Introduction

A while ago, after what now seems like eternity of flirting with Haskell articles and papers, I finally crossed the boundary between theory and practice and downloaded a Haskell compiler. I decided to do a field evaluation of the language by two means. I was going to solve a problem in a domain that Haskell is known to excel at followed by a real world problem [1] that hasn't had much exploration in Haskell [2]. Picking the problems was easy. There's a lot of folklore that suggests Haskell is great for building compilers and interpreters so I didn't have to think long to a pick a problem that would be self contained, reasonably short, and fun - writing an interpreter of a Lisp dialect. For the second test case I decided to go with a web application - plenty of people are writing them for money and there hasn't been much Haskell-related work done in this area.

I've now completed the first test case and the results are incredibly promising. I was able to write an interpreter that can evaluate many of the examples from my lisp article in 188 lines of reasonably well designed, extensible, commented Haskell code. I made no effort to squeeze functionality into as few lines of code as possible, furthermore, because I am new to Haskell the code is probably much longer than it normally would be.

Beyond a doubt, Haskell is incredibly expressive. I could get far more functionality in with far less typing than I've normally come to expect of mainstream languages and I still had code that was easy to extend and modify. After getting such impressive results I had to tell the world. I quickly jot down the first draft of this article and immediately discarded it because I realized I'm preaching to the choir: people that use Haskell would already know what I was about to tell them and people that don't use it would find lines of code to be a terrible benchmark to draw any valuable conclusions from (and they'd be right).

You're now reading the second draft of this article which is about much more than the results of my first experiment. The article is about my experience with Haskell and the process of working with it. I will describe which features of Haskell I used to implement particular aspects of my interpreter, how they're different from the object oriented world, why they helped me get things done faster, and how I had to change my program whenever my initial efforts took me to a dead end. While the jury's still out how well Haskell performs in other domains (I'm just starting my web application project) I hope this article sparks your interest in this beautiful language and explains some things programmers new to Haskell often find confusing.

[1] By "real world problem" I mean a problem that a reasonably large number of people gets paid for solving every day.

[2] There don't seem to be any definitive sources that suggest Haskell isn't good at something.