mult.ifario.us

Duncan Coutts posted some slides from ICFP about the developing Haskell platform — a set of "known good" and well-maintained libraries — and it is indeed on its way. (Compare with the "batteries included" effort for OCaml.) Here's the stack from slide 13:

It's not in the charter for the Haskell Platform to make general improvements to Hackage, but looking at the stack diagram I couldn't help but thing about a comparison against a language stack like Java (JDK, Maven, Codehaus, JCP) or Ruby (C ruby, rake, RubyGems, RubyForge) instead of Linux. Quality, collaboration, and liveness are important aspects to assess for a project, but that's next to impossible without publicly accessible (and relatively standardized) bug tracking, source control, and discussion. (Things like continuous integration are niceties but provide somewhat lower utility than the big three I just mentioned.) With 754 libraries, there's a lot of meat and a lot of mystery that's impossible to assess at a glance from the current HackageDB package list web interface. The "heuristic" requirements for libraries in the Haskell platform does include a bug tracker and good basic hygeine (build portably with standard tools, proper releases, maintainer), but it's missing those other touchpoints.

Lest I be perceived as casting stones, my experience is that even in the current circumstances and in spite of the lack of visibility, the Haskell community is vibrant and active. The Cafe and IRC are bustling, and troll-free and flame-free with very rare exceptions. Community leaders are friendly and approachable. Where I've found issues with libraries (resource leak in HTTP, QName equality bug in HXT, attribute qualification issue in "light" xml), maintainers have been helpful and receptive. It would be even better if it was straightforward to collaborate with other users on dedicated mailing lists, post or consume bug fixes via darcs or git branches (the good kind of fork), and track updates. (Use of distributed VCS tools like Darcs and git exponentially increases the utility of a publicly available project VCS.) There is no reason that this should be limited to just a blessed core, as it will help in the growth and refinement of other libraries as well. Posting to Hackage should entail the creation of a mailing list, the provisioning of a bug tracker, and either a check-in of the source for the posted library to a central repository or a reference to a publicly available git or darcs repository.

More than most and less than some, I appreciate the difficulties in providing community infrastructure, having observed Bob and Ben in action at the Haus and watched a top-level project at Apache (ODE) from proposal through graduation. I also appreciate the role of the infrastructure in creating and reinforcing community — it's no accident that a fair proportion of the most widely used open souce libraries on the Java platform have grown either at Apache or at the Codehaus.

It looks like SUN's serious about open sourcing Java, where Java means the JDK. Among the various languages that I use, I could count the number of times that I've looked at the source code for Ruby, Python, Perl, GCC, GCL, and GHC on the fingers of an absent-minded stonemason, and almost all of those times have been when I wanted to compile something bleeding edge on an obscure operating system. Diving into a highly complex codebase and making positive changes simply isn't done. The SUN JVMs are already open enough for my taste. The JVMTI is available as a plug-in point, and the source code for the Java standard libraries is available.

Will "open source Java" prevent cruft from getting into the standard libraries for Java or evict some of the current dross and detritus? Will it save us from the next EJB or Crimson? Strip the Java standard libraries down to a minimal subset of what they currently contain, don't put it back, provide a great package manager, and that's open enough for me.