4 ms·
> Everyone should learn at least one functional programming language and try to apply what they learned in other languages. But if functional programming langua
by aikah 11y ago
> Everyone should learn at least one functional programming language and try to apply what they learned in other languages. But if functional programming languages want to become popular, they have to be less about puzzle solving.
Because FP relies on an insane amount of theory.
Often FP aficionados are incapable of explaining functional programming concepts to others without using FP idioms or jargon. I still don't have the foggiest idea of what a monad or a functor is, or why the hell would I want to use currying or partial application, when my imperative code just works (that's not entirely true, and javascript has done a great job at popularizing some concepts, like closures, partial applications or first class functions).
Now compare with OOP : polymorphism , inheritance and encapsulation are easy to explain : Everybody can understand that a machine can be turned on by pressing a button, no matter what machine it is(phone,computer,screen) : polymorphism. It's easy to explain encapsulation : you don't need to how the inner working of a microwave in order to use it. Same with inheritance.
I agree that one should learn at least an FP language so one is forced to deal with a specific problem a certain way, that's good exercice. But I shouldn't have to understand category theory in order to learn Haskell or Clojure.
- jroblak 11y agoOn one hand you say that FP aficionados are unable to explain FP concepts to others, and on the other you succinctly do it later on in the same paragraph (first class functions, closures, partial application). I think you're conflating Haskell with FP, which is definitely not the case. No one needs to understand category theory to write Clojure or Lisp.
- nostrademons 11y agoNah, OOP concepts like polymorphism, inheritance, and encapsulation were crazy difficult to understand when they first came out. There were a lot of Car & BankAccount examples that didn't really reflect how people actually use OOP in the real world. The thing is, all the lucrative software engineering positions created in the late 90s required knowledge of OOP. Which meant that all the wannabe software engineers put in the time and effort to learn it, because that was how they could get a high-paying job. And so now you have a critical mass of people for whom OOP is second-nature, who can explain things to junior developers when they ask questions. Follow the money. FP isn't popular because outside of certain niche domains (eg. high-assurance software), it doesn't provide a competitive advantage large enough to build billion-dollar industries off of. If knowledge of FP suddenly started becoming necessary to get a six-figure software engineering job, you'd see many more people putting in the effort to learn about FP concepts. (This may already be happening with React in web development, with Hadoop/Spark/MapReduce in big-data, and with Swift in iOS development, but it's a new trend that'll take years to mature.)
- marcosdumay 11y agoGraphical interfaces pushed OOP into the mainstream. As plain structured programming was not powerful enough to create GUIs, people were forced to learn it. The fact is, for an industry that talks so much about lifelong learning and innovation, software developers are very conservative.
- marcosdumay 11y agoOOP concepts may be simpler, but their application are about as complex as the application of the concepts from category theory. You can learn what is a monad or an functor by reading/writing code with them. Pure Math is incredibly hard to learn without context.
- deleted 11y ago[deleted]
- pklausler 11y agoI'll agree that the terminology is not helpful to most people. But I would contend that if you understand object frameworks with callbacks, you already understand a useful and practical way of seeing functors and monads without being aware of the fact. And if you understand the basic idea of git, you already understand the idea of building new data structures that share large immutable parts of old structures.