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

[Paul Hudak]

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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] New Haven, CT 06520-8285 WWW: www.cs.yale.edu/~hudak

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe