[Haskell-cafe] Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"

[Seth Gordon]

Paul Hudak wrote:
> Hi Sebastian.  As a writer of one of those "academic" Haskell textbooks,
> I've been following this thread with some interest.

BTW, I found your textbook very helpful.  The first time I tried to
learn Haskell, I got the Bird and Wadler textbook, and got bogged down
about halfway through.  It just wasn't the sort of approach that was
good for someone in my position, i.e., trying to pick up the language in
my spare time without the structure of a college class to check my work
and give me the occasional kick in the rear.

But with SOE--ooh! pretty pictures!  (The only problem was figuring out
the magic incantation to make Hugs on my system talk to the SOEGraphics
library.)

> Maybe some of you can do better, but it's really tough to show someone
> how an /advanced/ Haskell programmer would solve /advanced /problems
> that arise in the real world.  As a simple example, I love this recent
> quote by Garrett Morris:
> 
>     "I'm personally fond of framing most non-trivial Haskell problems as
>      defining domain specific languages; as a result, everything over about
>     200 lines that I've written in the past 3 years has used the mtl [Monad
>     Transformer Library] in some form or fashion.  It's great."
> 
> So how do we teach Garrett's way of programming (which I like very much)
> to the masses?  One would guess that we'd need to explain not only
> monads, but also monad transformers, first.

My first thought would be to develop some kind of cheap-ass NLP system,
starting with simple "VERB NOUN" constructions or some kind of text
filter, and building up to the kind of parser that the Infocom Z-machine
uses.

(N.B.: applications that are too reminiscent of math class, like
arithmetic-expression evaluators or symbolic differentiators, are
turn-offs.  If the rest of us were that thoroughly comfortable with
math, we'd be expert Haskell programmers already. :-)

> Sebastian Sylvan wrote:
>> There must be some way of teaching Haskell "breadth first", so to speak.

In the ed biz they call this a "spiral curriculum".

As applied to a Haskell textbook, what I would suggest is something like
this:

In chapter 1, introduce the IO monad, and point out a few key features
(e.g., explain why a function with type "IO a -> a" would be unsafe).

In chapter 2, introduce the Maybe monad, and point out that
constructions like "(Just 5) >>= putStrLn" won't compile.

In the next few chapters, introduce other common and useful monads, so
the student has some hope of getting an intuitive sense of what's going
on with them; at the same time, dribble in a few useful facts about
monads or useful operators for manipulating them.

*Then*, no earlier than chapter 5, provide the formal definition of a
monad and explain how you can roll your own.

(I'm not sure whether it would be helpful to give some examples of monad
transformers before the formal definition of a monad, or whether those
should come afterward.)