[tlug] Darcs and the Lack of Haskell Programmers

[Curt Sampson <cjs@example.com>]

An initial note: this is cross-posted to both the Tokyo Linux Users'
Group mailing list and the Darcs list. I've set the Reply-To header to
myself only. The TLUG list is configured to replace that with the TLUG
list, which is fine. I'm not sure what the Darcs list will do. At any
rate, be conscious of where you want to send your replies.

On 2008-08-02 12:46 +0900 (Sat), Stephen J. Turnbull wrote:

> It seems from the comments of various people that there just aren't
> that many Haskell programmers around, not even at the GHC project. I'm
> not sure whose argument that favors, mine (on the argument that Google
> should wait around until there are Haskell programmers who can be paid
> to work on the appropriate things) or Curt's (on the argument that it
> takes so long to raise up Haskell programmers that anybody who wants
> to have one in five years should

I think that this particular issue is misleading, and the problem here,
while excacerbated by the relatively small number of Haskell programers
available, is something different.

As you pointed out somewhere quite a while back, Stephen, a revision
control system is a pretty special case of software. It's rather more
complex than, say, a web framework both in that the code is harder
to write (this is very close to, if not actually, Brooks' accidental
complexity), and that the problem itself is a difficult one (essential
complexity). So that's one part of the issue.

But there's another side to this too, which only came to me after using
darcs in anger on a couple of projects. (For our non-native-English
readers, that means, more or less, "using it on a project for real,"
where it causes problems for your project if it doesn't work, as opposed
to using it as an experiment to learn about it.) It turns out that
different development styles need different forms of revision control.

This is why I recently moved a new project (written in Haskell) that
some of us had started from Darcs to Subversion (which is Starling's
standard RCS): it works better with our development style.

We generally do what might be called "distributed integration": every
developer, upon making a change, is responsible for making sure that
that change is releasable, he needs to integrate it into whatever
branches are going to have it in a release, do all testing necessary,
and make sure that if we rolled those branches out into production right
now, it's going to work. This is a pretty standard Extreme Programming
practice; probably some other agile folks use it too.

Somewhere in all of the original XP books and such that I read,
someone, probably Kent Beck, described the "integration pumpkin." Now
on one project I'd read about, they simply had a single integration
workstation; when you wanted to integrate your new code with a release
branch, you went over there and did the work. On this particular
project, though, you could integrate on any workstation, but they ran
into issues when two pairs of programmers (it was a pair-programmed
project) were integrating at the same time; they'd stomp on each other.

So they came up with the integration pumpkin: a stuffed toy pumpkin that
you would take when you were integrating, that served as a global lock
on this, as it were.

I'd always wondered why they did this, until I started seriously using
Darcs. It turns out that distributed revision control has an issue with
this sort of thing: it distributes the repository, but centralizes the
integration for any particular release branch. This works fine for
something like Darcs or the Linux kernel, where one or a few people do
all of the integration. But it doesn't work so well on my projects,
where every developer is expected to make the release branch releasable
with his changes, and any random team member might be doing the final
changes to make an actual release version. What had happened was that
the implicit integration pumpkin that Subversion supplies didn't exist
in Darcs.

I'm not sure whether or not this is an issue with Darcs in particular,
or with distributed repositories in general, but it's definitely there.
The short summary is: with Subversion I'm forced to resolve conflicts;
with Darcs, when I see conflicts, I just do a revert and all of the
conflicts disappear, along with all of the new code, unfortunately.

Anyway, I'm wondering how much these sort of style and UI issues might
be part of the GHC RCS troubles of the day.

Going back to the original topic of the post I'm replying to:

Now that I think about it, I'd say that the problem has nothing to do
with the relatively small number of Haskell programmers around. It's to
do with the relatively small number of Haskell programmers available
that have the ability to work on this sort of problem, and there are
probably have as many of those as there are in, say, the Linux kernel
development community. And of course, the also have other difficult
things to do, such as build a world-class compiler that's right up there
with gcc, with maybe one-tenth the manpower.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com