
From a glance, I also don't buy that most of this Haskell code is very idiomatic or optimized, but I could be wrong. It looks like literal
This "benchmark" only tests specific implementations of these little tests, tests mostly designed to do imperative things in an imperative way. What that means is the results are completely subject to (1) how good the submission for that tests was, (2) the choice of tests in the first place, and (3) startup times for loading the binaries into memory (GHC makes big binaries that are arguably much faster if you do things in "daemon" mode, for example). translations of imperative code into Haskell, which is not the way Haskell works. (It reminds me of Paul Graham's 1-D measure of programming language expressivity: how hard is it to make a number incrementer, which assumes very much that side-effects are a good thing---the Haskell code is quite short considering the fact that this is not something the language was designed for, and it's not considered "the right approach" unless you have a good reason to do it this way.) I'm also not surprised that "true, blue" Haskell folk haven't necessarily jumped on this and submitted better code, because it is pretty much a game created to make C win---it already wins! That being said, I think it's neat that someone but something together to play with. I also //do// agree that Haskell at its best is still too slow, and that even implementations of a great language like Haskell can always be better, but, as you said, the programmer/human side wins out---for me, for Haskell, anyway. Plus a lot of this code could be rewritten in C and then just have the Haskell code foreign function call it--- since that is arguably a very good way ("the right way"?) to use Haskell to do imperative things, especially time-sensitive inner loops, especially in large applications. But notice that none of these programs are big enough to be considered "large" applications, and none of the tests measure prototyping, refactoring, design time, mathematical tractability/provability, or programmer time (or programmer **pain**! especially for non-trivial programs, which none of these are. Just my $.02 Jared. -- jupdike@gmail.com http://www.updike.org/~jared/ reverse ")-:"