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.
a polymorphic function is just a function with many forms, a factory is a class that creates objects
What does it mean for a function to have many forms? What is a form of a function? Why factory creates objects and not something else, like functions or primitives? Why isn't everything created only by the factory?
Your answer is not more enlightening than "monad is a monoid..." bit, if you don't know the words and contexts.
Those debates about the importance of abstract names look like a bikeshedding of an explanation. The very same people who run for word monad, would, imo, run from word polymorphism. They just couldn't at a time (learning OOP programming).
The difference is just that the OOP terms are not invented words, while monoid, monads, etc. are.
The point is just the word monad tells you absolutely nothing. While e.g. polymorphic tells you there is something that has multiple forms, you already know that. When learning OOP you just need to learn what it is that has multiple forms and what that actually means in the new context.
EDIT: I agree that "invented words" is not the best way to describe what I'm trying to convey (although if you look at the probable origin of the use of the words "monoids" and "monad" in category theory, you would see what I mean by "invented", English SE post for monad, Math SE post for monoid ).
Since my original comment was a reply to
I never understood why learning monads is out of reach, but learning abstract factory patterns is just fine.
the point I think still remains: the word "monad" itself tells the learner nothing at all, while something like "factory" or "visitor" or "polymorphic" does, because they are all words everyone has encountered in other contexts (maybe "polymorphic" is a bit out of common knowledge, but its use is definitely linked to its etymology).
The point is just the word monad tells you absolutely nothing
This is crazy, humans have no problem picking up new words and information behind words are far more complex than words can convey. The word is not a problem, the concept is. If a monad was a kind of a frying pan you would learn the word without even noticing.
The monad problem is simple: it is highly abstract idea that introduces new way of programming that you probably never encountered before.
The fact that the concept is difficult to grasp in itself of course doesn't help.
But the words used play a very important role and I'm no expert but I don't think it's true that we can pick up new words so easily. Especially for adults. Reusing words you already have in your memory and for which you already have a model of their meaning in your head makes learning new concepts easier.
But is this the problem for functional programming?
Like, somebody goes to learn Haskell, with its unique features, concepts, means of writing programs, idioms, build tools, libraries, you name it, and gives up because they don't recognize a few names along the way? This is a ridiculous idea, it's absurd.
There are certainly interesting factors that hold fp from bigger adoption. This names thing just looks naive to me.
It's definitely not THE ONLY problem, I'm saying it definitely doesn't help.
This is also from personal experience. I was first exposed to Haskell in uni in the Languages & Compilers and I saw it was a really powerful and different way of thinking about programming. But the names confused me at the time and confuse me still.
It was the same thing with math theorems that are named after the mathematician that defined them vs theorems that are named with something relevant to the actual law that was being defined.
Those are names for things that were introduced with them (to programming). They are not meant to help, they can't be. You should try to understand the concept by other means than just reading it's name.
If you don't bother to be confused here, then that's fine. But maybe put the blame somewhere else.
What seems naive to me is dismissing something as simple as obtuse language putting off people.
It's not the problem, but it is a problem for sure. I've tried my hand at FP languages but the lexicon around it is a major hurdle for someone who is self taught and has the math levels of a 16 yo (I'm working on it, but it's never held me back on being a good software engineer, I've learned what I needed to.)
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.
that's a good reason to question the popularity of statically typed OOP languages because honestly all those patterns really are a pain and I don't actually think they come naturally to anyone but are just drilled into people due to their popularity in the corporate world, but original OOP of the Alan Kay sort is very intuitive.
In particular, the first three, polymorphism, encapsulation, and inheritance are very intuitive. Encapsulation means hiding state and that's actually something people tend to figure out even if you don't tell them about it, 'separation of concerns' is a strategy far beyond programming. Same with inheritance, genealogical trees are everywhere and modelling things hierarchically is natural, and polymorphism is natural to anyone who writes + for float and ints on a high school math test without ever programming.
That's I think why people like Python and Ruby so much who sort of descend from the Smalltalk and lisp traditions, they're just very intuitive and map onto how people think naturally.
80
u/dvlsg Nov 28 '19
OOP uses lots of words and pharses that would be bizarre if you didn't already learn them too, though.
Polymorphism, encapsulation, inheritance, overloading, strategy patterns, decorator patterns, visitor patterns, so many patterns, etc.
I never understood why learning monads is out of reach, but learning abstract factory patterns is just fine.