Learning Haskell and FP
Patrick M Doane
Fri, 5 Jan 2001 10:26:19 -0500 (EST)
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
I think a really good beginner's tutorial on I/O could be started from this
- 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
- 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
Any thoughts? I could take a first stab at this if people think it would
be a useful direction.