Yeah, most of this is just drawing conclusions from what is essentially noise. Especially the consistency measure: that's bound to be heavily affected by how many people use a given language. The so-called "tier 1" are not popular because they're consistent--they're consistent because they're popular. The same goes for the tier 3 languages in reverse: they probably have so little activity that a high variance is inevitable.<p>Also, number of lines per commit is not really a good measure of expressivity. I don't even see how it's a reasonable proxy: the number of lines I commit changes more depending on my project (is it simple or complex, for work or for fun?) than on my language.<p>Also, it makes literally no sense at all to consider very domain-specific languages like puppet: you may as well talk about how expressive HTML or CSS are relative to normal programming languages!<p>Basically, I think this article draws too many arbitrary conclusions on limited data.
I'm not certain that commit size is a good measure of expressiveness. Even not counting obvious outliers like javascript (oops, 3241245 people had a commit with jquery inside), it will be very dependent on the cultures in the different languages.<p>Some languages have users that are less mature in VCS usage than others, some languages have users that spend a lot more time writing tests (which create larger commits) etc.
There is a lot of weak-ass criticism going on in this thread when the data -- whatever about its methodology is troubling -- seems to almost perfectly back up what is the common experience among programmers. Yes, copy-and-paste doubtlessly affected the numbers for JavaScript, but I am not at all surprised to see JavaScript where it is.<p>Does anyone here really doubt that you can get more done with a single line of Python than a line of C/Java/C++? Same for Clojure/Common Lisp/Racket versus Python.<p>We might not take individual ranking too seriously, and none of this affects language choice when performance is a critical concern (though the spacing between Scala, OCaml, and Go is interesting and relevant to this), but do you guys honestly doubt the trend here? Does anyone have a strong counter-example? It seems like the authors may have had a decent notion with using LOC as a measure. There is no proof of this here, but I am intrigued by it.<p>The final conclusions in favor of CoffeeScript, Clojure, and Python are again pretty obvious. Is anyone going to suggest JavaScript or C++ is more expressive than any of these?
The good thing about Coffeescript is that it actually seems to deliver what it was promising in the first place, terseness, expressiveness, simplicity and good Javascript output.<p>It is really a joy to develop with (though my being a Ruby programmer probably makes me a somehow biased and enthusiastic candidate).
Wait... JavaScript and CoffeeScript end up at <i>opposite</i> extremes while having near-enough identical semantics?<p>That's a big red flag on this as a measure of expressiveness.
It's hard to tell if the fact that CoffeeScript is #6 (the highest ranked major language) and Javascript is #51 (second to last) is a reflection on how much of a shift CS is from JS, or on the quality of methodology and metrics in the OP.
> let the results speak for themselves<p>The difference between Fortran Free Format and Fortran Fixed Format should be enough to tell us that <i>lines of code per commit</i> is all about how much stuff you put on a line!<p>(Is `nl` significant in the language syntax? Were readable wide screen displays available when the code was written?)
Note that in fifth place -- ahead of Coffeescript, Clojure, Python, etc., etc., -- is eC, a that's basically C plus a few OO features and a GUI library. It has, for instance, no automatic memory management (besides some rather primitive refcounting); neither dynamic typing nor type inference; no nice literal syntax for collection types; in short, whatever its merits it is not an outstandingly expressive language.<p>There is surely some correlation between short commits and expressiveness, but they're far enough apart that I think the title is very misleading.
Terse isn't the same as expressive. Consider Scala vs Java. In Java, definining a singleton involves implementing a design pattern in one of a few ways. Maybe you have a private constructor and a static initializer. In Scala you define your class with `object` and it's done. That's concise and expressive.<p>In Java, if your generic class has a lower bound you write Class Foo<T extends Bar> while in Scala you write def Foo[T<%Bar] which is just an abbreviation. Replacing a word with punctuation. One is good, one isn't.
The real measure is features shipped.<p>It's pretty hard to disambiguate speed of development, fluidity and flexibility (which potentially increases LOC per commit by bundling multiple 'conceptual pieces') with expressiveness (which decreases LOC per commit) in a single LOC per commit metric.<p>The idea that a single commit corresponds to a 'single conceptual piece' is probably not very precise. It also doesn't measure for the complexity of the conceptual piece. It hasn't been established that the same level of 'conceptual pieces' are tackled across all programming languages per commit.<p>Just some thoughts. That said, I think though given all the factors involved (more expressive concepts per commit are perhaps tackled in more expressive languages, and that cancels out that less expressive concepts are tackled per commit in less expressive languages -- that balances out simplicity in simpler / less expressive languages can lead to more actual features commited), that actually the methodology kind of works. But, like others here, I wouldn't presume it's quite so simple underneath.
There are a few surprises in that list. I'd have thought both Coq and Lua would end up further to the left. I suppose the graph shows an interesting dynamic: expressiveness is not just due to a language's semantics, nor syntax, nor libraries. You need a healthy interplay between all three aspects of a programming language to truly be "expressive".
The whiskers on the Prolog and Logtalk plots would tend to confirm what PG had said in one place or another, that a language can be both more high level and less expressive, apparently using a definition of expressive related to line count. In that light I'm kind of surprised they do as well as they do in this post.<p>As I get more serious about Prolog I think it's kind of a shame more people aren't exposed to it (apart from apparently dreaded university classes). It's pretty impressive just how quickly one can write a parser, and for writing an "internal" DSL it rivals or exceeds Lisp (depending on one's taste).
This assumes that languages are used to solve similar classes of problems, or that, in aggregate, those different classes result in similarly-sized "feature" chunks.<p>I think it's fair to say that nobody's ever written a forum in puppet, and that few people are working on micro-[web]frameworks in Fortran.<p>Interesting data, just need to be careful about what conclusions are drawn from it.
While their chart confirms my personal bias (that FP is more expressive), I think their methodology is flawed to the point of making the whole thing meaningless. They are not measuring expressiveness, they are measuring lines of code per commit. Having a community that likes lots of small commits doesn't actually make a language more expressive than one with a community that likes fewer, larger commits. They even acknowledge that the javascript numbers are basically meaningless because it is so common to copy+paste entire big external dependencies into a javascript project.
That's why I think people should take a look at the next generation of Rebol <a href="http://www.red-lang.org/" rel="nofollow">http://www.red-lang.org/</a>.<p>Fast as C, expressive as Lisp, and more readable than Ruby...well, that's the goals at least ;)