4 ms·

The broken promise of static typing

39 points by type0 9y ago

glangdale 9y ago
An interesting idea, but note that the "bug density" seems to skyrocket as the projects are restricted to having more "stars", suggesting that bug density of a language (as measured by this post) is correlated to people actually caring about the project. It's possible that the association exists here, but it would be better to see a scatterplot of various metrics (stars/watchers/forks/activity metrics) against "bug density" with languages plotted in different colors. It wouldn't surprise me if the 'no one gives a shit about your toy system' factor is higher than the 'which language you chose' factor.
- MaulingMonkey 9y ago
  Aye. Even ignoring per-project issues, there are so many compounding factors in these language shootouts as well - although I would be interested in seeing one comparing, say, "comparable" JavaScript vs TypeScript projects. But it's hard to nail down all the compounding factors. Give me a static typing system that requires no effort on my part (e.g. is entirely inferred, negligible build time penalties, etc.) and has zero false positives (e.g. every type error reported by it is an actual bug to fix) and you'll have a very hard time convincing me this could be anything but a good thing, even on the most TDD driven of projects. It's basically a free lunch. The question then, is not if static typing conceptually is a good thing, but which static typing systems (if any) make satisfactory tradeoffs - and thus are more beneficial than not. With the rise of larger codebases and hard to exhaustively test things like multithreaded, multiprocess, and multinode code, I only find myself moving more and more towards static analysis (including static typing) on top of dynamic approaches (not just TDD, but various assertions, telemetry, logging, fuzzing, chaos monkeys, etc.)
SirSavary 9y ago
I'm sure there are a few problems with this analysis that people smarter than I can point out but one thing that does come to mind is the age of a repository. I'm fairly confident that most of the highly starred Java and C++ repositories are much older than the ones for other languages. I'm not sure if the graphs took age into account but if they didn't, they should. A library that's been around for 10 years will likely have more than one that's been around for 1 years so it's not really a fair comparison.
- marcus_holmes 9y ago
  This is a good point. Maybe measuring bugs/year instead of bug count total would work better. Of course, what you want is all your bugs to be discovered quickly. It'd be interesting to see the bug/year count across all projects for each language, too. I suspect dynamic languages are prone to "coping" with bugs for longer, until a broken edge case is discovered.
  - concede_pluto 9y ago
    I found myself wondering whether the paranoid mindset that finds static typing reassuring is more likely to realize when code doesn't work.
deleted 9y ago
[deleted]
Pitarou 9y ago
What a great idea for an analysis, but I can’t see ANY patterns in the data. I thought the expressiveness of the language might be a factor. A line of Haskell does more than a line of Java, so it there is more room for bugs. Clearly not. I thought the age of the language might a factor. We would hope that language designers learn from what has gone before, and make better languages. But Erlang, one of the oldest in the sample, is also one of the least bug-prone. The one that really shocked me is Ruby vs Python. The two are similar in so many ways, and on the points where they differ, I would have expected that Python’s “one way to do it” philosophy would have made it less bug-prone. That’s clearly not how it works.
ankurdhama 9y ago
IMHO the promise of static typing is about having more structure in your code that can help you with understanding of the code and also help to figure out more patterns in your code to refactor and reduce complexity.
nickm12 9y ago
This is a click-bait headline coupled with a terrible analysis. I don't even know what "bug density" is because the author doesn't define it, but I assume it is some count of bugs divided by lines of code. It doesn't seem like the author tried to normalize or control for any factor, including basic ones like the age of the project. I'm not sure what a sound approach to answering this question is—I think this is a topic worthy of academic study—but this is definitely a low-quality analysis.
- yawaramin 9y ago
  The author defined it after responding to comments--he says it's bugs per repo. So, a repo with 10 lines of code and 1 bug is, according to him, less buggy than a repo with 100 lines of code and 2 bugs. Also, note that projects in dynamically-typed languages tend to be smaller since people tend to switch over to static types for larger projects. So this 'analysis' is pretty much designed to 'find' that dynamically-typed language projects are less buggy.
kwhitefoot 9y ago
An important feature of Erlang is single assignment. This is something that I try to enforce in all the languages that I use (VB.Net, VBA, C#, Java, Javascript) and it definitely reduces the bug count in my code. Unfortunately the two languages I use most, C# and VB.Net, do not have a way of declaring a local variable so as to enforce single assignment so I have to inspect the code. Final in Java and const in JS save me a lot of grief.

39 points by type0 9y ago

An interesting idea, but note that the "bug density" seems to skyrocket as the projects are restricted to having more "stars", suggesting that bug density of a language (as measured by this post) is correlated to people actually caring about the project. It's possible that the association exists here, but it would be better to see a scatterplot of various metrics (stars/watchers/forks/activity metrics) against "bug density" with languages plotted in different colors. It wouldn't surprise me if the 'no one gives a shit about your toy system' factor is higher than the 'which language you chose' factor.

MaulingMonkey 9y ago
Aye. Even ignoring per-project issues, there are so many compounding factors in these language shootouts as well - although I would be interested in seeing one comparing, say, "comparable" JavaScript vs TypeScript projects. But it's hard to nail down all the compounding factors. Give me a static typing system that requires no effort on my part (e.g. is entirely inferred, negligible build time penalties, etc.) and has zero false positives (e.g. every type error reported by it is an actual bug to fix) and you'll have a very hard time convincing me this could be anything but a good thing, even on the most TDD driven of projects. It's basically a free lunch. The question then, is not if static typing conceptually is a good thing, but which static typing systems (if any) make satisfactory tradeoffs - and thus are more beneficial than not. With the rise of larger codebases and hard to exhaustively test things like multithreaded, multiprocess, and multinode code, I only find myself moving more and more towards static analysis (including static typing) on top of dynamic approaches (not just TDD, but various assertions, telemetry, logging, fuzzing, chaos monkeys, etc.)

SirSavary 9y ago

I'm sure there are a few problems with this analysis that people smarter than I can point out but one thing that does come to mind is the age of a repository. I'm fairly confident that most of the highly starred Java and C++ repositories are much older than the ones for other languages. I'm not sure if the graphs took age into account but if they didn't, they should. A library that's been around for 10 years will likely have more than one that's been around for 1 years so it's not really a fair comparison.

marcus_holmes 9y ago
This is a good point. Maybe measuring bugs/year instead of bug count total would work better. Of course, what you want is all your bugs to be discovered quickly. It'd be interesting to see the bug/year count across all projects for each language, too. I suspect dynamic languages are prone to "coping" with bugs for longer, until a broken edge case is discovered.
- concede_pluto 9y ago
  I found myself wondering whether the paranoid mindset that finds static typing reassuring is more likely to realize when code doesn't work.

deleted 9y ago

[deleted]

Pitarou 9y ago

What a great idea for an analysis, but I can’t see ANY patterns in the data. I thought the expressiveness of the language might be a factor. A line of Haskell does more than a line of Java, so it there is more room for bugs. Clearly not. I thought the age of the language might a factor. We would hope that language designers learn from what has gone before, and make better languages. But Erlang, one of the oldest in the sample, is also one of the least bug-prone. The one that really shocked me is Ruby vs Python. The two are similar in so many ways, and on the points where they differ, I would have expected that Python’s “one way to do it” philosophy would have made it less bug-prone. That’s clearly not how it works.

ankurdhama 9y ago

IMHO the promise of static typing is about having more structure in your code that can help you with understanding of the code and also help to figure out more patterns in your code to refactor and reduce complexity.

nickm12 9y ago

This is a click-bait headline coupled with a terrible analysis. I don't even know what "bug density" is because the author doesn't define it, but I assume it is some count of bugs divided by lines of code. It doesn't seem like the author tried to normalize or control for any factor, including basic ones like the age of the project. I'm not sure what a sound approach to answering this question is—I think this is a topic worthy of academic study—but this is definitely a low-quality analysis.

yawaramin 9y ago
The author defined it after responding to comments--he says it's bugs per repo. So, a repo with 10 lines of code and 1 bug is, according to him, less buggy than a repo with 100 lines of code and 2 bugs. Also, note that projects in dynamically-typed languages tend to be smaller since people tend to switch over to static types for larger projects. So this 'analysis' is pretty much designed to 'find' that dynamically-typed language projects are less buggy.

kwhitefoot 9y ago

An important feature of Erlang is single assignment. This is something that I try to enforce in all the languages that I use (VB.Net, VBA, C#, Java, Javascript) and it definitely reduces the bug count in my code. Unfortunately the two languages I use most, C# and VB.Net, do not have a way of declaring a local variable so as to enforce single assignment so I have to inspect the code. Final in Java and const in JS save me a lot of grief.