4 ms·

Observation from the real world: Functional programming seems to be extremely easy if you have never learned imperative programming first. I have seen beginner

Observation from the real world: Functional programming seems to be extremely easy if you have never learned imperative programming first. I have seen beginners grasp FP much faster than OOP and write production ready code only after a few weeks/months of learning whereas beginners need on average multiple years to learn "production ready" design pattern style OOP. On the other hand I have observed some of the best OOP developers really struggle with FP. It's not that they find FP hard to learn, they find it really hard to unlearn OOP and the thinking that the way things are done in OOP is the holy grail of good software design. For example, only recently there was this blog post trending on HN (Am I stuck in a local maximum - https://blog.ploeh.dk/2021/08/09/am-i-stuck-in-a-local-maximum https://blog.ploeh.dk/2021/08/09/am-i-stuck-in-a-local-maxim...), which was triggered by a "blue tick" OOP programmer (tastapod on Twitter - inventor of BDD) making false statements about FP because he seemingly struggled learning it and wasn't able to work out how to program without mutations. He came to the conclusion that all functional programmers actually use mutations by default and immutable data structures are not common in FP at all. It was a completely unfounded assertion and clearly one made from frustration by someone who was so hard wired into OOP programming that they couldn't adapt to the FP way of thinking. It was a prime example of an "old dog" (citing the original article) finding FP harder than the new guys.

jacquesm 5y ago
Yes, this is very true. It took me a lot of time 'unlearn' bad habits about state and side effects before functional programming really clicked. The interesting bit is that it made my other programs better as well, because I still find myself avoiding mutable state and impure functions.
- dnautics 5y ago
  I'd personally say it's less about unlearning statefulness and learning what the alternative tools are and not be bullheaded and kick and scream about not having the tools one is used to, e.g. map and reduce vs for and while. Once you learn how to use them, their utility and benefit (they explicitly limit the scope of the changes in the loop and reduce mental overhead) become clear. But a lot of people never get past "why can't I have a for loop" and don't get there.
  - jacquesm 5y ago
    Map and reduce immediately clicked, the state thing had me for the longest time ('how do you generate output, how do you get a real world effect from a function'), those seemed to me to be far more magical in the FP world than in the step-by-step alteration of the environment that I was used to from imperative programming. It also seemed to map harder onto the real world than IP, where instructions about piecemeal alterations seem to be the way of the world. It really clicked for me when I started to think in terms of transformations, where each function performs a transformation of the input on the way to some output. This allows you to be 'pure' most of the way and to limit input and output to the top layers of the program, where they should be (should in my opinion).
agumonkey 5y ago
Thre's a little bit of psychological esoterism too, fp is very minimal, OOP gives people some new mystery rope to hang themselves with. verbose syntax, procedures to follow, it's probably psychologically a better impedance matching than 'a -> 'a -> b -> ('a -> 'b) where people have to hold very very evanescent ideas floating in the air without as much ways to play with them.

jacquesm 5y ago

Yes, this is very true. It took me a lot of time 'unlearn' bad habits about state and side effects before functional programming really clicked. The interesting bit is that it made my other programs better as well, because I still find myself avoiding mutable state and impure functions.

dnautics 5y ago
I'd personally say it's less about unlearning statefulness and learning what the alternative tools are and not be bullheaded and kick and scream about not having the tools one is used to, e.g. map and reduce vs for and while. Once you learn how to use them, their utility and benefit (they explicitly limit the scope of the changes in the loop and reduce mental overhead) become clear. But a lot of people never get past "why can't I have a for loop" and don't get there.
- jacquesm 5y ago
  Map and reduce immediately clicked, the state thing had me for the longest time ('how do you generate output, how do you get a real world effect from a function'), those seemed to me to be far more magical in the FP world than in the step-by-step alteration of the environment that I was used to from imperative programming. It also seemed to map harder onto the real world than IP, where instructions about piecemeal alterations seem to be the way of the world. It really clicked for me when I started to think in terms of transformations, where each function performs a transformation of the input on the way to some output. This allows you to be 'pure' most of the way and to limit input and output to the top layers of the program, where they should be (should in my opinion).

agumonkey 5y ago

Thre's a little bit of psychological esoterism too, fp is very minimal, OOP gives people some new mystery rope to hang themselves with. verbose syntax, procedures to follow, it's probably psychologically a better impedance matching than 'a -> 'a -> b -> ('a -> 'b) where people have to hold very very evanescent ideas floating in the air without as much ways to play with them.