[Haskell-cafe] Re: Why can't Haskell be faster?

[Don Stewart]

igouy2:
> 
> --- Sebastian Sylvan <sebastian.sylvan at gmail.com> wrote:
> -snip- 
> > It still tells you how much content you can see on a given amount of
> > vertical space.
> 
> And why would we care about that? :-)
>  
> 
> > I think the point, however, is that while LOC is not perfect, gzip is
> > worse.
> 
> How do you know? 
> 
>  
> > > Best case you'll end up concluding that the added complexity had
> > > no adverse effect on the results.
> 
> Best case would be seeing that the results were corrected against bias
> in favour of long-lines, and ranked programs in a way that looks-right
> when we look at the program source code side-by-side.
> 
> 
> > It's completely arbitrary and favours languages wich requires
> > you to write tons of book keeping (semantic noise) as it will
> > compress down all that redundancy quite a bit (while the programmer
> > would still has to write it, and maintain it).
> > So gzip is even less useful than LOC, as it actively *hides* the very
> > thing you're trying to meassure! You might as well remove it
> > alltogether.
> 
> I don't think you've looked at any of the gz rankings, or compared the
> source code for any of the programs :-)
>  
> 
> > Or, as has been suggested, count the number of words in the program.
> > Again, not perfect (it's possible in some languages to write things
> > which has no whitespace, but is still lots of tokens).
> 
> Wouldn't that be "completely arbitrary"?
> 

I follow the shootout changes fairly often, and the gzip change didn't 
significantly alter the rankings, though iirc, it did cause perl to drop
a few places.

Really, its a fine heuristic, given its power/weight ratio.

-- Don