Saying the comparison is unfair because the Haskell solution is lazy makes about as much sense as claiming a comparison between a C and C++ implementation is unfair because the C++ one uses objects.
The point of such a comparison is not to provide a accurate language benchmark by comparing algorithmically identical implementations but to compare the most obvious implementations in those languages that solve a specific problem.
Personally I think the Haskell result would still be impressive at twice the speed of the C++ solution simply due to the LOC used and the time in which it was implemented.
>The point of such a comparison is not to provide a accurate language benchmark by comparing algorithmically identical implementations but to compare the most obvious implementations in those languages that solve a specific problem.
Right, but "parse this text file and then throw the result on the floor" isn't a real problem. The haskell version is deferring some of the work to when the object's actually used - but if you wanted to use that parser in a real program, you'd have to do that work. It's like those webserver benchmarks that you can do much better on by making the server print "HTTP" before it's done any processing.
This seems to be a common problem when benchmarking haskell. You absolutely have to use a program that outputs the real-world result you want, otherwise the clever compiler with its lazy semantics will optimize away all the work.
The point of such a comparison is not to provide a accurate language benchmark by comparing algorithmically identical implementations but to compare the most obvious implementations in those languages that solve a specific problem.
Personally I think the Haskell result would still be impressive at twice the speed of the C++ solution simply due to the LOC used and the time in which it was implemented.