On Monad Tutorials

I recently read the opinion that reading monad tutorials prematurely does little good, and is the cause of much frustration*.  I've got to agree with this; I wasted a lot of time trying to understand monad tutorials before I was ready.  There are a bazillion blog posts out there that introduce the reader to monads, all studiously linked from reddit etc.  Some of them are fine and useful if you read them when you are ready. 

When are you ready?  When you

• have worked your way through Learn You a Haskell to the point where you've read its monad chapter
• are looking for another take on monads
• have some time to spend writing some monadic code.  

The previously mentioned "Write Yourself a Scheme" was a great opportunity to learn to write monadic code from a consumers' point of view.  Now I need to find a reason to write my first monad.

*I don't recall where, or I'd link it.   

"Write You a Scheme in 48 Hours"

I just finished Write Yourself a Scheme in 48 Hours.  How was it?

Well, it positions itself as a Haskell tutorial.  In that function, I think it fails miserably.  It uses many language features with no introduction or explanation.  Given how different Haskell is from the dominant programming languages, this works badly as a tutorial.  Other Haskell features are explained in the section after they were first used -- by the time you get to the explanation, you have already hit hoogle or another tutorial to find the explanation for yourself.  In short, it is in no danger of unseating Learn You a Haskell as the Haskell tutorial of choice.

However, when used as a set of exercises after completing LYAH, "Write Yourself a Scheme" does well, very well.  WYAS seems to be a work in progress, and exercises are missing for the latter few chapters.  But I found the first few sets of exercises very instructive. I did find myself referring often to outside resources, but it's clear that the author intends that -- and at this stage of learning, it's a good thing for me. 

Next up: Real World Haskell

Another SICP Post

As I read The Structure and Interpretation of Computer Programs, I've been thinking about the stuff I used to do in my Lisp days, and how it compares with the style of a Haskell program.  Most of the differences, directly or indirectly, seem to boil down to static vs. dynamic typing (even more than strict vs. lazy). For example, Lisp has great metaprogramming facilities (macros, "runtime macros" consisting of eval plus manipulation of parse trees).  Haskell has no features that are really like that kind of macro*, and certainly has nothing like the inherently dynamic eval --- but that doesn't mean that it lacks for features that let you do many of things you would do with macros and eval.

But that doesn't mean that Haskell has a nice way to do absolutely everything that you might choose to do in Lisp.  

A Simple Experiment ...

or not.

One of the things I like to do when I'm getting to learn a new compiler is to take a couple of very simple programs and look at the assembly that the compiler produces.  I tried this with GHC and the following program, add.hs:

add' x y = x + y

main = do
   print $ add' 1 2

The result of  ghc -S add.hs  was 301 lines of assembly code. Adding an explicit type annotation for add' brought it down to 252 lines, and the code was still beyond my meager ability to take in assembly.