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.)
Alice: "Doing X will prevent bugs like Y!"
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).
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.
To repeat, you can harden a code base without rewriting it by using static analysis tools. This is not as true with static typing.
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.
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.
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...
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.
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.
If a test becomes unnecessary if you have static typing then you should never have written it in the first place. It's a bad test.
That seems a very strong - and unsupported - claim. Could you elaborate?
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.
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.
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.