[arch-general] pacman new generation

[Norbert Zeh]

Taylor Hedberg [2011.11.22 1036 -0500]:
> Nicolas Sebrecht, Tue 2011-11-22 @ 16:24:02+0100:
> > I don't think, so. IMHO, the pool of contributors is bigger with a
> > high-level language than for C, simply because the learning curve of a
> > good high-level language is much shorter.
> 
> You can't seriously be suggesting that switching to Haskell would
> increase the size of the pacman developer pool. I think Haskell is
> great too, but if you think it's bigger than C just because it's
> high-level, you're delusional. Even on a distro like Arch, where there
> seems to be a disproportionate number of Haskell users, I'd wager that
> there are still far more people here that know C.
> 
> The learning curve of Haskell is widely regarded as one of the steepest
> in programming. There are plenty of arguments to be made in its favor,
> but that is not one of them.
> 
> C is the lingua franca of Unix, practically everyone knows it, or at
> least enough of it to be moderately competent. It makes sense to keep
> community-developed projects like pacman in a widely-known and used
> language so that more people can understand the code and contribute. I
> don't think there's any compelling reason to rewrite pacman in another
> language.

I think this discussion has dragged on for too long and the points that should
have been made have been made already - so I was reluctant to respond.  However,
I felt I needed to chime in here to say that I think that Taylor hit the nail on
the head.  I am a big proponent of Haskell - it's pretty much the only language
I use nowadays for any of my toy projects - but it's not an easy language to
learn to use effectively.  For that reason, the pool of Haskell developers out
there is much smaller than the pool of C programmers.  Furthermore, from my own
experience I know that writing good Haskell code poses its own set of challenges
exactly *because* the language is so expressive, not unlike writing Perl code,
which in the areas it was designed for is also highly expressive.  I sometimes
step into the trap of expressing my computation as succinctly as possible...and
the result is write-only code where I, being the author of the code, need 5
minutes to figure out what a cleverly crafted 2-line function does when looking
at the code 3 months after I wrote it.

So, given that the current team behind pacman is using C to develop it and
manages to churn out very high-quality code with it, the only reasonable
approach to convince people that Haskell would indeed be a better choice is to
demonstrate that there exists a group of Haskell-savvy arch users/developers out
there that can first reimplement pacman in Haskell, in a way that matches or
comes close to the performance of the current C implementation, and can then
capitalize on the expressiveness of Haskell to add new features more quickly
than would have been possible using the current C implementation, without
sacrificing performance, stability or readability of the code.

Cheers,
Norbert