Hacker News new | past | comments | ask | show | jobs | submit login

I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to.

Imperative languages have slowly been adopting some of these. 20 years ago you had people talking about how things like map and filter are confusing but nowadays most imperative languages have a version of it so obviously it isn't that confusing.




I don't know if this counts as irony, but here goes:

The killer feature of programming with pure functions is that you can guarantee the same output for the same input. If I were pushing this idea 5+ years ago, I would have said "Unfortunately you have to give up your comfortable for-loops and mutable variables* and learn about these weird maps and folds instead, but it's well worth the trade!"

Fast-forward a few years and now maps and folds are everywhere in the mainstream (it's even recommended to use them over for-loops in many cases.) But we never got the same-input-same-output guarantee which was my reason for switching in the first place!

* Even that's being too pessimistic. You can have your mutable cake and keep your guarantees, too: https://wiki.haskell.org/Monad/ST#A_few_simple_examples


> I think the problem is FP has built its own set of abstractions that imperative programmers aren't used to.

What you describe as a problem sounds like a solution to me :)

I'm curious whether you think there are imperative abstractions that could be used over the commonly used FP abstractions.

That avenue of discussion sounds potentially valuable and fun to me :)




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: