[dragonwriter]

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

[rohern]

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.

[dragonwriter]

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

[rohern]

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

[dragonwriter]

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

[rohern]

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.

[dragonwriter]

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