RE: [Haskell-cafe] Shootout favoring imperative code

--- Sebastian Sylvan
wrote: Some of the problems seem to be heavily geared towards an imperative *implementation*, meaning that a Haskell version is hardly idiomatic Haskell (and as such I , and I suspect otehrs, really have no inclination to work on it).
This may be correct, but it still doesn't address the question. Why does Clean fare so much better? Clean is purely functional, right? Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx

On 1/4/06, Scherrer, Chad
--- Sebastian Sylvan
wrote: Some of the problems seem to be heavily geared towards an imperative *implementation*, meaning that a Haskell version is hardly idiomatic Haskell (and as such I , and I suspect otehrs, really have no inclination to work on it). This may be correct, but it still doesn't address the question. Why does Clean fare so much better? Clean is purely functional, right?
Ah, but is that really the interesting question? :-) IMO no. I don't think most of these benchmarks are unfair performance-wise (mostly because there are very few problems which are *inherently faster* in imperative languages), but some of them are unfair in "implementation-effort-time". So the fact that Clean fares better than Haskell doesn't have much to do with the "unfairness" of the shootout (but certainly is interesting!). There are many programs which can be quite easily programmed in Haskell but are cumbersome in C, but very few of that type of programs are in the shootout (see basically any Haskell tutorial for many examples :-)). For instance, working with big lazy matrices (doing multiplication, inversions etc.) and then extracting only a single element somewhere for the output. That's certainly useful, and difficult to do in C or C++, but comes "for free" (implementation-time-wise) in Haskell. OTOH, now that I think about it, most of the cases where Haskell is clearly more elegant than the competition is in more "real-world" scenarios, and not in "benchmarky" code (small code performing a small set of operations many times) - so it may be that benchmarks are inherently favoured towards "von-Neumann-abstraction"-type langauges. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
participants (2)
-
Scherrer, Chad
-
Sebastian Sylvan