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.
Yes, that is what I mean. By the way, on the benchmark game website, is it still possible to sort benchmark results not by speed, but by gzip'd source code size?
So you did not mean "Most implementations look like C …" you meant the fastest implementations look like C ?
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?"
I think you're misunderstanding the point of my comment. Keep in mind the point of the original article: "For a language famed for its terseness, Haskell it turns out, isn’t as terse as expected - it’s average size of source code is larger than the average Go source code size."
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.
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.