Programming languages ranked by expressiveness(redmonk.com)
redmonk.com
Programming languages ranked by expressiveness
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
92 comments
"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."
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."
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."
But that's not true if there is a systemic bias involved that has nothing to do with expressiveness. If you're more likely to make small commits on "fun" projects, you're biasing the results against languages that aren't used as often in fun projects.
[deleted]
With lots of data there's no doubt that they are measuring something, but it's not clear that they are measuring what they want.
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.
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.
Yes. It would have been better to publish the chart, and then on this line:
> 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.
> 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.
I think language age is another point in support of your consistency argument. Older languages have had more massive library changes etc. whereas new languages or unused languages have libraries change much less and therefore less churn. It's why Lua can be at one end and Boo at the other. Or C# and Vala despite their similarities. Old languages with lots of users at the low-churn end of the spectrum are something to look at though.
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.
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.
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.
So true. I would normally have trouble believing that assembly is more expressive than C, but maybe the people who write assembly tend to be excellent at what they do? And JS is more expressive than Java, no? Maybe some of these are skewed by the sort of programmers that use them.
I agree, for all the time he spends on his results, as far as I can tell he never really defends the idea that commit size is in any way a good proxy for "expressiveness." It would be nice if he could explain why he chose commit size over somthing like rosetta code size or some other metric.
I quickly mentioned it in the caveats section up top. The underlying justification/assumption is that commits are generally used to add a single conceptual piece regardless of which language it’s programmed in.
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.
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.
The underlying justification/assumption is that commits are generally used to add a single conceptual piece regardless of which language it’s programmed in.
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.
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.
>>commits are generally used to add a single conceptual piece<<
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.
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.
But that's a really important issue that I think deserves a lot more than two lines if you really want to convince anyone. For example, let's say I don't think that assumption is valid because adding or changing a feature in a large project is a lot more likely to involve refactoring than in a small project, regardless of how expressive the language is. This would bias your results against languages that are more commonly used in large projects. Maybe that's an issue, maybe not, but as far as I can tell you haven't even considered it (and saying "it probably averages out" isn't a real response.) Without some sort of justification for your assumptions I have a hard time believing your results.
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.
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?
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?
> 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.
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.
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.
Yes, thank you for that 9th-grade science lesson.
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.
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.
> The commenters in this thread are writing off the data because...? They decided the measure is bad?
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.
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.
Obviously I and the writer of the article disagree with you that it fails the first case.
> Obviously I and the writer of the article disagree with you that it fails the first case.
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.
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.
The supposition is that a more expressive language lets you do more with a single line of code on average than a less expressive language. The second supposition is that commits tend to be done to gather code expressing a single chunk of functionality in a program, so that on the average commits have the same utility in terms of what they contribute to the source project.
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.
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.
> The supposition is that a more expressive language lets you do more with a single line of code on average than a less expressive language. The second supposition is that commits tend to be done to gather code expressing a single chunk of functionality in a program, so that on the average commits have the same utility in terms of what they contribute to the source project.
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.
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.
[deleted]
If you only validate research via checking if it "agrees with experience", then what's the point of doing it in the first place?
That's not what we're doing here. What this article really is an examination based on a set of assumptions about how we can measure expressiveness. This is a difficult thing to measure. You could (I assume) do just as well by polling thousands of programmers and asking them in their experience, which languages are expressive. In the case of this article, the measure of expressiveness used seems to match up very well with a) common programmer experience and b) the intentions of language designers. And we're not talking about programmer experience in 2013. This split between Lisp, C, and Fortran is older than I am.
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".
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".
Vala and C# are two very similar langauges that are on polar opposite sides of the chart. Why? If I can't answer that in a convincing way, my first thought is going to be "because there is another factor involved in the rankings that wasn't accounted for."
I don't think anyone is saying it is completely uncorrelated with the real thing, sure if you split the chart in half the languages on the right will mostly really be less expressive, but this we know without having the chart anyway and the more granular results don't seem trustworthy.
This is exactly the point I am making.
There's enough good data backing up that conclusion that there's no point using crappy data like in the article.
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.
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.
The data in the article based on LOC seems to match very closely conclusions based on other data. I do not know that we get to throw out this measure just 'cuz. This is proof of nothing, but no one is offering proof that we should ditch this measurement.
I'd almost bet the author started with the conclusion and went searching for more data to back it up, so it's not a surprise to me that his data backs up his conclusion.
And nobody is offering proof that this measurement is meaningful, so it should be ditched.
And nobody is offering proof that this measurement is meaningful, so it should be ditched.
I started with a hypothesis that LOC/commit might be an interesting way to compare the productivity of languages, and I frankly had no clue whether it would produce anything useful or interpretable at all. When it did, I figured it was cool enough to write it up, although it's definitely fairly noisy data.
I personally think that the poor methodology of this post would never have survived to see the light of day if the conclusions did not match what programmers expect. Conversely the methodological flaws mean that we should be very careful about accepting the data for any conclusion beyond, "Well, it looks like what I expect."
Fair enough. That is an entirely valid critique. However, I do not think this makes the article worthless. Given the apparent correlation between known expressiveness and the data derived here, it may be that they had a good notion using length-of-commit as a measure for expressiveness.
> it may be that they had a good notion using length-of-commit as a measure for expressiveness.
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?
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?
I think this plot begs a different question... which languages are being abused by the development community?
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.
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.
I agree. I was also surprised by Ruby's position. I suspect the problem is related to that with JavaScript. That is to say, people including code in their commits that they didn't write.
Actually, I think thats exactly the problem. There is a general perception based on anecdotal experience, followed by a non rigorous 'scientific' data 'experiment', followed by analysis of results which throws out all the data which disagrees with the original perception. Look at the actual results, they dont really show a strong correlation with 'common experience amound developers',
>Does anyone here really doubt that you can get more done with a single line of Python than a line of C/Java/C++?
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.
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.
These are valid lines of code (plus or minus a ;) in both languages.
That is exactly my point.
Well, then your point is to say that comparing two animals on the strength of their legs is ridiculous because both animals have legs. This is just a non sequitur. No one was confused about the fact that you can make a function call in C that does more than a variable assignment in Python.
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.
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.
No, my point is that comparing a single line of code is ridiculous. You can only get an understanding of the efficiency of a language when you look at many lines of code. I would think you would need a few thousand lines of code that did something non-trivial before the true picture emerges.
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.
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.
Yeah, sure. That's what an average is. It is taking the performance of a large case and reducing it to a single unit in order to make comparisons.
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.
It is really a joy to develop with (though my being a Ruby programmer probably makes me a somehow biased and enthusiastic candidate).
It is really a joy to develop with (though my being a Ruby programmer probably makes me a somehow biased and enthusiastic candidate).
Now I want to see the same thing, but based on the length of the commit message instead.
Wait... JavaScript and CoffeeScript end up at opposite extremes while having near-enough identical semantics?
That's a big red flag on this as a measure of expressiveness.
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.
I'd say it's a byproduct of the fact that only in-the-know developers are using CoffeeScript, while JavaScript is being written by every rank-and-file amateur web dev in the world. There is likely an inverse correlation between language popularity and median code quality.
At the risk of being a bit incendiary, I would observe that you can apply that alternate hypothesis across pretty much the entire chart. One could propose that what we see there is something more like "inverse average skill of the developers using this language". JS is an outlier due to the fact that the language's position on the web has a lot of hacks using it. (This is not itself a reflection on the language, but on its position in the world.) It's not perfect (I'd toss Auguas and Puppet out of this entirely as they aren't really programming languages; assembler probably really is a lack of expressiveness, VHDL possibly the same), and I'm not really proposing it as The Answer, but it is an interesting and viable alternate hypothesis.
I'm thinking that's mostly due to the testing methodology. In JS it's pretty common to start a project by downloading and committing jQuery, Underscore, and whatever framework dependencies you're using. And just speaking from experience, coffeescript is better, but it's not _that much_ better (I'd guess ~1.5 lines of JS per line of CS, the chart shows somewhere around 8:1).
Coffeescript, I find, is more apt to force you into a more cohesive pattern for structuring your code which could help avoid large refactoring stints.
Yeah, this is clearly broken for Javascript. I don't think they're counting imported packages and libraries as extra LoC for other languages, but for Javascript they seem to be counting a jQuery import as an additional 9,597 LoC in the commit.
On the other hand, I guess they probably aren't counting inline Javascript in HTML files.
On the other hand, I guess they probably aren't counting inline Javascript in HTML files.
Yeah, I agree — I really doubt it's that large of a shift, as I mentioned under "Specific language effects." I find it hard to believe that JavaScript could really be less expressive than C and assembly.
I also found it interesting that Objective-J is well ahead of Objective-C. The parts of those languages that are not pure Javascript and C, respectively, seem like they should be equally expressive. Especially when Javascript and C score side by side, eliminating any effects by expressiveness of the subset language.
I think one point that has been overlooked so far is that many projects might copy in a bunch of JavaScript (jQuery, etc.) and then write the glue code in CoffeeScript. So you get a commit with 3kloc JavaScript and maybe 20loc CoffeeScript.
> let the results speak for themselves
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?)
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?)
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.
There is surely some correlation between short commits and expressiveness, but they're far enough apart that I think the title is very misleading.
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.
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.
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.
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.
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.
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.
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).
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).
Hah! Take that, Python aficionados!
-- Perl user
-- Perl user
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.
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.
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.
[deleted]
Does this data take into effect the total lines of code in the project being committed to? Would this not have an effect on the results?
No, it's a combined total across all ~7.5 million open-source projects in Ohloh, so (potentially real) effects like that are averaged out.
No sign of RPL, which is insanely expressive :(
Right, I did restrict languages to a popular subset defined in another post: http://redmonk.com/sogrady/2013/02/28/language-rankings-1-13...
Are you referring to the programming language for calculators? Wikipedia doesn't make it seem that expressive, and I can't find much else associated with the acronym RPL.
Yes. The Wikipedia article is to be honest, crap. RPL is a functional stack based language sort of like lisp and forth combined with mathematica thrown in for good measure.
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.
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.
>One proxy for this is how many lines of code change in each commit
This premise is complete rubbish.
This premise is complete rubbish.
APL and J would win this handily, but we don't use those languages for a reason.
Hm, how can Objective-J have such a different ranking than Objective-C?
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.
A related hypothesis is that it might be tied more closely to a language's packaging system than expressiveness. I've noticed in some of the projects I'm involved in that commits are often related to packages, with people more likely to roll multiple things into one commit if they're to the same file or package, and more likely to split them if they're updates to things that the language itself splits. Might be cultural, or might be related to it being easier to modularize your own contributions when the language has defined module boundaries to help you out. So languages that favor more small packages may (though I have no evidence!) see smaller average commit size than those which favor fewer, more monolithic packages (or source files).
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.
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.
This is likely a graph of languages ranked by CDD usage (Copypasta Driven Development).
That's certainly a possibility in some cases and communities (perhaps at a sub-language level or for very niche languages), but I find it rather unlikely on a global level considering the trends across many languages and language classes that you can see here.
I don't think it's the community that makes up for the bias, more importantly it's not normalized with respect to the size of the project, sure CoffeeScript won't have much lines per commit since 90% of the time the commit will be something like "make this slide-in twice as fast", where meanwhile Eclipse/Firefox/LAPACK etc. get done in Java/C/C++/Fortran. Also for the less widely used languages the sample is certainly much smaller and most projects are toy exercises. Anyway, C# is next to Assembly, and shell scripts next to Smalltalk, so what are we talking about here...
Agreed. He also fails to control for variation in project types that languages are commonly used for. e.g. perl/bash are often used to write short scripts, where as Java is typically used for enterprise applications; so of course the commits for the former will have smaller commits than the later.
"Having a community that likes lots of small commits..."
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.
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.
I'd agree, I'd expect something like APL to show up on here in terms of sheer expressiveness. While it can be a pain to program in because of the funky characters, it's actually very very expressive.
APL is insufficiently popular to be considered here, otherwise I'm sure you would be right.
Yep. And even then it doesn't take into account the fact that writing tests is more common in some languages (Ruby, for instance) than it is in others.
That's why I think people should take a look at the next generation of Rebol http://www.red-lang.org/.
Fast as C, expressive as Lisp, and more readable than Ruby...well, that's the goals at least ;)
Fast as C, expressive as Lisp, and more readable than Ruby...well, that's the goals at least ;)
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.