4 ms·

The problem with the debate is that it's all based on personal preference and anecdotes, all of which are subject to cognitive biases. What we really need is a

The problem with the debate is that it's all based on personal preference and anecdotes, all of which are subject to cognitive biases. What we really need is a proper study, but they are notoriously hard. The debate fundamentally comes down to 'under what circumstances is the extra cost of working with a static type system worth it for the benefits'. For a 15 line helper script of the sort I've just written, Python with its dynamic typing is (to me - a proponent of static typing) the fastest thing to work with due to the low overhead. To me there is a threshold of project complexity where the cost-benefit ratio flips. Is that actually true? Does that vary for all people?

IronBacon 8y ago
> What we really need is a proper study, but they are notoriously hard. Here you go: "A large-scale study of programming languages and code quality in GitHub"[0]. I've only read the abstract (are we OK on sharing sci-hub links? [1]), spoiler alert, according to this research some languages are more defect prone than others but the effect is small. [0] https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/abstract https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-... [1] sci-hub.se/10.1145/3126905
- rkangel 8y ago
  I'm aware of this study, and a couple of others. They are all only looking at one area of productivity though, because that's the available data. In this particular case, there's no indication of development time required to achieve that level of bugginess. Maybe in practice all projects do enough work to reach an average level of reliability, but then what's interesting is how much developer time is required to get there. It's a total cost analysis that's interesting - and there's a lot of costs. Cost of development, how that varies depending on required time to market, cost of bugs (fixing them, and loss of sales due to customer reliability concerns), cost of complexity as software has to be maintained over time.
  - IronBacon 8y ago
    > but then what's interesting is how much developer time is required to get there. Yeah, good point. I read an old research where they tried to test the "productivity" offered by different languages, but then it became difficult to asses the experience of the different developers...
taude 8y ago
I actually don't think a study is needed, because it's not a one-size fits all debate, I think which you agree with, too. I could argue either side for different teams, companies, velocity, goals. Just like your example, I'm a believer in dynamic for quick tooling, smaller teams, earlier product life cycle, etc. And static for larger products, with dynamic team composition, and longer life cycles, etc...

IronBacon 8y ago

> What we really need is a proper study, but they are notoriously hard. Here you go: "A large-scale study of programming languages and code quality in GitHub"[0]. I've only read the abstract (are we OK on sharing sci-hub links? [1]), spoiler alert, according to this research some languages are more defect prone than others but the effect is small. [0] https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/abstract https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-... [1] sci-hub.se/10.1145/3126905

rkangel 8y ago
I'm aware of this study, and a couple of others. They are all only looking at one area of productivity though, because that's the available data. In this particular case, there's no indication of development time required to achieve that level of bugginess. Maybe in practice all projects do enough work to reach an average level of reliability, but then what's interesting is how much developer time is required to get there. It's a total cost analysis that's interesting - and there's a lot of costs. Cost of development, how that varies depending on required time to market, cost of bugs (fixing them, and loss of sales due to customer reliability concerns), cost of complexity as software has to be maintained over time.
- IronBacon 8y ago
  > but then what's interesting is how much developer time is required to get there. Yeah, good point. I read an old research where they tried to test the "productivity" offered by different languages, but then it became difficult to asses the experience of the different developers...

taude 8y ago

I actually don't think a study is needed, because it's not a one-size fits all debate, I think which you agree with, too. I could argue either side for different teams, companies, velocity, goals. Just like your example, I'm a believer in dynamic for quick tooling, smaller teams, earlier product life cycle, etc. And static for larger products, with dynamic team composition, and longer life cycles, etc...