

On Explaining Monads - emilyst
https://emily.st/2014/05/25/monads/

======
stormbrew
Not gonna lie, I was hoping for something funnier when I clicked this, because
I find the endless stream of terrible examples and explanations for what a
monad is extremely funny. Maybe that makes me a terrible person, I'm not sure.

But I think this is a rare useful addition to the corpus on layman
understanding of "what is a monad?" Because it goes to an effort to try to
destructure the problem and attack it from the angle of "why is a monad
useful?", the answer to which, to most people, amounts to "it probably isn't
to you right now, but it might be someday."

What it really comes down to, though, is that a monad is a way for you to
define a program that actually Does Useful Things (like ask questions and act
on them and output answers and occasionally tell you you're doing it wrong).
You can use a C++ compiler or a ruby interpreter for this, or you can write a
program in Haskell that generates one. And if you do the latter, monads are
the construct that you build them with.

From there you have to explain why there's a benefit to going the roundabout
route to useful things, but no one's going to understand them until they
understand that basic premise.

~~~
mattgreenrocks
Disclaimer: still reckoning with monads.

The explanation is better than most I've seen, but it also feels a bit too
reductive. IO is probably the best way to start understanding monads (futures
also helped), but this idea of decorating instructions means you can do things
like implement your own exception handling mechanism if need be. Lingual
features of this scope usually aren't given to users, excepting a Lisp.

The hard part for me is grappling with how abstract a monad is. To this end,
it almost seems easier to observe the uses of them rather than trying to fit
them in a box (for now). Every explanation I read on them now sheds a bit more
light on them, so it's just a matter of time and persistence.

~~~
groovy2shoes
This is hands-down the best introduction to monads:

[http://blog.sigfpe.com/2006/08/you-could-have-invented-
monad...](http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-
and.html)

It starts with some motivation, then gives some specific examples, then
generalizes to monads. It gave me a TON of insight about monads when I was
first starting out, and I'm genuinely surprised that it doesn't get mentioned
every time the monad discussion comes up.

Monads are so difficult to approach because they're so abstract and general --
all the theory in the world won't help you understand how they're useful. Once
you've got the basics, the only way to grok monads is to use them. The IO
monad alone is a good start but it's not enough. Try using a bunch of them to
get a feel for what they have in common. The Maybe and Error monads come in
handy a lot.

While most tutorials introduce monads with return and bind, monads can also be
characterized by fmap and join. I'd recommend learning about that as the next
step towards monad enlightenment. It helped to give me more insight into what
a monad _is_ , conceptually speaking. It's not strictly necessary but I found
it interesting and helpful.

As an aside, if you find yourself struggling with Applicative Functors, try
playing around with Elm [1] (Signals are applicative functors, and the <~ and
~ operators are the same as Haskell's <$> and <*> operators). That's what did
it for me :)

[1]: [http://elm-lang.org/Elm.elm](http://elm-lang.org/Elm.elm)

------
chrismorgan
Good job on the permalink for the Wikipedia article. I wish more people did
things like that. (e.g. links to blobs in GitHub are typically identified by
the branch name rather than the commit—use the commit number by pressing the y
key.)

------
tikhonj
No!

EDIT: As a side note, I hope my tone doesn't come across as too harsh. I feel
a bit bad about writing this way, but it's just something I've been thinking
about—and frustrated by—for a while. I have no problems whatsoever with the
author of this piece. I just want to make sure that people really pick up on
where it's off the mark, and I'm a bit frustrated—largely with myself—that
there is no good explanation of functional programming and monads that avoids
many of these problems.

That is _not_ the way to think about monads. It's an unfortunate failure of
education/PR that people hang on to this notion. The way monads are often
presented, it's a very natural conclusion. But it's also entirely misleading.

Monads are not tied to functional programming. They are not tied to _pure_
functional programming. They are _not_ about introducing IO effects to
otherwise pure programs.

There is _one_ that does that. One type that's a monad and that manages
effects in Haskell. IO. But that is the IO type. Other monads? Other code
using monads? It often has _nothing_ to do with adding effects to a pure
language! (Unless you stretch the definition of "effect", which, to be fair,
many people do.)

There are lots of other monads. Lots! You can think of most Linq code as using
_some_ monad—but never for effects. It's in C♯, after all. Practically Java,
and about as far from pure as you can get. Promises, in JavaScript, form a
hobbled monad, which could trivially be a completely reasonable and correct
monad if the people writing the spec weren't violently opposed to it.

The Wikipedia description... was not bad. Even if the author found it
confusing. It wasn't great either. Even that was too narrow.

I like to think of it like this: a monad gives us a new, custom, way to
_compose_ things. In the case of IO, it does, indeed, give us a way to compose
effectful programs. In the case of List, it gives us a way to compose
nondeterministic functions (ie backtracking). In the case of Maybe, it lets us
compose functions that may fail (ie early termination). And so on.

And the final paragraphs showcase yet another unjustified belief: that pure
functional programming is basically just imperative programming _but less_.
That's something I really need to write about _at length_. Suffice to say,
it's more enlightening to think of pure functional programming—especially like
Haskell—as almost _orthogonal_ to imperative programming, not as a subset.

But, again, this is not something clear from most Haskell learning materials
or evangelism. It's just so easy to describe it as imperative programming
without assignment or imperative programming without side effects or... I did
the same thing myself when I started. But that turned out not to be a good
description at all. If anything, it just serves to confuse as soon as you get
to intermediate or advanced Haskell topics.

I completely understand why people take this tack. The best way to learn is by
drawing connections and analogies to what you know. And Haskell learning
materials don't exactly provide the contrast or elucidation you'd need to
avoid many of these pitfalls. I'm not sure what the best approach to
rectifying this is, so for now I'll just write a few blog posts about it and
not much more...

If you're curious, I've tried my hand at explaining monads too. But what I
wrote is way too long and too rough and too unedited and, for all three
reasons, on Quora[1]. Still, might be worth a look.

[1]: [http://www.quora.com/Functional-Programming/What-are-
monads-...](http://www.quora.com/Functional-Programming/What-are-monads-and-
why-are-they-useful/answer/Tikhon-Jelvis)

~~~
emilyst
I feel like Wadler was pretty straightforward in his whitepapers about the
role he envisaged for monads. See in "Monads for functional programming", the
second sentence of the abstract, or the first sentence of the introduction.
He's pretty clear that he's talking about monads as a tactic to represent
impure notions into a pure functional program.

My point is to take the concept beyond theory and talk about application, and
the application is making something useful out of functional programming.

------
platz
That wikipedia quote needs to be banished into the 7th circle of monad shame.

------
dukerutledge
Meh, a ton of blow harding with little explanation.

~~~
dangoor
This post didn't strike me as a ton of anything. It was pretty succinct. I
agree with stormbrew above that the value here is in stating clearly what the
purpose of a monad is as a way to lead in to a better understanding of a
monad. With knowledge of what a monad is, many people will probably stop
reading there because they're not interested in getting close to pure
functional programming.

