4 ms·

The promise of static typing

32 points by oskarth 10y ago

deleted 10y ago
[deleted]
itsdrewmiller 10y ago
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 10y ago
  Agreed. I think (bugs/LOC) could even work.
  - gdwatson 10y ago
    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 10y ago
      APL is considered by many a write-only language.
- rbanffy 10y ago
  > Seems like controlling for overall project size is an important missing component of this analysis. That would bias the numbers against more concise languages.
reverius42 10y ago
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 10y ago
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 10y ago
  What about Ruby?
  - akras14 10y ago
    What about JavaScript?
  - Muges 10y ago
    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.
deleted 10y ago
[deleted]
andyfleming 10y ago
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 10y ago
It's impossible to find the truth by a single observational study with ten data points and tons of unaccounted variables.
ArkyBeagle 10y ago
static languages and dynamic languages simply have different ways to injure yourself.
chrisdevereux 10y ago
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.

32 points by oskarth 10y ago

deleted 10y ago

[deleted]

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 10y ago
Agreed. I think (bugs/LOC) could even work.
- gdwatson 10y ago
  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 10y ago
    APL is considered by many a write-only language.
rbanffy 10y ago
> Seems like controlling for overall project size is an important missing component of this analysis. That would bias the numbers against more concise languages.

reverius42 10y ago

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 10y ago

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 10y ago
What about Ruby?
- akras14 10y ago
  What about JavaScript?
- Muges 10y ago
  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.

deleted 10y ago

[deleted]

andyfleming 10y ago

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 10y ago

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

ArkyBeagle 10y ago

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

chrisdevereux 10y ago

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.