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