rohern

> "it just seemed strange that seeing a doctor (not even emergency room) cost roughly half as much as an iPad."

That's the banner headline. What a nightmare.

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.

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.

Obviously I and the writer of the article disagree with you that it fails the first case.

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.

This is exactly the point I am making.

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.

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.

These are valid lines of code (plus or minus a ;) in both languages.

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.

:D

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".