If I Were Given a Re-do from the Beginning

I'll get to the title topic in just a minute.   But first, more about Real World Haskell.  Currently I'm a little more than halfway through the book, and still liking it quite a lot.  I'm currently halfway through the "Programming With Monads" chapter.  I'm feeling that this chapter is a little dense with text and that more incremental baby-steps exercises would do it some good.  Certainly they would do me some good.  So I'm stopping where I am until I have time to sit down and write some more monadic code.  I imagine it will take a few repetitions until I'm comfortable with it, but that seems like a fundamental skill if you want to write Haskell. 

Now for the main feature: if I had to do it all over again, here's what I would do to learn Haskell from scratch:

• Start by reading Learn You A Haskell.  All the way through.  
• Really get into some code with Write Yourself a Scheme. 
• Read Read World Haskell from the very beginning, and don't skim through the earlier chapters; they have a different and useful way of presenting the basics.  Yet I wouldn't start here; I learn best when I see a topic from a couple of different directions. I have the dead tree version of the book but there's a free PDF available here.

And here's what I would not do:

• Read Monad tutorials early in the learning process.  I wouldn't recommend it before reaching the monad chapter in Real World Haskell.  First of all, the monad sections in Learn You A Haskell and Real World Haskell are quite good.  Second, monad tutorials are more effective if they are immediately reinforced by some coding exercises. I think the best path to understanding monads is by using the damn things. 
• Read any type theory content until . . . well, past where I am now.  I have read some of this stuff and have yet to see any useful connection to actual Haskell code.  I'm sure I'll get there eventually, but I'm not there yet. 
• Do not start Haskell School of Expression unless you first find the source code and get it running. 

Finally, there's something I might do: read The Haskell Road to Maths, Logic, and Programming.  That book is rather less a book about programming Haskell and more a book about the foundations of mathematics.  If that sounds interesting, then the exercises in the book are a nice way to get some coding practice as you are coming up to speed in Haskell.

Getting More from the Type System

This blog post from Tony Morris really got me thinking about the advantages of a powerful static type system like Haskell's.  That blog post (along with others such as this one) are great pointers for getting the most mileage from the type system.

When I first started with Haskell, I was pleased with the effect that the type system had on the code-test-debug-refactor cycle by keeping the type errors at compile time -- yet not requiring lots of tedious, error-prone boilerplate to support that.  I found that code was much more likely to work with minimal debugging.  Along with the conciseness of the code, this made for a more engaging and satisfying experience at the "hacking" level.  This is more than enough reason to learn Haskell. 

But what I wasn't yet seeing was how to take it to the next level and exploit the type system at the design stage.  Those two blog posts are great examples of how to use the type system at design time.  I coded up a Haskell solution to Morris' exercise, and it was some time well spent.  Example code is below the cut, and I think it's a great little package that shows very directly how Haskell's type system adds value.