Because neither an advanced type system nor static analysis could catch bugs in program logic?)
The benefits of static typing (complie-time checks) are grossly exaggerated. If the claims were true, Java itself and Java projects would be much less buggy.)
Bob: "Oh, but it does nothing for bugs like Z. I just won't bother at all, then".
Why would you not want to try and remove an entire class of bugs if it were within your power to do so? Just look at all the effort companies like Facebook have poured into exactly this kind of problem with things like Hack and Flow (which make use of OCaml).
I think you're missing each other in terms of what static typing you mean.
Haskell or ML style static typing is very useful, completely changes the way you do things and gives you many guarantees.
C or Java static typing is almost useless with regards to bugs (see null) and serves mostly to annoy you. It has many of extra costs of stronger static typing, but gives you very little of the benefits.
Static analysis is more than just static typing. Notably, it is possible to leverage static analysis for solid gains in reliability against code bases without having to rewrite them to take advantage of a different typing paradigm.
To repeat, you can harden a code base without rewriting it by using static analysis tools. This is not as true with static typing.
C static typing can be very useful, if you are able to use it effectively.
There is, of course, a tremendous pile of things it doesn't do well, and a bunch of ways you can make it less useful for yourself, but the last C project I worked on I found it a tremendous help in refactoring compared to the nightmare I would have had without it.
No one said that it doesn't catch different types of "easy" type-mismatch bugs (which dynamic but strong typed languages will catch too at the first test run) - Clang, for example, warns a lot, and there are industry-strench static analysers for C. Nevertheless complex code is usually buggy. Integer overflows is very good example of a bug by human programmers.
You'd be surprised. Probably at both, but I hasten to get it in the conversation that static analysis is more than just static typing. By a long shot.
To me, simple static analysis can be over sold to the point that it is worthless. I swear, I see more effort put into detecting tabs versus spaces than I do things that actually reliably cause bugs. Seriously, unless you are writing make files, I just can't bring myself to care on tabs.
However, using some of the more advanced static analysis tools that don't just show where you forgot to do a null check, but also show where you pass in a null value... That is truly impressive and fixes bugs. Even better, these are things that can be used to harden a code base without having to rewrite it.
Or, you used a pointer, then checked whether it was null.
This is why you keep re-running it, by the way. You had your null check at the top of the function, and then in maintenance someone added something new at the top, not realizing that it needed to be after the null check...
> The benefits of static typing (complie-time checks) are grossly exaggerated. If the claims were true, Java itself and Java projects would be much less buggy.)
I have no stats here (and neither do you :)), but based on my experience, Java code does tend to be much less buggy when compared with dynamic-typed code, keeping the features and quality of developers the same. Of course, logical bugs don't get caught by static typing. But it helps a lot when refactoring code, or collaborating on the same codebase with many people, or changing someone else's code. These things become really important once the code base hits a certain size.
>Java code does tend to be much less buggy when compared with dynamic-typed code
I only see this happen when both the Java code and the dynamically typed code both have zero tests.
IME, once you actually start taking integration testing seriously and actually exercise your code even just a little, the benefits of static typing evaporate pretty quickly.
Have you looked at the clang analyzer that's integrated into Xcode (http://clang-analyzer.llvm.org/)? It doesn't catch everything, and sometimes gives false positives, but it is quite amazing how it visualizes problems in the program flow, going through several levels in the call hierarchy, following variable assignments over function calls, etc... in a few cases I was convinced that a problem was a false positive until I really took the time to understand what the static analyzer is trying to tell me and it turned out to be actual bugs.
In my opinion it is mostly poor integration into the coding workflow, and poor visualization of the analyzer warnings that lead to too little use of static code analysis, and another is a too wide-spread 'if it works at all, ship it' mentality.
I would not say grossly exaggerated, especially for languages with stronger type systems than Java. But the worst bugs I've encountered definitely came from code behaving exactly as intended. The flawless implementations of terrible, terrible ideas.
There's not much a language can do to protect a programmer from doing nonsense. Terse, explicit languages that are easy to reason about have a slight edge in that they make it easier to grasp the big picture. A powerful type system like that of Haskell can certainly help too. Practices that involves many eyes looking at the code help the most.
>The benefits of static typing (complie-time checks) are grossly exaggerated. If the claims were true, Java itself and Java projects would be much less buggy
I wouldnt call Java an "advanced type system". Take a look at Idris then try to say that with a straight face:
>Because neither an advanced type system nor static analysis could catch bugs in program logic
It certainly does if you indeed use an advanced type system.
The benefits of static typing (complie-time checks) are grossly exaggerated. If the claims were true, Java itself and Java projects would be much less buggy.)