There is very little to infer from code which is so far from being idiomatic, aside from the fact that you might as well use C if you ever find yourself in the benchmark situation.
This is, arguably, totally fine, because these are still valid programs that run (and run quickly). BUT, it makes the benchmark programs poor choices to compare the verbosity of languages. So statements like "For a language famed for its terseness, Haskell it turns out, isn’t as terse as expected" can't be supported when comparing benchmark programs that were written to maximize speed, rather than written to minimize developer time.
Fortunately, the Benchmark Game does publish all of its programs, including the ones that don't "win" the speed race, and it's possible to find nice, concise, idiomatic Haskell programs in there.
Because?
Because the way some link to an external library is more verbose than the way they link to an included library?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Well you can and obviously people do, but the advice given is "Always look at the source code."
> Most implementations look like…
So you counted !
How many of the 33 Haskell programs "look like C" ?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Or did you see a couple that "look like C" and cherry-pick ? :-)
The only fairly idiomatic ones (no pointers, no malloc, no unsafe) I could find are pidigits, binary-trees, and k-nucleotide. That's 3 out of 10.
You might find this interesting — "One can, with sufficient effort, essentially write C code in Haskell using various unsafe primitives. We would argue that this is not true to the spirit and goals of Haskell, and we have attempted in this paper to remain within the space of reasonably idiomatic Haskell. However, we have made abundant use of strictness annotations, explicit strictness, and unboxed vectors. We have, more controversially perhaps, used unsafe array subscripting in places. Are our choices reasonable?"
pdf "Measuring the Haskell Gap"
http://www.leafpetersen.com/leaf/publications/ifl2013/haskel...
I'm responding to this. Languages with many escape hatches like Haskell or Swift will result in less idiomatic code (and potentially longer programs) when optimized for the benchmarks games. Languages with less escape hatches like Go and Ocaml less so.
I don't have anything against any of these languages. Feel free to write C-like code in Haskell if you want.