4 ms·
> done a far better job than Haskell at explaining Monads [..] the elitist sounding language For fucks sakes, nobody invents words like "monad" to sound elitis
by infinity0 10y ago
> done a far better job than Haskell at explaining Monads [..] the elitist sounding language
For fucks sakes, nobody invents words like "monad" to sound elitist.
- saosebastiao 10y agohttp://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-issue http://stackoverflow.com/questions/3870088/a-monad-is-just-a...
- AdieuToLogic 10y agoThe 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. 0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree https://en.wikipedia.org/wiki/Abstract_syntax_tree 1 - https://en.wikipedia.org/wiki/Big_O_notation https://en.wikipedia.org/wiki/Big_O_notation 2 - https://en.wikipedia.org/wiki/Turing_completeness https://en.wikipedia.org/wiki/Turing_completeness
- saosebastiao 10y ago> 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.
- AdieuToLogic 10y agoMy 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).