igouy2: > > --- Sebastian Sylvan <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe