I agree that Monads deserve our time and attention. Unfortunately, search for monads and you'll get thousands of articles explaining what they are in incomprehensible terminology, along with language-specific type annotations, and devoid of any practical reasons to use them over their non-monadic control flow cousins in imperative languages.
They never seem to explain why you would ever need them, how they help in certain situations. Even worse, they don't tell you when they might actually be hazardous or code smell. They rarely even gloss over the challenges (like needing monad transformers if you want any sort of monadic composition), leaving you to figure that out for yourself when you start bashing your head against the walls.
For all their hard-to-google non-standard terminology, the Scala and F# communities have done a far better job than Haskell at explaining Monads in a way that actually makes people want to learn and use them. And once they have learned the concepts, the elitist sounding language doesn't sound quite so intimidating anymore.
For fucks sakes, nobody invents words like "monad" to sound elitist.
If so, well done!
If not, then I humbly ask why is a term such as monad qualified as elitist, yet terms such as Abstract Syntax Tree[0], Big O notation[1], and Turing complete[2] are not?
All four of these have in common precise definitions.
All four of these have in common applicability when considering the domain each address.
All four of these have in common their existence in programming even when not directly considered by those writing software.
0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree
The preciseness of the definition has nothing to do with the perceived elitism. Plenty of precisely mathematically defined concepts, as you've illustrated, can be (and are) explained to people without ever needing a single glyph or axiom in the explanation, let alone a recursive terminology briefer.
Take the following two definitions:
1) A screw is a mechanical device that converts rotational motion to linear motion, and torque to a linear force.
2) A screw is something you use to attach stuff to walls. You use a screwdriver to mash it in there.
One is abstract yet precise. The other is non-abstract and imprecise...so imprecise that it might as well be wrong. Regardless of its cringe induction potential to the Haskell-lovers brain, only one of these definitions will hold the attention of a 4 year old and explains why they're useful and how to use them.
The simple fact of the matter is that people in general are bad at math, and even most people who think they are "good at math" have no fucking clue what category theory is...good luck holding their attention while you brief them on it. Nobody learns abstract before non-abstract, it's just not how brains work. If you give them a reason to hold on to the concept, and explain it with words they likely understand, you might get far enough to one day explain the abstract version.
Fair enough. So here is a book which does precisely that:
"Functional Programming in Scala" (ISBN-13: 978-1617290657)
The authors incrementally present FP concepts, including monads, in a very approachable style. I can say first hand that this book does not require a heavy mathematical background (off hand, I don't think there are any formal proofs in it).
> its essence just because we're afraid of big words and the opinions of experts.
I think most of the distaste for terms like Monad, is a failure to communicate it's meaning to a lot of people, it reminds me a lot of Enterprise Java terminology with terms like factories, abstract/factories, Bean, ect, that provide just as much intuition into their own meanings from their names. And when you look up their meanings you get hit with even more obtuse terminology. Like for example a in a less formal discussion about programming, a term like "pure functions", can simply described as "stateless function" [1]. You don't need to automatically reach for the big words, when a more commonly understood word sufficiently communicates something. Unfortunately I'm not so sure there's such a word for monad however.
In the case of Elm, it has this approach to naming things with less formal names where it can use something more comprehensible. The author of the Elm language mentions this in a talk of his [1] (just scroll to the section on being direct).
I really see this more as a communication issue, not everyone in software has a duel degree in abstract mathematics & computer science, let alone a degree.
[1]: http://www.elmbark.com/2016/03/16/mainstream-elm-user-focuse...
When it comes to Monad et al I'm reminded of this talk by Gilad Bracha. He points out that the function names and type names that stem from category theory are not very good at communicating their intent in programming. (my words) Monad could be named Flatmappable f.i. 'unit' and 'bind' can have more intuïtive names as well.
At the moment I get the impression that as Scala is becoming a safe and productive and widely used tool there are developers moving to more Haskell like pastures within Scala. Perhaps because that kind of programming is required for some specific problems. But quite likely as well because they hope that it will make them stand out as smarter programmers.
Some people may remember the so called "Peters principle". Informally it states that people get promoted until they've reached their level of incompetence.
Similarly some smart developers tend to increase the complexity of their code to keep themselves amused until they're struggling to understand it themselves. Joosts principle. :-)
Edit: the link to the talk https://www.infoq.com/presentations/functional-pros-cons
This was my point exactly, also thanks for the link I'll have to checkout that talk :-)
I'm actually indifferent to the terminology, having used my fair share of Haskell/ML/Lisp, but I can see how you came to that assumption.
> in many formal publications
I'm aware of this, but the thing with this is not everyone in software has a computer science background, let alone an academic background. I'm a freelancer at the moment, but if I used most of this terminology in my workplace people would be giving me wtf looks.
> In no way is "Enterprise Java Beans" analogous
How so? All I said formal names in mathematic/computer science, give next to intuition into their actual meaning & when you look up their meaning, most of the results are riddled with more terminology. Same kind of goes for a lot of the Jagon in Java enterprise stuff, like beans/services/factories/etc. I wasn't saying their exactly the same, but more I had a similar experience when trying to familiarise myself with that stuff.
To clarify I'm not suggesting changing existing names in mathematics or existing APIs, I'm just suggesting in documentation / blog posts / educational stuff we should avoid using the more intimidating terminology if a simpler term convoys the message better, especially if the terminology gets in the way of educational material doing it's intended purpose.
Maybe this wouldn't be a problem if mathematic education content was more accessible, I don't know but at the moment I really don't think it is. Like it would nice to have a nice accessible book like "Category Theory in Python/JS" or something to refer people to... But I agree, changing names is anti-intellectualism
> The danger of "intuitive" names and analogies is that they often don't capture the generality of the abstraction and can limit ones thinking
I get that, & I feel in mathematics that is important, but in writing an API having slightly dishonest names is okay. Like a name like `flatMappable` vs' `Monad` even though not all Monad's work like a flatMap, but I get what you're saying new users might think monads are just a collections API thing, but maybe if they saw it on an Optional/Error/Promise/Async/etc this wouldn't be a problem, I don't know. Maybe it's a matter of establishing a culture where the use of these names like flatMap are first demonstrated with none collection types, again I don't know. I'm really just throwing ideas out there, but I feel it's something to consider.
Oh well, hopefully things improve
Didn't really expect that, but bravo, I suppose!
> Official Scala documentation never even mentions the word "monad" (not even once!), and I think this is a good thing
Actually that's a huge mistake because Scala is amongst the few languages that can express the Monad as a type. In most mainstream languages monads aren't explained because those languages lack the capacity for doing it. It's no wonder that people have a hard time understanding monads without a type to look at, as that would be like describing an elephant to a blind man. Do you think you understand Iterable because of its name? No, you understand it because you've seen its interface clearly described and then you used it and learned to appreciate it.
And really, the strangest things happens when you don't talk about it. You still have for comprehensions, but surprise, they don't behave like in Python, "yield" is again overloaded, having nothing to do with Python's yield or Ruby's yield, and people stumble for no good reason, because it is hard to connect what seems like syntactic sugar over iterators to an expansion using map and flatMap. Along with "computation expressions" from F# or other bullshit naming meant to not scare away the most sensitive of us, the big problem that happens is that people get confused and don't even know what to search for. Search for monads and you'll find endless articles, tutorials, books, research. Search for comprehensions and you get shit.
This is basically anti-intellectualism, the same kind of attitude that made Trump popular and that encouraged Brexit. The same kind of attitude that made the Option type in Java violate the Functor laws, taking a concept and destroying its essence just because we're afraid of big words and the opinions of experts.