On programming.reddit.com, 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 programming.reddit.com, 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:
- Weak Haskell Claim: Haskell is useful for something. Some people should learn it.
- Strong Haskell Claim: Haskell is the best language for a wide variety of projects. Everybody should learn and use Haskell, because it's the best engineering choice.
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.
- darcs: Distributed open source code management system. Interesting (to my mind) primarily because of its implementation of a particular patch theory, which might explain why a functional language is a big win for darcs.
- Pugs: The Perl6 implementation in Haskell. I still intuitively feel like a language implementation counts for less, but this does count for more than GHC. Enough language implementations might add up to "a language useful for implementing other languages", which does not interest me personally. (credit ayrnieu)
- augustss suggests Bluespec, and later assures me it is primarily Haskell.
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.
- GHC: The Glasgow Haskell Compiler, which if I am not mistaken is the Canonical Haskell Compiler and interpreter, is written in Haskell.
- yhc: York Haskell Compiler.
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.
- jhc - "Although jhc is not ready for general use, I think some of its ideas or code might be useful to other people so I am deciding to release it in this state." from here does not say "big project with users" to me.
- Cryptol: I'm not convinced this is a big project, and I'm a little concerned that there doesn't seem to be any way to obtain the product? (I don't just mean "no download link", I mean there's nothing, not "how to buy", not "where to find", nothing.) The manual I could find does not strike me as describing a particularly large project; it looks like the sort of thing where the documentation is about three times larger than the project itself.
- What appear to be pure academic projects: pH
- What appear to be dead projects: Lolita (aside: worst project name ever)
- HAppS: Oct 1, 2007 - I've started using HAppS for a personal project, but I can already tell, it's far too early to hold this up as a shining example of a successful Haskell project. It may meet my time criterion, but it is effectively undocumented and barely installable.
augustss, David MacIver (in my comments).