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.
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.
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.
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.
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.
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.
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".
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?
This is a terrific idea if it means that people become more open to expanding the size of Congress, an idea which is currently met with objections like 'Oh, but then we would need to build a bigger building'.
The Congress of the United States is absurdly small in relation to our population and absurdly unrepresentative as a result. The British House of Commons, which represents a country of 63 million persons, has 650 seats. The Canadian House of commons has 308 members (rising to 338 next election) representing 33 million persons. The entire US Congress, including the Senate, is only 538 seats, representing over 315 million persons. The House of Representatives has not been expanded since 1911 and the population of the United States has increased by 200 million since then.
Anything that makes this more achievable is worth having. The bonus of giving Congressmen the ability to work from their district in direct communication with the electorate is also worth having.
I think the most interesting question raised by this article is, "Why are the smart people graduating from college willing to get shafted by startups?"
Why are schools failing to teach engineers about caring for their own careers? I do not think most business majors would put up with kind of crap. They are all taught to negotiate for salary and to get high earnings early as a basis for later demands. They also understand how stock options work and that 0.5% over a four-year vesting cycle with no protection in the event of acquisition is an atrociously bad deal.
The additional advantage of this age group being that they generally have no experience with salary negotiations or normal work-life balance. In fact, if they're coming out of a top CS program, they are probably used to bonkers work-life balance, which is exactly what a startup will demand of them.
That's the banner headline. What a nightmare.