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

[Erik Jones]

On 8/14/07, Michael Vanier <mvanier at cs.caltech.edu> wrote:

I'm becoming more and more convinced that metaphors for monads do more harm
> than good.  From now on
> I'm going to describe monads as purely abstract entities that obey certain
> laws, and that _in
> certain instances_ can be viewed to be like containers, or actions, or
> donuts, or whatever.  In
> other words, a monad is an abstract thing that can generate things that we
> can metaphorize, but it's
> pointless (point-free?) to try to capture the entire concept in a single
> metaphor.  I'm reminded of
> a physics teacher who was having a similar problem explaining the concept
> of tensors, until he said
> that "a tensor is something that transforms like a tensor does!".  So a
> monad is something that
> behaves like a monad does.



Nice.  As a Haskell beginner (with previous imperative programming
experience) I subscribed to this list today to say exactly that.  I spent
weeks reading different tutorials that attempted to enlighten by means of
various abstractions before I finally found one that simply showed the
mechanics of the required operators and rules (sounds less formal than laws)
that they need to hold to.  Even then I hadn't quite "got it" until I met
SPJ at OSCON and heard myself saying, "All monads are are labels in front of
values with specific operations defined on them."  His reply was, "Yes!
Very abstract isn't it?"  Then I'd "got it", or realized that I had but
hadn't realized it (if that makes any sense...), as that sequential exchange
of ideas (hah!) brought me to the realization that the "abstractions" that
monads are held to represent are solely in the usage semantics of aforesaid
operations and, while technically the actual labels used don't matter, we
pick labels whose meaning match those semantics.

So, yes, don't start by giving any extra meaning to the basic monad
operations than their mechanics.  Then show how they can be use to
"implement" abstractions like state, uncertainty, etc...

Oh yeah, start with terms that programmers already know, e.g. encapsulation
v. wrappers.  Then switch.  Don't start with terminology that's different
and explain the mappings, start with the familiar than follow the mappings
to the different.

-- 
Erik Jones
mage2k at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070814/2e45befa/attachment.htm