Why I am learning Haskell

I saw Simon Peyton-Jones talk on Software Transactional Memory at OSCON and was amazed at how neat it sounded. Taking some ideas from databases to remove some of the pain of multithreaded programming is a great idea. His point that a thread-safe Dequeue is a post-doc publishable result convinced me that something is wrong with the threading models in widespread use, while STM reduces it to an undergrad problem. The maping from the complexity of the problem domain to your code should be sane, if implementing a a simple structure like a dequeue using threads makes the code lots longer and requires a large amount of effort by someone with a doctorate, something is wrong. I love python, but multithreaded programs suffer (at least in the C implementation) because of the global interpretor lock (GIL). So I decided to learn Haskell.

There are (as far as I know) two ways of doing concurrency; shared state and message passing. STM is a neat syntax and smart compiler technology that ultimately uses shared state. See a Java or C# implementation here.

Erlang is becoming increasingly popular and big successes with high availability at Ericsson are compelling real world examples of its use. It uses message passing concurrency and is a nice (mostly) functional language. I am happy with the choice of Haskell though, the syntax seems neat (because of my maths background) and the functional purity enforces functional thinking more than (say) Common Lisp or OCaml. There was a great post today on Planet Haskell on concurrency options in Haskell and I am keen to explore them.

Maybe I will not hack in Haskell full time, but I think some of the ideas will go mainstream (already appearing in Linq and C# from Microsoft, who have bought in a lot of talented folk from the FP world ), but maybe I will.

It fits my mind well so far.