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