[Haskell-cafe] Re: Why can't Haskell be faster?
dons at galois.com
Fri Nov 2 19:55:32 EDT 2007
> --- Sebastian Sylvan <sebastian.sylvan at gmail.com> wrote:
> > 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.
More information about the Haskell-Cafe