Big Haskell Projects List

posted Feb 19, 2007
in Programming

On, I have referred to a list of Big Haskell Projects I'm keeping. I've been keeping it in my head, because it's been short, but I thought I should go ahead and start actually keeping one.

Haskell as a language intrigues me, but I can't help but notice that there aren't a lot of large projects that use it. My intuition suggests that this could be difficult, because I suspect the type system may become increasingly unwieldy. I once asked about this directly, and the results were less than impressive. I'm asking for examples of large projects because concrete results trump my intuition.

In the interests of honesty and transparency, I'm actually going to keep this list in a public place and try to keep it updated as people suggest things until either A: It satisfies me and I start trying to learn Haskell or B: It becomes too much of a time sink, which would basically mean that there are a lot of large projects. That is, my goal is not to keep a list in perpetuity, but just until the point is made.

Update March 8, 2007: This has been up for three weeks now and attracted some attention from some people who really ought to know. I'm willing to say now that pending further updates, I see no compelling reason to believe that Haskell is practical for larger projects. Furthermore, Haskell arrogance is totally unjustified by evidence. It may someday be proven a compelling choice for Real Programming, but there isn't even any significant evidence of that, let alone enough to justify arrogance.

If you want to add to this list, either comment to me on, email me (no spam padding, I lost that battle five years ago), or drop a comment here. (Note that I like to keep my comments clean, so if your comment is just a word and a link, I'll pull the credit up into the body here and delete the comment; don't feel bad, I think it's promotion. :) )

The initial criteria were: "A useful project that required more than a man-year at full employment (40-hours a week) to create." If you are in doubt, don't suggest it; the point is to have a list of the strong stuff, not a long list of dubious (and thereby unconvincing) stuff.

I've subsequently added: "Must have some actual users, not just the developers." This is because projects can continue on sheer force of will, and that doesn't prove suitability for anything. I would also kick out academic-only projects, except that criterion mostly takes care of that.

To take it one meta, consider the following two statements:

I'm looking for evidence that the latter is true, in the form of significant-scoped projects that at least prove Haskell is a viable choice. (It's borderline impossible to ever prove it's the best, so I use this standard as the best proxy.) I don't dispute the weak claim, so the mere enumeration of academic projects, small libraries, or toy projects aren't interesting to me, and I don't think they constitute significant evidence for the second claim. Many people freely conflate the two, generally by arguing for the strong claim, but providing evidence for the weak claim. (This is not unique to Haskell; probably all advocates of a borderline language do it.)

Big Haskell Projects

For each value judgement, assume it is my opinion and my opinion alone. Your milage will vary.

Haskell Compilers

I'm separating these, because they don't count for much in proving that Haskell is useful for large projects, not because they aren't large projects, but because pretty much by definition anybody building a Haskell compiler is a thorough expert on Haskell. Any putatively general-purpose language where experts are incapable of implementing the compiler in terms of the language itself is utterly useless; the contrapositive of this statement will show why this is such a low standard. But I will admit it still proves something.

Considered And Rejected

(At least for now.)

Note that being "rejected" implies nothing about the goodness or badness of the project; it just means that I don't think it proves large-scale viability.


augustss, David MacIver (in my comments).


Site Links


All Posts