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
