Haskell (even with the GHC extensions) seems pretty stable, but the greater GHC platform seems pretty unstable. I’ve already written about how we’re [sorta] missing a vital part of the tool chain (it was broken when I tried to build it using 6.10 the other day), but in this post I’ll focus on Haskell’s libraries (especially user generated ones).
After fairly heavy usage of Haskell over the past few months, I exit 2008 thinking that, while Haskell is a wonderful language, the library situation with GHC prevents GHC from being more heavily used. Unless you’re writing completely custom software, it can be very difficult to try a piece of Haskell software. One of the reasons Rails is so successful is that it Just Installs and the tutorials are Just That Easy. OTOH, when I start to install a new package in GHC, I never quite know what will happen.
Here are some problems I’ve had with Haskell’s libraries over the past few months/years along with possible fixes for those issues:
- Hackage != Haskell Library Repository: Hackage doesn’t necessarily contain the latest and greatest versions of a library. For example, harp on Hackage is V0.2, but harp on code.haskell.org is V0.4.
- This could most easily be fixed by automating the pulling of code from repos. Since harp is located at code.haskell.org/hsp/harp, Hackage could automatically pull code and build packages from there.
- The Hackage team has put together a great system. It seems fair that they have T.O.S. which keeps Hackage usable and clean. Part of the TOS would be that a package maintainer: keep the package up to date in Hackage; respond to e-mails; notify the Hackage team if the maintainer is abandoning the package.
- 6.10 ‘base’ Library Reorg: the base library reorg looks good, but it changes around a lot of the … er … basic libraries of the system.
- Not sure of a fix here. Seems like a nice reorg and if base weren’t reorged, I’d probably be bitching about the need to reorg base… Here’s to hoping we don’t go through another base reorg any time soon.
- Bit-rotted Libraries: Libraries exist in Hackage which won’t build and which will probably never build. For example, HaskellDB is an awe-inspiring library… that hasn’t built since 6.6 and just isn’t going to build any time soon. As a newbie looking for a database library, HaskellDB would be the obvious first place to look and trying to use it would produce serious frustration (it certainly did for me). It’s nice to have a historical reference to HaskellDB in Hackage, but the package shouldn’t be listed as currently usable. Maybe it’d be sufficient to default to filtering by the latest GHC version.
- Given Don’s post, it might not be too difficult to script weekly library builds and auto-email library maintainers about their library being broken. After a few missed e-mails, the library could be shifted to another maintainer or, at worst, deprecated.
- Gripe about git as much as you like, but GitHub has done a great job of building an environment for ‘social coding’. Using something like GitHub would make it easy to: allow those-who-want-to-work-on-a-library to do so; move a package to a new library maintainer; provide a consistent location from which Hackage could pull code. FWIW, Rails has gone this direction…
Haskell is an awesome language. I’m a big fan (as evinced by Turbinado). Working with Haskell has forced me to think about coding in a new way and has seriously improved my coding ability. However, Haskell has also proved enormously frustrating as I try to put together a project which depends on many libraries.
A great way to increase the visibility and usage of Haskell is to make it easy to develop and build complex software in Haskell. Naturally, that requires a robust set of user libraries and that seems to require Hackage. So let’s make 2009 the Year of Hackage.
Over on reddit, Don suggests we make “2009: the year distros start supporting the platform”. enauv replies that “[GHC is] too radical and changes too quickly for platforms to truly support it.” I tend to agree with enauv, so much so that this post was originally titled “2009: GHC 6.10 LTS?” because GHC (the overall platform) does tend to change too quickly for distros to support it effectively. Maybe GHC needs to migrate GHC to Long Term Support and move bleeding edge stuff to GHC 7.0?
This post is written by a practicioner and not by an academic. I understand that Haskell is an ‘academic’ language, but Haskell has gotten popular enough that it’s no longer ‘academic’ and that’s the greatest compliment a language could receive.
How am I going to solve the library dependency problem in Turbinado? I’m going to bundle all libraries on which Turbinado depends into Turbinado. Not a solution I like, but it’s one that works…