A proper language comparison...

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Jul 26 11:44:31 PDT 2013


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.


More information about the Digitalmars-d mailing list