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

[Sebastian Sylvan]

On 12/11/06, Kirsten Chevalier <catamorphism at 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.

-- 
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862