People often compare programming languages by lines of code. The problem is that a more verbose language usually requires less thought per line than a terser language.
Maybe a better metric of a programming language's complexity could be had by measuring the size of a compressed source-code file rather than line's of code.<p>Anybody disagree and think the opposite is true;
that a simpler syntax usually means more thought?<p>Anybody here ever heard of somebody doing something like that?
I'm going to slightly disagree with other comments here and say that LOC is a meaningful metric. It might not be the best, as OP suggests, but it's worth something.<p>Having written a lot of Python it is now frustrating to write C++, mostly because of the verbosity. Instead of thinking about the problem I'm trying to solve, I'm thinking about how to deal with the language or necessary data structures. Python just gets out of your way and lets you solve the problem at hand quickly and concisely.<p>I don't think more thought goes into a line of Python code, and if it does, it's productive thought. It's not the "what's the 6th argument to this function?" or "is the type of the 3rd argument to this function really just a typedef for a float?" type of my-language-requires-me-to-jump-through-hoops thought.<p>To me, all that verbosity means more time thinking about the code and less time thinking about the problem.
I believe compressed source code size is one of the metrics available on the "Computer Language Benchmark Game":<p><a href="http://shootout.alioth.debian.org/" rel="nofollow">http://shootout.alioth.debian.org/</a><p>I feel relatively strongly that LoC is almost entirely worthless as a metric. Even compressed source code size makes me uneasy. Shameless self promotion: I wrote a blog post which appeared on HN just the other day about better ways of comparing programming languages.<p><a href="http://news.ycombinator.com/item?id=766841" rel="nofollow">http://news.ycombinator.com/item?id=766841</a><p>In short, I disagree that there is almost any relationship between mental effort and verbosity.
According to Paul Graham (<a href="http://www.paulgraham.com/arcchallenge.html" rel="nofollow">http://www.paulgraham.com/arcchallenge.html</a>):<p><pre><code> The most meaningful test of the length of a program is not lines or
characters but the size of the codetree-- the tree you'd need to represent
the source. The Arc example has a codetree of 23 nodes: 15 leaves/tokens
+ 8 interior nodes. How long is it in your favorite language?
</code></pre>
So instead of measuring lines of code, you measure the size of the AST. Works well for Lisp, at least; not sure how well it generalizes to other languages.
Both metrics seem to assume that source code is a fixed thing. My bottleneck when working with source code is not write or read, but modify. Therefore, the most important metric to me is whether an O(1) conceptual change requires only an O(1) change of source code.<p>A small line count / compressed size / AST node count is probably a good indicator of this, but I'm not convinced it's exactly the same.
I think anything directly related to the syntax of a language is a very, very dull metric. I say 'dull', because the LOCs certainly can tell you something about the size of the project (if 3 guys crafted 3 million lines of code for a project, and 3 other guys did the whole thing in 12k lines of code in the same language, something is eery), but it is very hard to make fine statements with them.<p>I much rather would like to see metrics which actually involve the complexity of the code involved, that is, a measure for 'what the user has to keep in his head'. The cyclomatic complexity (~#of paths through a method) is a good example of a step in the right direction in my opinion. I just don't know how one would formalize the complexity of a framework, for example, where one has to remember 'ok, I need to implement this, this and that method in my class and these contracts have to hold' and such :)
For business applications take a look at "function points". It is not perfect but it may help you.<p>Some people use LoC without comments or blank lines.<p>In general these measures can be useful indicators but have to be taken with a grain of salt.<p>Also take a look at this Martin Fowler's article <a href="http://martinfowler.com/bliki/CannotMeasureProductivity.html" rel="nofollow">http://martinfowler.com/bliki/CannotMeasureProductivity.html</a>
A common claim I hear from software engineering researchers is that the number of errors in <i>X</i> lines of code from a person is constant. "Lines of code" is supposedly independet of programming language.<p>If this is true, then the implication is that when you can implement the same functionality in less code, it will also probably have less bugs. So, if we look at opportunities for bugs, I think lines of code <i>is</i> relevant.
I actually like LOC as a metric.<p>Base on the truism that every line of code has a potential bug, even if the line is cruft, then the length of the codebase is proportional to the potential bugs.<p>It's a simplification, obviously, but LOC is useful in this respect.<p>The main problem with LOC IMHO is people try and use it for the wrong purpose.
The LoC metric drives me insane. To entertain myself, I mess with the LoC "bean counters" by writing overly verbose, first-pass code and then optimizing it down once I'm finished. It's my own little form of rebellion.<p>"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
- Bill Gates
Probably the best way I've seen of comparing languages is by what proportion of the program is problem solution versus how much is language/syntax cruft.