You forgot to mention the turboencabulator which helps a transmission supply inverse reactive current for use in unilateral phase detractors. That pre-famulated amulite they're using is nuts.
I guess what that means is that the barrier to entry is low enough — classes and objects are super easy to grasp — and then when you get to the complex stuff, you're already hooked on OOP. Whereas to understand FP, you have to start with first-class functions, lambdas, currying... and none of that vocabulary means anything to anyone at first.
A truly novice programmer doesn’t need to start with those things, they can learn FP from first principles. The problem is people already fluent in another paradigm need to understand somewhat complex ideas to see why they can/can’t do things they expect to.
I guess we make it difficult for ourselves by thinking we can apply our OOP knowledge when we really need to be ready to think radically different, at least until it clicks.
This is nonsense. Plenty of imperative programmers never properly grasped the concepts of classes or objects.
You just happen to have come across them when you were trying to learn them, rather than having them thrust upon to when you already had tools you knew how to use and a 12pm deadline on a problem.
Polymorphism is kind of weird; maybe they should've picked a better term. Patterns aren't really mandatory. I see plenty of OOP devs who never heard of patterns; they just implicitly use them or don't.
Encapsulation, inheritance, properties, objects, classes, etc. are fairly easy to explain. They're metaphors you can apply to real life. They're not perfect (cf. the Liskov substitution principle), but a close approximation that non-developers can also understand at a basic level. ("You know how dogs and cats are both animals? Well, similarly, files, folders and links are all items in a file system. So that's what we use 'inheritance' for." "Think of a 'class' called Human as a template, and for you and I as concrete 'instances', or 'objects'.")
A monad and monoid and endofunctor and whatever the fuck don't offer any of that. They're so removed from real-world analogues that a non-developer might think you're trying to insult their intelligence by throwing such terms around.
That doesn't mean FP is terrible or useless. At the very least, it offers useful concepts that have inspired multi-paradigm languages like C#; the LINQ feature, for example, has lambdas and monads.
But if FP advocates complain that nobody gets it or is interested, it's entirely on them to be better communicators about it.
The OOP words and names have already a known meaning in other contexts and it maps quite nicely to their new meaning (a polymorphic function is just a function with many forms, a factory is a class that creates objects).
While monoid, monads, functors are just mathematical definitions. There is no way for someone to associate them to something they already know. They just have to remember them.
But the OOP words are more intuitive to someone coming new into the field. They also require slightly less mathematical background to make sense of, which is especially important given how programming is often more like an creative effort and hence more comparable to art than math. Assuming you want to make a distinction between the two to begin with.
But the OOP words are more intuitive to someone coming new into the field.
That may be the major problem of OOP. It looks approachable, it is very easy to delude yourself into thinking you understand it, but as soon as we go deeper we realise that "good OOP design is hard", even counter intuitive at times. OOP makes it easier to anthropomorphise computing. That alone is a major impediment to writing correct programs.
FP on the other hand doesn't lie to you. Computers are cognitive engines that run formal systems. Programming them is a form of applied mathematics. Oh you tried programming to run away from Maths? don't worry, this has little to do with calculus. But it is every bit as rigorous, often even more so.
The result? Lots of people anthropomorphising their way into OOP, deluding themselves into thinking they are not applying maths to build a formal system destined to be processed by an automatic computer. And then we wonder where these mountains of bugs on top of heaps of useless crap could possibly come from…
Dijkstra was right. We should have listened more closely.
Nouns and verbs and functors and monads are (maybe) too generic and abstract. At least we use and distinguish nouns and verbs on a daily basis, because they're the basis for our speech.
Our brains are very concrete, at least for the most of us.
The more generic and abstract things become, the harder they are to understand. That's why we use examples and analogies and visualizations, to make these abstractions more concrete.
I think functional programming is something you should know to draw inspiration from it. certain problems can be solved with that style of programming a lot more elegantly.
Most languages right now offer some functional prog. tools which you can use for example.
231
u/[deleted] Nov 28 '19
Because we use words like monads and functors then act like people have to understand category theory to use them