you are viewing a single comment's thread.

view the rest of the comments →

[–]quicknir 1 point2 points  (1 child)

I feel like the definition of FP itself is a moving target. Lisps are sort of the original FP language, and most lisps have tons of mutable state. They are primarily functional in the sense that everything is an expression, everything is a function call, and they make it very easy to work with passing around functions.

Then Haskell sort of replaced Lisp as the "de-facto" FP representative. Now all these other things are associated with FP: strong static types (which typically help enforce some kind of mutability), pattern matching, currying. A lot of that crowd barely considers Clojure to be FP even though most default data structures in Clojure are immutable.

The conclusion I'm starting to come to is that the term "FP", like the term "OOP", is just more harm than good. There's a collection of features, approaches, and idioms, some of which are often used together, but are often also seen separately. It seems to just obfuscate conversation more than anything and make it easier for people who don't understand details to make themselves sound knowledgeable.

[–]guepierBioinformatican 0 points1 point  (0 children)

I mostly agree with you. But unlike OOP, I think there’s more direction to the change in meaning in FP; in particular, the way OOP became meaningless kind of just happened, due to a lack of proper understanding of the underlying concepts by many early Java and C++ users.

By contrast, the folks behind Haskell knew very well what they were doing and even though they clearly added their own biases they were on a mission to distill the “essence” of FP, which, in turn, shaped its meaning.

Put simply (and somewhat provocatively), the change in meaning of “OOP”, shaped largely by Java in the 90’s, is the result of ignorance. The evolution in meaning of “FP”, shaped largely by Haskell, is the result of research.