On 1/4/06, Scherrer, Chad <[EMAIL PROTECTED]> wrote: > > --- Sebastian Sylvan <[EMAIL PROTECTED]> > > 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
