Archive for July 2011

What’s Wrong with Learning Haskell

July 22, 2011
The Haskell Logo. There’s also a public domain...

Image via Wikipedia

This is in response to the recent State of  Haskell survey. They asked what Haskell’s main weakness or blind spot was and I couldn’t stop typing. Instead of leaving a comment on the survey, I thought I’d write it down here.

First of all, I like Haskell a lot. I’m the Thompson in “Thompson-Wheeler Logo.” That cute shape that cleverly combines the lambda and monad bind shapes? My idea. The irony is not lost on me. That Haskell logo of mine is used all over the world, and yet I’m barely a mediocre Haskell programmer.

I’m getting better at using Haskell to accomplish things I care about. But I think my experience in learning the language has been a little harder than it needed to be. I don’t want to imply that this is anyone’s fault but my own. But perhaps my experience can serve as a warning to someone. See that hole? It is, indeed, a dark hole. It is not of interest to you, programmer.

In order to communicate not only to programmers like me but also to some of the Haskell “formalists,” I’ll try to map my informal statements to some formal writing tools. Now I’ll be the first to admit that all the pairs in the mapping will contain informal terms, which ruins the formality of it all. Hopefully you formal folks will find it helpful. If you didn’t or barely understood that, it wasn’t for you, which is a point we’ll revisit many times here.


I’ve been around a lot of language communities. Haskell’s is my clear favorite. Haskell people are happy and helpful, which is unheard of for a programming community.

Despite this, for me it has still often been difficult to find answers to my questions. I think this is largely due to the fact that, when discussing things with the average (serious) Haskell programmer, I feel like I have a fourth grade education. I took some discrete math as part of my CS education, but I have too little math background to understand a lot of what I hear.

I think especially early on that I could have had an easier time. Some mechanism to steer me away from some Haskell resources would have helped. I’m not sure what that mechanism might have looked like, so I handwave over the details here. Perhaps you formalists know handwaving over the details as the “Axiom of Choice,” no? I hearby invoke it.

For instance, (Or in formal terms, Example 1.1)  I tried to get in tune with the current practice of Haskell by lurking on Haskell-Cafe. It worked when I was learning Ruby. Not here. This was a bad idea. I learned nothing and it made me feel bad. Yeah, poor me.

Another time (Example 1.2) I tried to read the Comonad Reader blog. Another bad idea.

As a relative Haskell newbie, whose not-Haskell day job is web development, integrating systems, build engineering, tormenting managers, and sometimes just writing a lot shell scripts, Haskell-Cafe and the Comonad Reader are, and this important, don’t miss this: not for me.

Let’s be a bit more formal and state this as an axiom.

(Axiom 1) Again, I’m not sure how I could have known this, but it would have been nice if there was some way (Axiom of Choice?) that I could have known that these resources were, here it is: not for me. Those are for other people with different backgrounds and extremely different goals. We’ll call this the Axiom of Not for You. The italics are important. We don’t want confuse this axiom with the similar axioms of not for you, not for you, or the less emphatic not for you. This is the Axiom of not for you.

(Axiom 2) Despite the relatively small size of Haskell community compared to others, it’s ratio of diversity to headcount is higher than one might expect coming from, say, the Ruby community. This the Axiom of Not All Haskell Programs are Programs.

(Example 1.3) For instance, I’m a Ruby programmer. As someone who does his share of Ruby programming, I can take anything I read about Ruby and understand what it means to me.

And it’s easy to see why. Because at the end of the day, when people write Ruby programs, they are hoping to end up with a program. It’s is a program. You feed it to a computer which runs it. The computer, as a result does some useful work. I understand that.

Works on My MachineBut, it turns out, Not All Haskell Programs are Programs. There are people, I kid you not, who write these super elaborate Haskell programs, compile them, and consider their work done. I know. Inconceivable! They don’t even get a “Works on My Machine” sticker, because they don’t even know!

But when you understand that Not All Haskell Programs are Programs, it’s perfectly clear. Apparently those programs are really proofs encoded into Haskell’s type system, which is neat. If it compiles, and if you followed a few rules and understand a little Denotational Semantics, well then, you win! Yay! I can’t begin to tell you how happy I am for you. But the Axiom of Not for You applies here. I don’t need to understand that proof, maybe not ever. Those people are not programming, they are proving stuff. Proving stuff is not programming. Curry-Howard isomorphism notwithstanding, for my practical purposes, proofs are not programs.

(Example 1.4) Imagine that a nice girl with a dual background in programming in Haskell and driving steam rollers realized one day that some Haskell programs are steam rollers, and could, in fact, be used to steam roll. Roads. She also has a blog and writes this up. I stumble across this article. Using the previous axioms I would clearly understand that while it is an interesting and possibly revolutionary discovery that some Haskell programs can be used to steam roll, steam rolling is not programming. A steam roller is not a program and applications of steam rolling are not for me.

As to the mechanism to solve this, I think we need to realize that there are some workaday programmers like me looking to get a leg up on some of our harder problems. We value Haskell’s type system. Watching a program work perfectly the first time it compiles is a foreign yet pleasant experience. Getting more reliable code with less unit testing overhead is fabulous. Quick check is so neat I ported it to JavaScript.  And having an LOC count the size of a Python program but running with the performance of a C++ program is what motivated me to look at Haskell in the first place. Even slow unoptimized Haskell seems scary fast to me.

But, people like me need to be both steered to right learning resources, such as Learn You a Haskell or Real World Haskell, and steered away from the writings of Logicians and Type Theoreticians. My problem was that, not only did those two good books not exist yet, there wasn’t, and still isn’t, a mechanism to steer workaday programmers like me away from stuff we aren’t ready for yet.

So my humble suggestion, in all seriousness, is for the community to help the noobs not only with positive advice, like read LYAH, but also to steer clear of, or at least not worry about, say, automatic differentiation of types.

Thanks for reading.