On Explaining Monads(emily.st)
emily.st
On Explaining Monads
https://emily.st/2014/05/25/monads/
5 comments
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.
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.
This is hands-down the best introduction to monads:
http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
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://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
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
[deleted]
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.)
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-...
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-...
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.
My point is to take the concept beyond theory and talk about application, and the application is making something useful out of functional programming.
That wikipedia quote needs to be banished into the 7th circle of monad shame.
Meh, a ton of blow harding with little explanation.
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.
Yeah, I tried to be clear that "I’m not going to explain monads."
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.