4 ms·

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

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

4 ms·

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

by glangdale 9y ago

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