4 ms·

Interesting, but as a layman this seems totally backwards. If the underlying premise is flawed, who cares if the methodology is correct? If the original study h

by goto11 7y ago

Interesting, but as a layman this seems totally backwards. If the underlying premise is flawed, who cares if the methodology is correct? If the original study hadn't made errors like misclassifying some projects or commit messages, the result would still be based on an unfounded premise.

SiempreViernes 7y ago
To put it simply: if the methodology is sound then the premise can't be unfounded, because the premise is the source of the methodology.
- smt88 7y ago
  I think you may misunderstand what others mean when they say "premise". For this paper, the premise is that GitHub commit history indicates language quality. The methodology is then the implementation of the study: how do we classify each commit? How do we identify the base language in a repository? What would lead us to discard a repository as a data source? The methodology may be perfect, but you may still end up with nonsense because GitHub is not a comprehensive or representative source of data for studying programming.
  - SiempreViernes 7y ago
    No, pretty obviously the claim is that language properties will affect the type of commits being made, this is the premise they start from. The CACM paper then did a bad job of testing if this is true by not being vary careful with the labelling and cleaning of their data, a point on which they were then attacked. Please notice that they were critiqued on their methodology, not for thinking that commits are casually influenced by the design of the language they modify.
    - mumblemumble 7y ago
      Their premise is even more deeply flawed than that. AFAICT, they didn't consider selection bias seriously enough. I'm not sure if it's politically correct to say this, but, e.g., it's entirely possible that particularly meticulous coders are both more likely to select a strong, statically typed functional language and generate bugs at a lower rate. And that the effect turns out to be almost entirely due to the person and not the programming language. There are also some fundamentally unanswerable questions. Like, would dynamic typing come off looking better if the selection of dynamic languages weren't dominated by warty messes like php and ecmascript?
      - zzzcpan 7y ago
        > Like, would dynamic typing come off looking better if the selection of dynamic languages weren't dominated by warty messes like php and ecmascript? It already looks better if you consider that dynamic typing is more expressive and such languages take much less code to do the same thing and less time. This is not something that can be researched via commit messages, but it is rather obviously true, so the claim from the paper that "static typing is better" is also obviously false and is way out of paper's reach to even claim. But then again this is CS and such claims that go way beyond data and author's expertise are super common in CS papers. Personally I stopped taking CS papers seriously a long time ago.
        mumblemumble 7y ago
        > This is not something that can be researched via commit messages, but it is rather obviously true I am inclined to disagree. Both static and dynamic languages suffer from the same problem here: The most well-known examples from each camp are warty messes that make terrible case studies, let alone poster children.
      - luord 7y ago
        > I'm not sure if it's politically correct to say this, but, e.g., it's entirely possible that particularly meticulous coders are both more likely to select a strong, statically typed functional language I don't think you need to worry; this isn't "politically incorrect". It's just wrong. Agree with what you said afterwards, though: Meticulous coders probably are less likely to write bugs. But that will be true regardless of the languages they choose or prefer.
        mumblemumble 7y ago
        > It's just wrong. It's something everyone has a strong opinion on, but nobody's ever really figured out how to measure. Leaving it a subject that's still firmly in the province of conjecture. Typically self-affirming conjecture. Me, I like dynamic languages, but, given that this subject is pretty much a complete knowledge vacuum, populated only by occasional iffy, easily criticized studies like the one in question, I'm inclined to say that the only position that offers any decent chance of not being informed primarily by confirmation bias is to assume that, for the most part, none of us has any firm idea what they're talking about. Least of all oneself.
syrak 7y ago
> If the underlying premise is flawed, who cares if the methodology is correct? How do we know the premise is flawed? > The first step should be to show that the github dataset can be used to say anything about quality and productivity of things like language choice. How do you concretely do that? The initial paper, even if flawed, did a lot of work to try to control for confounding factors. To do what you said, you would have to put as much effort, if not more, to convince people that the results can be falsified to claim anything, with the same level of control in place. It's not even clear that counting commits is entirely meaningless. Getting some signal out of it does seem tremendously difficult, but not impossible. So questioning the methodology is really the only way to rebut the experiment.
mumblemumble 7y ago
The factor you're missing is the potential for a criticism to advance the discussion. Everyone believes that they occupy the intellectual high ground, and that it's everyone else who's guilty of confirmation bias and wooly thinking. Therefore, anybody else's accusations of confirmation bias and wooly thinking are merely a product of their own confirmation bias and wooly thinking, and can safely be ignored. Attacking the methodology mitigates this effect. By demonstrating that they spent serious time digging into it and trying to replicate it, the authors give a strong signal that they're not just exercising in armchair skepticism. This, in turn, lends rhetorical weight to their attack on the premise. Without it, it would be as easy to ignore, and as quickly forgotten, as your average comment on Hacker News.
scott_s 7y ago
> If the underlying premise is flawed, who cares if the methodology is correct? The post you're replying to includes an explanation addressing that point.

by goto11 7y ago

SiempreViernes 7y ago

To put it simply: if the methodology is sound then the premise can't be unfounded, because the premise is the source of the methodology.

smt88 7y ago
I think you may misunderstand what others mean when they say "premise". For this paper, the premise is that GitHub commit history indicates language quality. The methodology is then the implementation of the study: how do we classify each commit? How do we identify the base language in a repository? What would lead us to discard a repository as a data source? The methodology may be perfect, but you may still end up with nonsense because GitHub is not a comprehensive or representative source of data for studying programming.
- SiempreViernes 7y ago
  No, pretty obviously the claim is that language properties will affect the type of commits being made, this is the premise they start from. The CACM paper then did a bad job of testing if this is true by not being vary careful with the labelling and cleaning of their data, a point on which they were then attacked. Please notice that they were critiqued on their methodology, not for thinking that commits are casually influenced by the design of the language they modify.
  - mumblemumble 7y ago
    Their premise is even more deeply flawed than that. AFAICT, they didn't consider selection bias seriously enough. I'm not sure if it's politically correct to say this, but, e.g., it's entirely possible that particularly meticulous coders are both more likely to select a strong, statically typed functional language and generate bugs at a lower rate. And that the effect turns out to be almost entirely due to the person and not the programming language. There are also some fundamentally unanswerable questions. Like, would dynamic typing come off looking better if the selection of dynamic languages weren't dominated by warty messes like php and ecmascript?
    - zzzcpan 7y ago
      > Like, would dynamic typing come off looking better if the selection of dynamic languages weren't dominated by warty messes like php and ecmascript? It already looks better if you consider that dynamic typing is more expressive and such languages take much less code to do the same thing and less time. This is not something that can be researched via commit messages, but it is rather obviously true, so the claim from the paper that "static typing is better" is also obviously false and is way out of paper's reach to even claim. But then again this is CS and such claims that go way beyond data and author's expertise are super common in CS papers. Personally I stopped taking CS papers seriously a long time ago.
      - mumblemumble 7y ago
        > This is not something that can be researched via commit messages, but it is rather obviously true I am inclined to disagree. Both static and dynamic languages suffer from the same problem here: The most well-known examples from each camp are warty messes that make terrible case studies, let alone poster children.
    - luord 7y ago
      > I'm not sure if it's politically correct to say this, but, e.g., it's entirely possible that particularly meticulous coders are both more likely to select a strong, statically typed functional language I don't think you need to worry; this isn't "politically incorrect". It's just wrong. Agree with what you said afterwards, though: Meticulous coders probably are less likely to write bugs. But that will be true regardless of the languages they choose or prefer.
      - mumblemumble 7y ago
        > It's just wrong. It's something everyone has a strong opinion on, but nobody's ever really figured out how to measure. Leaving it a subject that's still firmly in the province of conjecture. Typically self-affirming conjecture. Me, I like dynamic languages, but, given that this subject is pretty much a complete knowledge vacuum, populated only by occasional iffy, easily criticized studies like the one in question, I'm inclined to say that the only position that offers any decent chance of not being informed primarily by confirmation bias is to assume that, for the most part, none of us has any firm idea what they're talking about. Least of all oneself.

syrak 7y ago

> If the underlying premise is flawed, who cares if the methodology is correct? How do we know the premise is flawed? > The first step should be to show that the github dataset can be used to say anything about quality and productivity of things like language choice. How do you concretely do that? The initial paper, even if flawed, did a lot of work to try to control for confounding factors. To do what you said, you would have to put as much effort, if not more, to convince people that the results can be falsified to claim anything, with the same level of control in place. It's not even clear that counting commits is entirely meaningless. Getting some signal out of it does seem tremendously difficult, but not impossible. So questioning the methodology is really the only way to rebut the experiment.

mumblemumble 7y ago

The factor you're missing is the potential for a criticism to advance the discussion. Everyone believes that they occupy the intellectual high ground, and that it's everyone else who's guilty of confirmation bias and wooly thinking. Therefore, anybody else's accusations of confirmation bias and wooly thinking are merely a product of their own confirmation bias and wooly thinking, and can safely be ignored. Attacking the methodology mitigates this effect. By demonstrating that they spent serious time digging into it and trying to replicate it, the authors give a strong signal that they're not just exercising in armchair skepticism. This, in turn, lends rhetorical weight to their attack on the premise. Without it, it would be as easy to ignore, and as quickly forgotten, as your average comment on Hacker News.

scott_s 7y ago

> If the underlying premise is flawed, who cares if the methodology is correct? The post you're replying to includes an explanation addressing that point.