The maze book for programmers!

Algorithms, circle mazes, hex grids, masking, weaving, braiding, 3D and 4D grids, spheres, and more!

DRM-Free Ebook

The Buckblog

assorted ramblings by Jamis Buck

Learning Haskell

30 October 2005 — 2-minute read

So, I finally had a little time this weekend to try and get back into a habit I had unfortunately fallen out of—learning at least one new programming language each year.

Haskell is one language I’ve been meaning to investigate. I’ve actually tried to pick it up a few times, but it has some pretty high barriers to entry:

  • There are several implementations available, without any good recommendations of which one to use. (I finally went and grabbed GHC, because darcs requires it and I wanted to give darcs a try.)
  • GHC takes forever to install from source. Many, many hours. If there is a precompiled binary for your platform, I’d highly recommend grabbing it.
  • Until quite recently, there have been no good online tutorials for learning Haskell. Even A Gentle Introduction to Haskell is anything but. (Brian Mitchell once explained to me that it is gentle compared to the highly academic Haskell Report, which it supplements.)
  • As a functional language, it is significantly different from most other languages I’ve ever used. Thus, without a good tutorial it was hard for me to wrap my brain around it.

Fortunately, I stumbled upon A Haskell Tutorial for C Programmers, which was finally what I needed to break into Haskell programming. It covers all the major bases, and gives you just enough background to go in and start reading the other tutorials.

Anyway, I’m excited to start learning Haskell. I certainly doubt it’ll replace Ruby as my language of preference, but it’s always good to step back and get a new perspective on the art and science of computer programming.

Reader Comments

Here are some things to think about when learning Haskell: Lazy (rather, non-strict) evaluation in Haskell is quite an impressive change-of-pace from most of what else is out there. In my experience it makes code easier to reason about for the programmer, but sometimes less so for the compiler. The effects of this are far reaching in the positive arena, but it is important to note that lazy evaluation comes with a significant performance price tag in the general case, although laziness also allows for interesting fusion and deforestation of and between intermediate data structures in other algorithms. A type-polymorphic language, as opposed to an ad-hoc polymorphic language such as C++ or Java, is substantially better suited to abstration. Conversely, it forces the programmer to think in a structured way which contributes to a substantial learning curve. Haskell has a complicated type system, and considering popular extensions like multi-parameter type classes and functional dependencies, it is becoming more complicated regularly. However, things like type classes (multi-parameter or not), monads, functional dependencies, GATDs, etc. find their uses within any programmer's tool belt and are quickly indispensible. I imagine the reasearch currently being done in the field of type theory will produce a number of real winners, and will become encoded in a semantic that is approachable in a less rigorous way, but the trend right now is to reach in every possible dimension for research in PLT/type theory. Note the trend from Miranda to Epigram in lazy functional programming languages. I don't mean to say that Haskell is the best possible language. These are just a few things to think about when or before attempting to learn Haskell. I experienced a fairly rapid understanding of the "big picture" of functional programming, and I believe that most programmers will quickly see the immediate benefits of a language like Haskell, and through a substantial effort and with the help of very smart and kind people at the IRC channel ( and the wiki (, I have come to find that for the most part, the promises made were filled, and those that weren't were the focus of exciting research that has kept me continuously enthralled in things I could never before have imagined. Sorry for the rant! I hope my vague oppinions are of use to those just beginning in Haskell, as I hope they are.
"Yet Another Haskell Tutorial" is another excellent place to start.
This immortal gem from the "Gentle Introduction" made it into my quotefile: If k1 and k2 are kinds, then k1->k2 is the kind of types that take a type of kind k1 and return a type of kind k2.