[Haskell-cafe] Why monad tutorials don't work

[Dan Weston]

Conor McBride and Ross Paterson said it best in the introduction to 
their paper "Applicative programming with effects" [1]:

   "This is the story of a pattern that popped up time
   and again in our daily work,..., until the temptation
   to abstract it became irresistible. Let us illustrate
   with some examples."

Translation: Unless you've broken your back hauling water by hand, 
you'll never truly "get" the utility (even joy) of installing plumbing. 
To help you speed through (but not skip over) this necessary hauling 
drudgery, we will show the movie of us doing it in fast forward, and ask 
you to make the leap of faith that the sweat dripping off our brows is 
real, not sprayed on to make us look impressive.

The fatal flaw of all tutorials is that the easier they make things 
seem, the less visceral understanding of the importance and benefit the 
reader will have.

So here's my 30-second monad meta-metaphor:

Monads are like wrapping paper, so the surprise isn't spoiled before 
Christmas. Every present can be wrapped, the paper doesn't damage what 
it covers, and there's no need to wrap it twice, it's no more opaque 
than wrapping it once.

But you know better! You don't want to bother wrapping your presents. 
Your children promise not to peek until Christmas day anyway. After 
first, you have plenty of time to watch them. But as the holidays 
approach, you get busier, and pretty soon you have to choreograph your 
entire day just to divert their attention. It only takes one slip-up to 
ruin the surprise, so you spend a great deal of effort making this happen.

Your mother (who has been down this route before with you) knows from 
experience that it is just easier to use wrapping paper, but you don't 
believe her. She's so old-fashioned and dogmatic! In a misguided attempt 
to be helpful, she whips out the dreaded Monad Tutorial Book of All 
Human Wisdom and explains the concept of Present Wrapping. The authors 
have PhDs in the science of concealment and compare the common 
properties of paper, boxes, sleight-of-hand, and one-way mirrors, but 
your eyes glaze over because you don't care about mirrors, you just have 
a present. Helpful friends share their war stories, but as you're not a 
bad parent like they are, you don't fall for their arrogant attempts to 
educate you and you point out how in each case their experience doesn't 
fit your needs.

The most amazing thing in this metaphor is the strangely irrepressible 
joy that those who've mastered the art of present wrapping have to share 
their discovery with others. I guess some things are just too good to 
keep to yourself! Sadly, these tend to be the things you can't even give 
away without getting flak for it... :(

Dan Weston

[1] http://www.soi.city.ac.uk/~ross/papers/Applicative.html

Lanny Ripple wrote:
> Having just gone through all the tutorials and things (again but this 
> time I think it stuck) the Haskell community is on the wrong track as 
> far as teaching Monads to new programmers.
> 
> If I were teaching addition and multiplication to children I wouldn't 
> start with, "We'll begin by defining an algebraic structure named a 
> "Group".  From there we'll expand our concept to a "Ring" and "Field".  
> A group is a set and a binary operator usually named "+" (or sometimes 
> "*") such that...".
> 
> No no no.  You start with, "You all know how to count from one to 10.  
> If we have 1 item and we 'add' another 1 item we have 2 items.  We write 
> this 1+1=2."
> 
> The tutorials seriously need to step back and start with something like, 
> "To enforce order of evaluation we evaluate closures* returning a 
> defined type.  The first closure will feed its result to the second 
> which will in turn feed it's result to the third.  Since the third 
> closure can't be evaluated without having the results from the second 
> and first (and thus they had to be evaluated earlier in time) we get a 
> defined evaluation sequence.  Here are some examples..."
> 
> (* Even using the word 'closure' is scary for those not familiar with 
> them.)
> 
> Then, like "Monads For Functional Programming" (the paper that finally 
> clicked Monads for me) you point out that evaluating all these closures 
> returning a defined type in various ways form a structure (which you can 
> then explain) and we can use that structure and change out the 
> underlying effect(s) as needed.
> 
> Now of course if your new programmer has the the necessary background 
> you can throw them in the deep end.  But don't do that to someone coming 
> at the language from something like Java learned out of a business 
> degree course.  (My background is a CS degree with math minor and it 
> still took two go-s at Haskell before I got as far as understanding what 
> folks were talking about with Monads.  Wish I had found Wadler's MFFP 
> the first time around.)  Where are the shallow end tutorials?  (Don't 
> get me wrong.  The tutorials are good but there is also a place for the 
> "learn-by-rote with lots of examples" ones too.)
> 
>   $0.02,
>   -ljr
> 
> PS - Not so much directed at Ronald's post but his was convenient to get 
> me on my soapbox.
> 
> Ronald Guida wrote:
>> My present goal is to understand monads well enough to be able to
>> explain them to others.  I wonder if it's possible to create a
>> tutorial that explains monads well enough so that they just "make
>> sense" or "click" for people.