Learning Haskell and FP

[Patrick M Doane]

On Wed, 3 Jan 2001, Simon Peyton-Jones wrote:

> I'm sure that's right. Trouble is, we're the last people qualified
> to write one!  
> 
> Here's a suggestion: would someone like to write such a guide,
> from the point of view of a beginner, leaving blanks that we can fill in,
> when you come across a task or issue you don't know the answer
> to?  That is, you provide the skeleton, and we fill in the blanks.

I read your paper on taming the Awkward Squad several months ago as my
first exposure to Haskell. I think it is an excellent paper and really
convinced me that Haskell was worthwhile to learn and use. 

There are aspects to the paper that are like a tutorial, but I think it
would be overwhelming for a programmer not used to reading papers from  
academia.

I think a really good beginner's tutorial on I/O could be started from this
paper:

   - Start immediately with using the 'do expression' and don't
     worry about the history that led to its development.

   - Avoid mentioning 'monad' and other mathematical terms until much
     latter in the game. It is better to see the system in action and then
     find out it has a nice solid foundation.

     Many people are also annoyed by an author using new vocabulary even
     if it is well defined. It's better to get them comfortable with the
     system first.

   - Take advantage of the 2d syntax rules to avoid the unneeded braces
     and semicolons. Syntax with little punctuation seems to go a long way
     with many programmers. Pointing out the similarities to Python here 
     could be appropriate.

   - After working through several examples, show that the 'do expression'
     is short hand for some more basic primitive operators. These
     can be more appropriate to use in some circumstances.

   - Conclude with explaining the difference between executing an action
     and building a value to execute the action. There is no need to
     point out that this is a requirement of being a lazy language.
     Instead point out the benefits such a system provides to back up 
     the claim that Haskell truly is "the world's finest
     imperative programming language."

Some points would still be difficult to get through:

   - Explaining the type system. There is no avoiding this, and users
     will have to learn it.

   - Working through the difference between 'unit' and 'void'.
     Perhaps this can be avoided in a beginning tutorial. A possible
     confusing example in the paper is that of composing putChar twice 
     while throwing away the result. People used to C or Java might
     immediately think "but it doesn't  have a result to through away!"

   - Some amount of understanding for Haskell expressions is going to be
     needed to understand examples. An I/O centric tutorial would want
     to explain as things go along as needed.

I would avoid other parts of the paper for a first attempt at some new
tutorial material.

Any thoughts? I could take a first stab at this if people think it would
be a useful direction.

Patrick