
The broken promise of static typing - type0
https://dev.to/danlebrero/the-broken-promise-of-static-typing
======
glangdale
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
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
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
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
I found myself wondering whether the paranoid mindset that finds static typing
reassuring is more likely to realize when code doesn't work.

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

