> 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.
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.
The link you provided contains two precise definitions of the term "monad" in the responses (one which includes the source of the "a monad in X is just a monoid in the category of endofunctors of X" quote). Was it your intent to support @infinity0's premise that words like "monad" are not 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.
> 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?
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.
My interpretation of your analogy is that if there were a resource which presented monad-related concepts in a manner a working Scala programmer is likely to relate with, as opposed to theory laden texts, then the usefulness of these concepts might be better received in general.
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).
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.