On 11/2/07, Isaac Gouy wrote:

How strange that you've snipped out the source code shape comment that would undermine what you say - obviously LOC doesn't tell you anything about how much stuff is on each line, so it doesn't tell you about the amount of code that was written or the amount of code the developer can see whilst reading code.

It still tells you how much content you can see on a given amount of vertical space. I think the point, however, is that while LOC is not perfect, gzip is worse. 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. 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). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

igouy2:

--- Sebastian Sylvan 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

--- Greg Fitzgerald wrote:

...

...

while LOC is not perfect, gzip is worse. the gzip change didn't significantly alter the rankings

Currently the gzip ratio of C++ to Python is 2.0, which at a glance, wouldn't sell me on a "less code" argument.

a) you're looking at an average, instead try http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&lang2=gpp b) we're not trying to sell you on a "less code" argument - it's whatever it is

Although the rank stayed the same, did the change reduce the magnitude of the victory?

c) that will have varied program to program, and do you care which way "the magnitude of victory" moved or do you care that where it moved to makes more sense? For fun, 2 meteor-contest programs, ratios to the python-2 program LOC GZ WC ghc-3 0.98 1.40 1.51 gpp-4 3.76 4.14 4.22 Look at the python-2 and ghc-3 source and tell us if LOC gave a reasonable indication of relative program size - is ghc-3 really the smaller program? :-) http://shootout.alioth.debian.org/gp4/benchmark.php?test=meteor&lang=all&sort=gz __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

On 11/2/07, Sterling Clover wrote:

As I understand it, the question is what you want to measure for. gzip is actually pretty good at, precisely because it removes boilerplate, reducing programs to something approximating their complexity. So a higher gzipped size means, at some level, a more complicated algorithm (in the case, maybe, of lower level languages, because there's complexity that's not lifted to the compiler). LOC per language, as I understand it, has been somewhat called into question as a measure of productivity, but there's still a correlation between programmers and LOC across languages even if it wasn't as strong as thought -- on the other hand, bugs per LOC seems to have been fairly strongly debunked as something constant across languages. If you want a measure of the language as a language, I guess LOC/gzipped is a good ratio for how much "noise" it introduces -- but if you want to measure just pure speed across similar algorithmic implementations, which, as I understand it, is what the shootout is all about, then gzipped actually tends to make some sense.

--S _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Lossless File compression, AKA entropy coding, attempts to maximize the amount of information per bit (or byte) to be as close to the entropy as possible. Basically, gzip is measuring (approximating) the amount of "information" contained in the code. I think it would be interesting to compare the ratios between raw file size its entropy (we can come up with a precise metric later). This would show us how concise the language and code actually is. --ryan

On Friday 02 November 2007 23:53, Isaac Gouy wrote:

...

...

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.

Why would you want to subjectively "correct" for "bias" in favour of long lines?

...

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"?

That is not an argument in favour of needlessly adding extra complexity and adopting a practically-irrelevant metric. Why not use the byte count of a PNG encoding of a photograph of the source code written out by hand in blue ballpoint pen? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e