Monads

Quora Answer : Why do people have trouble understanding Monads in Haskell? Is it just the scary name, or is there a legitimate difficulty? Where in that type signature do people start getting confused?

Aug 27, 2014

The name is the least of the problems. Computer science is full of coolly obscure names. It's fun.

The first thing that's hard about Monads is that they come from Haskell. And Haskell has a specific culture. Particularly with respect to types.

If you're a C programmer, a type is basically something you use to tell the computer how many bytes to use to store numbers in, and how the pattern of bits in those bytes should be interpreted as a number.

If you're a Java programmer, a type is something you use to annotate two different places in your program (say the part that defines a method and the part that calls it) so that the compiler can check that you're being consistent and complain to you if you're not.

If you're a Python programmer, you can pretty much avoid having to have any explicit model of types in your head, or even thinking about them much at all.

But in Haskell, a type is something that programmers use to describe the structure of their programs and how the different parts lock together. Type signatures are to Haskell what UML diagrams are to Java : the high-level architectural overview. They are used to inform both the computer and other programmers how it's all meant to fit together and why.

To become a Haskell programmer is to acquire literacy in reading, writing and interpreting types and type-definitions this way, and in inferring the shape of the architecture of the program from them.

So, while some of the problem is mathematics speak : "A monad is just a monoid in the category of endofunctors" etc. The bigger problem is that many Haskell encultured people are going to try to explain monads to you by showing type-definitions. If you're already type-literate, then this is fine. But for most people who are basically stuck thinking with the C, Java or Python model of types, and aren't accustomed to making wider architectural inferences from reading them, this really doesn't convey much. Even if those people are perfectly capable of understanding architecture and high-level abstraction in other contexts, they aren't used to reading them from type signatures.

This is tied to a supplementary problem. Most people explaining Monads in terms of Haskell's type system are assuming you are already a committed Haskell programmer, so bloody well OUGHT to learn type-literacy so you can achieve reasonable competence in the language. But many people enquiring about monads are not yet Haskell programmers but outsiders who have heard that monads are a crucial part of the Haskell toolkit and want to understand what they are, as part of their decision as to whether Haskell is something that's worth investing their time and energy in. These people need an insight into monads that doesn't start with types.

(Personally, as someone who isn't literate in types and doesn't like them much, but does like functional programming, I've found Monads in Clojure to be a useful explanation. As it manages to talk about monads without making types the big issue.)

Update : note this is after the above answer got several 39 upvotes. Those voters may not support this update.

Although the term "monad" is cool rather than confusing I think there IS an argument to be made that terms like "bind", "return", "flatmap" etc. are so far from the other uses you might have for them in computer science (binding names to types, returning values from functions etc.) that there is some justification for feeling that Haskellers take a certain delight in introducing ambiguously confusing terminology.