Inspired by the recent discussions of what kinds of books would encourage the spread of Haskell, I whipped up a draft table of contents for "Haskell in a Nutshell." You can find it in PDF form at http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts embedded - OReilly uses a couple of oddballs) and in ASCII text at http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt. While there are page numbers attached, you should simply ignore those for the moment :-) Rather, I'd be interested in feedback on the structure etc. Oh, and please don't just rip it off and write it yourself :-) Like "Java in a Nutshell", the first part is a firehose description of the language. As Haskell is somewhat different from what most OReilly readers are used to, I've included a bit more about different ways you can run Haskell (which, incidentally, points out that it runs *everywhere*). Also like "Java in a Nutshell", the last part is a reference to common packages. The middle part is a bit different - a short "cookbook" of semi-practical programs addressing fairly common programming tasks - some of the kinds of things you'd typically do with Perl or C++. I think it needs more "recipes" of course, but I'd like to know if the general idea is working. Brook ps - for the curious, I have in fact written a textbook before (object-oriented programming for a first-semester course, from 1994...). And I'm using O'Reilly's FrameMaker templates, so the draft is "camera-ready" (hence the page numbers - the TOC is automatically generated).
Brook Conner <nellardo@concentric.net> wrote,
You can find it in PDF form at http://nellardo.com/lang/haskell/hianTOC.pdf (it should have the fonts embedded - OReilly uses a couple of oddballs) and in ASCII text at http://nellardo.com/lang/haskell/haskell-in-a-nutshellTOC.txt.
Makes sense to me. However, I would move IO further to the front. For any "real life" programming, IO is essential and, I think, it is bad for the image of Haskell to treat it as something dirty that is relegated to end of every (at least, many) introduction of Haskell. I have just given an Introduction to Computing course using Haskell and written a set of lecture notes, which introduce a couple of concepts (including IO) differently than commonly done. The whole stuff is at http://www.cse.unsw.edu.au/~cs1011/lectures/index.html Feel free to get inspiration from the material (except Weeks 8 - 10, which weren't given by me). You will find IO in Week 5. Note that I haven't used the word monad a single time. IMHO, monads are an advanced concept, IO is not. It's like you can introduce recursion without discussing stacks. If you understand stacks, you can gain a deeper understanding of recursion, but if you hear about recursion for the first time, the mention of stacks will only distract the average student.
The middle part is a bit different - a short "cookbook" of semi-practical programs addressing fairly common programming tasks - some of the kinds of things you'd typically do with Perl or C++. I think it needs more "recipes" of course, but I'd like to know if the general idea is working.
I think, that this is a good idea. Cheers, Manuel
However, I would move IO further to the front. For any "real life" programming, IO is essential...
I am currently teaching a Functional Programming lecture (notes in German: http://www.informatik.uni-leipzig.de/~joe/edu/ws00/praxis/skript/) and I also used this approach: use the do-notation intuitively (for text IO and graphics, using SOE book), and explain monads later (with parser combinators and interpreters). This could be driven to the extreme: not only hide the word "monad", but also "functional". The title would be "Imperative programming in Haskell" (as S. Peyton Jones says in Tackling the Awkward Squad: "Haskell is the world's finest imperative programming language"). The students would start writing do-notated programs in the IO monad, starting with putStrLn "Hello World"; and gradually the emphasis is shifted from sequencing (the "semicolon") to "what can we do on the righthand side of let x = ... ", thus introducing functional programming. Not sure if this is really a good idea, though... -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
Johannes Waldmann <joe@isun.informatik.uni-leipzig.de> wrote,
However, I would move IO further to the front. For any "real life" programming, IO is essential...
I am currently teaching a Functional Programming lecture (notes in German: http://www.informatik.uni-leipzig.de/~joe/edu/ws00/praxis/skript/) and I also used this approach: use the do-notation intuitively (for text IO and graphics, using SOE book), and explain monads later (with parser combinators and interpreters).
This could be driven to the extreme: not only hide the word "monad", but also "functional". The title would be "Imperative programming in Haskell" (as S. Peyton Jones says in Tackling the Awkward Squad: "Haskell is the world's finest imperative programming language").
The students would start writing do-notated programs in the IO monad, starting with putStrLn "Hello World"; and gradually the emphasis is shifted from sequencing (the "semicolon") to "what can we do on the righthand side of let x = ... ", thus introducing functional programming.
Starting with putStrLn "Hello World" is a good idea and this would exactly be my approach when teaching students who already know some programming language (in the course I did last term, it was their first programming experience; therefore, I waited until Week 5). However, I don't think it is necessary (or desirable) to hide "functional". With "monad" it is a different story, as it is a complicated sounding word, which is not easily explained (to non-mathematicians). And it is not necessary; we are not starting on fixed point and domain theory either when explaining recursive functions. Actually, I did run a moderately detailed survey at the end about what the students found interesting/boring and difficult/easy etc (and with a good sample size, too: close to 500 students filled in the survey). I am planing to summarise the results and post them here sometime. Cheers, Manuel
On Tue, 9 Jan 2001 09:00:27 +0100 (MET) Johannes Waldmann <joe@isun.informatik.uni-leipzig.de> wrote:
[snip]
This could be driven to the extreme: not only hide the word "monad", but also "functional". The title would be "Imperative programming in Haskell" (as S. Peyton Jones says in Tackling the Awkward Squad: "Haskell is the world's finest imperative programming language").
Couldn't this choice potentially backfire, though? For example, many people choose Java over C because they prefer OO to straight imperative programming, which they see at The Old Way. If I went to a bookstore and saw one book entitled, "Imperative Programming in Haskell," and another entitled, "OO Programming in Java," I wouldn't buy the Haskell book, especially if had already had a bad experience with imperative programming in C. How about, "The Post-OO Age: Haskell: Back to the Future in Imperative Programming"? --Ben -- Benjamin L. Russell russell@brainlink.com benjamin.russell.es.94@aya.yale.edu "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho
participants (4)
-
Benjamin L. Russell -
Brook Conner -
Johannes Waldmann -
Manuel M. T. Chakravarty