<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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! :-)<br>
<br>
While I'm at it, I have a couple of other general comments:<br>
<br>
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.<br>
<br>
Maybe some of you can do better, but it's really tough to show someone
how an <i>advanced</i> Haskell programmer would solve <i>advanced </i>problems
that arise in the real world. As a simple example, I love this recent
quote by Garrett Morris:<br>
<br>
"I'm personally fond of framing most non-trivial Haskell problems as<br>
defining domain specific languages; as a result, everything over
about<br>
200 lines that I've written in the past 3 years has used the mtl
[Monad<br>
Transformer Library] in
some form or fashion. It's great."<br>
<br>
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.<br>
<br>
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."<br>
<br>
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!<br>
<br>
-Paul
Hudak<br>
<br>
<br>
Sebastian Sylvan wrote:
<blockquote
cite="mid3d96ac180612111243w4c2cc1f9p25e0fc2c610ac4a5@mail.gmail.com"
type="cite">On 12/11/06, Kirsten Chevalier
<a class="moz-txt-link-rfc2396E" href="mailto:catamorphism@gmail.com"><catamorphism@gmail.com></a> wrote:
<br>
<blockquote type="cite">It's not as if this is the first time that
this has been suggested,
<br>
but some people have suggested that a practical book about Haskell
<br>
would be a good idea. I agree. Some people have also suggested that
<br>
the right moment for this hasn't arrived yet, and I see that as a
<br>
challenge.
<br>
</blockquote>
<br>
IMO the number one problem with existing books is that they are far to
<br>
structured. I.e. "first we'll spend one chapter on functions, then one
<br>
on types, then one on laziness, then one on data types" etc. But that
<br>
means you can't really show off anything useful until the last
<br>
chapter! I think the problem is that most authors are academics, and
<br>
used to a very systematic way of explaining things - the problem is
<br>
that when Average Joe has read two chapters, he will want to try out
<br>
some ideas of his own, and if you haven't given him the basic tools to
<br>
do Real Stuff by then, he'll think the language isn't meant for real
<br>
world usage and that impression will stick.
<br>
<br>
Yes, monads are cool, but for Average Joe who doesn't give a hoot
<br>
about category theory we don't need too specific. And we REALLY don't
<br>
need to hold off on IO until chapter 18 because we feel that we
<br>
couldn't do the subject "justice" until then (again, there is no need
<br>
to explain it in detail right away).
<br>
<br>
For example, most books on C++ include plenty of operations on various
<br>
ostreams way before they actually explain how they work. As far as the
<br>
newbie is concerned, "cout" is a keyword that lets you print stuff,
<br>
and later on he'll realise that it's just a library.
<br>
<br>
So my point is that the book should give examples of REAL programs,
<br>
even if they're just small examples. Use IO when necessary and start
<br>
off by keeping it simple (e.g. "Haskell enforces that side effects are
<br>
kept separate from functions, thus we have both actions and functions"
<br>
- you don't need much more than that to begin with, just pretend that
<br>
the IO monad is "imperative haskell" and that the only weird thing
<br>
about Haskell is that you have to keep "imperative haskell" separate
<br>
from "pure haskell").
<br>
<br>
I find that many text books and tutorials hold off on this for far too
<br>
long which gives an impression that IO and all the "real world" stuff
<br>
is somehow difficult in Haskell. Ironically I think the reason is that
<br>
the authors are so excited about how elegant and nice it is in Haskell
<br>
that they feel the need to explore it in super high detail rather than
<br>
just gloss it over (hence they put it in chapter 18 when the reader is
<br>
familiar enough with Haskell to understand it).
<br>
<br>
This same thing goes for type classes and data types. If your first 10
<br>
examples use only tuples and lists, then that's what people will use
<br>
in their own programs. Use data types right away when it makes sense.
<br>
And type classes too, and explain each usage with increasing accuracy
<br>
until you get to the chapter dealing with it specifically at which
<br>
point you let loose with all the gritty details.
<br>
<br>
There must be some way of teaching Haskell "breadth first", so to
speak.
<br>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Professor Paul Hudak
Department of Computer Science Office: (203) 432-1235
Yale University FAX: (203) 432-0593
P.O. Box 208285 email: <a class="moz-txt-link-abbreviated" href="mailto:paul.hudak@yale.edu">paul.hudak@yale.edu</a>
New Haven, CT 06520-8285 WWW: <a class="moz-txt-link-abbreviated" href="http://www.cs.yale.edu/~hudak">www.cs.yale.edu/~hudak</a>
</pre>
</body>
</html>