Programming languages ranked by expressiveness
redmonk.com
redmonk.com
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.
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!
Basically, I think this article draws too many arbitrary conclusions on limited data.
This amounts to saying: Some days I eat eggs for breakfast, but other days I eat oatmeal for breakfast, so I am totally inconsistent in what I eat from day to day, therefore it would make no sense to include me on a survey about what people in my country eat.
You do understand that a single data point might be useless, but when combined with thousands or millions of other data points, it becomes useful? What you do on any one project does not matter, but what you do, combined with thousands of other developers, all averaged together, starts to get interesting.
If you honestly believed your own premise, then you would expect all the results to be the same -- there would be no variation between Fortran, Java, Javascript, Clojure or Coffeescript, cause, you know, everybody is different and does different stuff, and its all so crazy, how can anybody make sense of it?
But we can make sense of it. All that is needed is a good understanding of probability and a sufficiently large data set.
Mind you, the article above might be total bunk. There might be lots wrong with the dataset. But its not bunk for the reason you give: " 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."
Your breakfast analogy would be more like:
- Some days Alice eats crumpets while sitting in her house and it takes her about 20 minutes.
- Some days Bob eats a bagel while on the way to work and it takes him about 5 minutes.
- Therefore, bagels are 4 times faster to eat than crumpets.
See the problem is we have conflated lots of correlations at once. There is 1) a tendency for certain types of foods (languages) to be used for certain purposes, and a tendency for certain kinds of people to prefer certain foods (languages), and neither of those correlations are necessarily caused by the properties of the food (language) itself.
> What conclusions can we draw from this?
...answer the question with "None" and then explain why.
Following that with a deeper analysis of the myriad explanations for this data could have been interesting (e.g. what kinds of projects are strongly correlated with larger commits? How much does that vary by language and age of the project?), but unsupported conclusions are not.
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.
As for why this metric and not others, it's the one I could actually get the data for. I don't have the time or space to download literally millions of repositories myself, so I used what I could get access to.
That is only true in some programming communities.
Essentially what you are selecting for is languages whose users seem to have digested some of the same software development memes that you have. Those users are going to be generally drawn to expressive languages, and will have very focused commits in those languages. So there is a correlation between expressiveness and small commits.
But it is only a correlation. For instance I've programmed in both Perl and Ruby. Of the two, Ruby is more expressive. (Universal opinion of everyone that I know who has programmed both.) However Perl is very "unhip", so people doing open source software development in Perl these days tend to be people who have been programming for some time, which means that they've absorbed a lot of good programming ideas. (Seriously, once you get past the reputation for "unmaintainable line noise", a lot of surprisingly good code is written in Perl.) Thus Perl outranks Ruby in this list.
What would be much more informative is the ratio of lines of code/commit between languages for users that have programmed in both languages. It would take more work to do an analysis on the principles of that analysis, and you'd reveal similar trends, but the analysis would be far more informative.
1) You just assume that each commit adds "a single conceptual piece" -- where is your justification for that assumption?
2) Using the same descriptive phrase - "a single conceptual piece" - doesn't in-itself make the things described comparable.
Even if they were in some sense "a single conceptual piece" they could still be wildly different in-scale and in-complexity because of the problem-domain the project addressed not because of any intrinsic property of the language.
3) Ohloh tracks different types of repositories -- you seem to have ignored the possibility that locs/commit might have something to do with how much of a PITA it is to use the different repositories, and whether the history of language and repository popularity has meant some languages are represented more strongly on some repositories.
You've presented lots and lots of interpretation -- without exploring what's varying and what's constant in your dataset.
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.
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.
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?
So?
I mean, really, I can come up with completely bogus metrics all day, and whenever one produces results in a domain that happen to align with CW in that domain post a infographic using it, but that doesn't make that metric meaningful.
> The final conclusions in favor of CoffeeScript, Clojure, and Python are pretty obvious, I would think.</blockquote>
So? A metric that has no intrinsic validity doesn't become valuable just because it produces conclusions which match what you would have assumed to be true (whether based on valid logic or not) before encountering the metric.
The commenters in this thread are writing off the data because...? They decided the measure is bad? When the measure conforms to experience, it's probably worthwhile to look into it. This doesn't mean that correlation implies causation and yada yada 9th-grade science lesson.
Yes, because what the measure actually measures isn't a valid proxy for what it purports to measure.
> When the measure conforms to experience, it's probably worthwhile to look into it.
No, if the adopted proxy (here, "LOC per commit") has some sound rationale for being used as a proxy for the actual quality of interest (here "expressiveness"), then it is worth actually getting some results with it for which you have a firm expectation of what those results would look like if you were able to directly measure the quantity (in this case "expressiveness") for which you are using the proxy (in this case "LOC per commit").
If after such testing the proxy -- which you first looked to for reasonableness, and then tested on the "simple" data for which you had a firm expectation of what the results would be for the quality of interest -- seems workable, its worth investigating what kinds of results in returns for things which you don't have a firm idea of where they would fall. (Which is the only reason you actually use a proxy measure for in the first place.)
In this case, the proxy fails at the first test (sound rationale for using it as a proxy for expressiveness), which makes the second test (do the results line up with what you'd expect on a known sample set) meaningless.
That's hard to tell in your case, since most of your commentary has been explicitly skipping past the criticism of the failure of the proxy to have a clear link to the thing it was taken as a proxy to say that doesn't matter since the results were about what you would xpect, rather than actually addressing the criticism.
So it sounds like you were failing to understand the first test more than you were disagreeing with the criticism based on it. And, as yet, you haven't stated any reason for disagreeing, just continued to skip to the second test.
It's clear from this, I would think, why therefore length-of-commit is supposed to be a good proxy for measuring expressiveness.
To be clear -- the reason that it is obvious that I and the author disagree with you on the first case is because your objection was a) an elementary one and a consideration important to all such investigations, therefore it would be considered by anyone doing such an investigation or analyzing one and b) we were disagreeing with you anyway.
There's no really good reason to suspect that the second of these suppositions holds to the same degree across different languages (which basically is equivalent to the assumption that development practices are independent of language.)
> To be clear -- the reason that it is obvious that I and the author disagree with you on the first case is because your objection was a) an elementary one and a consideration important to all such investigations, therefore it would be considered by anyone doing such an investigation or analyzing one and b) we were disagreeing with you anyway.
It would clearly be considered by anyone competent doing such investigation, but since your first post on this thread didn't acknowledge the basis and challenge the correctness of the common criticism in the thread based on concerns of this type but explicitly and emphatically stated a lack of understanding of what the complaints were about, it appeared quite clearly that you didn't get it. The assumption of basic competence may be warranted, if only out of politeness, when someone doesn't explicitly state something inconsistent with that assumption, but when they do, that assumption becomes unwarranted.
I do not see anyone offering better measures of expressiveness or suggesting counterexamples to invalidate the results. The criticism here is just "Meh, not impressed".
Nobody will argue C is more expressive than Python, but the data in the article doesn't support it. Just because something is true doesn't mean it's okay to support it with shoddy data.
LOC per commit isn't a proxy measurement of the expressiveness of a language. The entire premise of the article is flawed.
And nobody is offering proof that this measurement is meaningful, so it should be ditched.
Replace "expressiveness" with "author's anticipation of reviewer difficulty based on prevailing cultural biases" and you have a different conclusion for how authors size groups of changes that also matches the order graphed.
If you want literal expression-per-line why not just look at compressed_size/line_count for the available body of work in each language?
Javascript is way too expressive for its given position. I also believe ruby is more expressive than python, and yet the plot shows the opposite there as well.
This plot could have some interesting data, but there's far too much noise to really learn much from it.
Maybe not if you follow PEP:8 -- maybe so if you write really really long lines ;-)
I've never understood this criticism before. Consider this line of python:
x = 3
To this line in C:
DoAllTheThings();
A single line of code is a bad comparison because it doesn't say anything about the underlying language or platform.
We know a single line of code can do a lot of things in both languages. The question is what does the average line do. And this is important, because the occurrence of bugs is directly correlated with lines written rather than the complexity of those lines, and the same seems to be true for programmer productivity. So if 100 lines of Python does more than 100 lines of C, this is an important fact, as in first case more will have been accomplished for the same amount of work and the same debugging effort.
Not even when you come up with an answer will you be able to say something about a single line of code. Meaningful statements can only be made about lots of lines of code.
Except perhaps about vb. Screw that language.
It is really a joy to develop with (though my being a Ruby programmer probably makes me a somehow biased and enthusiastic candidate).
That's a big red flag on this as a measure of expressiveness.
Just like all those hacks using Fixed-format Fortran and Assembly?
On the other hand, I guess they probably aren't counting inline Javascript in HTML files.
The difference between Fortran Free Format and Fortran Fixed Format should be enough to tell us that lines of code per commit is all about how much stuff you put on a line!
(Is `nl` significant in the language syntax? Were readable wide screen displays available when the code was written?)
There is surely some correlation between short commits and expressiveness, but they're far enough apart that I think the title is very misleading.
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.
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.
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.
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.
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).
-- Perl user
-- Python user
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.
Interesting data, just need to be careful about what conclusions are drawn from it.
Its both compiled and interpreted and a system language and a user language. Couple of examples:
'X=Y^2' 'Y' SOLVE 149 'X' STO EVAL @evaluate first expr for Y=149 .. Including optimising it by rearranging it
{ "a" "b" "c" } SORT REVLIST << "M" + >> MAP @sort then reverse then add M string to every list item using anonymous function and map.
Storage is entirely transparent and persistent as well.
Quite my favourite language these days. I can actually do real work with it and it runs in my pocket on a 75MHz ARM (which is more than enough for it), has built in context sensitive help, a debugger that even puts gdb to shame and has 2Gb of persistent storage and lasts a month on 4 NiMh eneloop AAA's. All for £79 :)
It also doesn't have any distractions like the internet.
This premise is complete rubbish.
It's an interesting metric in any case, I'd just prefer not editorializing it. That's a common concern I have with supposed proxy variables, unless their proxyness has already been established through some kind of scientifically solid investigation. A ranking of languages by average commit size would be truth-in-advertising, and then it could be followed by a speculative blurb about what that means, with language expressiveness being one hypothesis. I think that'd still be perfectly interesting as something to do and discuss, but maybe it'd have a harder time getting traction.
Comes up in published scientific literature fairly often as well, unfortunately. E.g. it's common for neuroscience papers to be solid scientific investigations of a specific variable, but to then completely oversell the results by labeling it as a proxy measure for something more evocative, like "creativity" or "free will" or "empathy", with a really handwavy argument for why this specific variable is a suitable proxy for that full concept. It's also getting common in the past 1-2 years for people to claim trends in Google Ngram type data are proxies for historical popularity of concepts, when there are a lot of confounding reasons that might not be true.
Is that even a thing? I feel like commit sizes is generally a pretty person by person thing. Aggregate a bunch of people/projects/dev-groups and you get some vague metric of a language.
The point I think isn't to show X is slightly more expressive than Y, but to illustrate a general trend.
Fast as C, expressive as Lisp, and more readable than Ruby...well, that's the goals at least ;)