
The promise of static typing - oskarth
https://labs.ig.com/static-typing-promise
======
reverius42
This analysis seems a bit shallow and I'm not sure what point it's trying to
prove. There are a lot of factors that aren't accounted for (as other
commenters point out, project size is a major one), and a few others I can
think of that would affect the metric used (apparently bugs/repo):

* Project management strategy for the repo/project.

* Commercial vs. non-commercial project.

* Ability and experience of the developers.

* Popularity of the project.

* Type of project (library, application, etc.)

I suspect all of these will correlate in a meaningful way with the language
choice. Commercially produced or consumed projects may be more likely to have
comprehensive bug reporting/tracking, and are more likely to be in a
"mainstream" language, for instance.

Like Torvalds says, with enough eyeballs, all bugs are shallow. A corollary to
that could be that without knowing how many eyeballs there are, and how well
they can see, you don't really know how many bugs there are, either.

------
Muges
This analysis fails to take into account the popularity of a language. The
repository of a library is likely to have more users if it's written in a
popular language, and these users will probably report more bugs and feature
requests.

Considering this I'm not surprised at all to see that Java, Python and C++
repositories have a higher "bug density" than Clojure, Go or Erlang ones.

~~~
leoh
What about Ruby?

~~~
Muges
I'm not saying that this metric measures language popularity, but that
language popularity seems to have a big influence on it. I may be wrong, but
that's what caught my eye when I read the article. There are plenty of other
factors that aren't accounted for, some of which have been pointed out by
other commenters.

------
itsdrewmiller
Does anyone know what unit is being used for the x axis on these charts?

Edit: Figured it out (total bugs / repo). Seems like controlling for overall
project size is an important missing component of this analysis.

~~~
egwynn
Agreed. I think (bugs/LOC) could even work.

~~~
gdwatson
That might be better, but it would still be misleading. "Denser" languages
would have more bugs per line, but also fewer lines per program.

I've never used APL and wouldn't want to debug it, but its bug-to-line ratio
could be much higher than Java and still come out ahead in practice.

~~~
rbanffy
APL is considered by many a write-only language.

------
andyfleming
This analysis seems as though it could be misleading. Couldn't the number of
bugs reported vs. the actual number of bugs that exist in the code differ
significantly?

------
cousin_it
It's impossible to find the truth by a single observational study with ten
data points and tons of unaccounted variables.

------
chrisdevereux
Aside from project size, the problem domains of libraries are likely to vary
hugely between languages. With statically typed languages being biased towards
either systems programming or more algorithmically complex tasks.

The proportion of Haskell libraries for tasks like string padding is probably
lower than the proportion of ruby or js libraries, for example.

------
ArkyBeagle
static languages and dynamic languages simply have different ways to injure
yourself.

