[Haskell-cafe] Haskell Speed

[Jared Updike]

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).

>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
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 at gmail.com
http://www.updike.org/~jared/
reverse ")-:"