Hi Sebastian.  As a writer of one of those "academic" Haskell textbooks, I've been following this thread with some interest.  In fact, I agree with pretty much everything that's been said.  But I must point out that, even though Chapter 18 in SOE is titled "Higher Order Types", and that's where I introduce the Monad class, I actually introduce IO in Chapter 3 -- page 36 in a 363 page textbook to be more precise.  In fact, I do exactly as you suggest -- introduce IO early in a way that most imperative programmers are familiar with, and then expose the beauty and generality of monads much later -- i.e. in Chapter 18.

I don't know if you were referring to SOE when you said Chapter 18, but I thought that I should point out the coincidence, at least, if that's what it is! :-)

While I'm at it, I have a couple of other general comments:

I purposely wrote SOE in a style that I was hoping would be different from the standard language textbook, namely I tried to introduce language features as they were needed in solving  problems, rather than just rattling off a list of language features.  Granted, my toy "multimedia" examples are not well motivated by the real world, so it doesn't necessarily apply to what's now being proposed.  But I wanted to point out that this was nevertheless really hard to do, and the sequencing of the material was a real challenge -- I'm not even sure that I would follow this formula again if I rewrote the book.

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.

One of the things I found myself doing in SOE is saying things like, "remember that thing we did way back in Chapter 3?  Using monads, we can now express it more elegantly and modularly and succinctly like this: ..."  But there is danger in doing this.  If we teach newbies how to do things the "beginner's" way first (recursion instead of higher-order functions, lists instead of user-defined data types, specialized functions instead of type classes, and so on), then we risk the user saying "Oh this is just typed Lisp, so I'm outa here."

So, I am *all for* someone writing a textbook that tackles real, meaty problems from the real world.  But it's not at all clear to me how to do it.  There seems to be a need for a fine balance between elementary stuff and advanced stuff, mixed with both elementary and advanced applications.  I hope that some of you are up for the challenge!

    -Paul Hudak


Sebastian Sylvan wrote:
On 12/11/06, Kirsten Chevalier <catamorphism@gmail.com> wrote:
It's not as if this is the first time that this has been suggested,
but some people have suggested that a practical book about Haskell
would be a good idea. I agree. Some people have also suggested that
the right moment for this hasn't arrived yet, and I see that as a
challenge.

IMO the number one problem with existing books is that they are far to
structured. I.e. "first we'll spend one chapter on functions, then one
on types, then one on laziness, then one on data types" etc. But that
means you can't really show off anything useful until the last
chapter! I think the problem is that most authors are academics, and
used to a very systematic way of explaining things - the problem is
that when Average Joe has read two chapters, he will want to try out
some ideas of his own, and if you haven't given him the basic tools to
do Real Stuff by then, he'll think the language isn't meant for real
world usage and that impression will stick.

Yes, monads are cool, but for Average Joe who doesn't give a hoot
about category theory we don't need too specific. And we REALLY don't
need to hold off on IO until chapter 18 because we feel that we
couldn't do the subject "justice" until then (again, there is no need
to explain it in detail right away).

For example, most books on C++ include plenty of operations on various
ostreams way before they actually explain how they work. As far as the
newbie is concerned, "cout" is a keyword that lets you print stuff,
and later on he'll realise that it's just a library.

So my point is that the book should give examples of REAL programs,
even if they're just small examples. Use IO when necessary and start
off by keeping it simple (e.g. "Haskell enforces that side effects are
kept separate from functions, thus we have both actions and functions"
- you don't need much more than that to begin with, just pretend that
the IO monad is "imperative haskell" and that the only weird thing
about Haskell is that you have to keep "imperative haskell" separate
from "pure haskell").

I find that many text books and tutorials hold off on this for far too
long which gives an impression that IO and all the "real world" stuff
is somehow difficult in Haskell. Ironically I think the reason is that
the authors are so excited about how elegant and nice it is in Haskell
that they feel the need to explore it in super high detail rather than
just gloss it over (hence they put it in chapter 18 when the reader is
familiar enough with Haskell to understand it).

This same thing goes for type classes and data types. If your first 10
examples use only tuples and lists, then that's what people will use
in their own programs. Use data types right away when it makes sense.
And type classes too, and explain each usage with increasing accuracy
until you get to the chapter dealing with it specifically at which
point you let loose with all the gritty details.

There must be some way of teaching Haskell "breadth first", so to speak. 



-- 
Professor Paul Hudak
Department of Computer Science    Office: (203) 432-1235
Yale University                   FAX:    (203) 432-0593
P.O. Box 208285                   email:  paul.hudak@yale.edu
New Haven, CT 06520-8285          WWW:    www.cs.yale.edu/~hudak