On Fri, Jul 26, 2013 at 08:21:45PM +0200, SomeDude wrote: > On Thursday, 25 July 2013 at 20:03:52 UTC, Peter Alexander wrote: > >The problem is all those last bits: > > > >- Line counts aren't a good measure of anything. > > That's why some people prefer to compare a gzipped version of the > source code. The gzipped version gives a more fair account of the > code size.
That's not true. Comments, esp. extensive DDoc comments, can carry a lot of information that isn't part of the code itself. That will contribute to the gzipped size. At the very least, you'd have to strip out comments before compressing to get an accurate idea of "how much code" there is. The idea of using compression to quantify the amount of code is a clever one, though. Perhaps one way to improve it might be to have the compiler serialize the AST of the completely-parsed code, then we compress that serialized AST. Still, it's hard to get from this (or any other) measurement of code size to the "expressiveness" of the language. An inexperienced coder might write rather verbosely where an expert coder would write in just a few concise lines; the quantity of code would differ in each case, so without knowing the level of mastery the coder has over the language, it's still difficult to quantify expressivity. Furthermore, one could deliberately code in such a way as to maximize (or minimize) whatever chosen measure is used to evaluate the language, but that by no means reflects the *typical* usage of the language. And even then, we have to deal with the problem space: not all languages are best at addressing all classes of programming challenges. It would be unfair, for example, to judge Java on the basis of how well one could write an OS in it, since the language just isn't designed for that sort of thing. You'd be running into all sorts of roadblocks everywhere that aren't present when you write other applications that Java is more suitable for. T -- Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.