The 2% figure doesn't take into account opportunity cost. Maybe a project written in a dynamic language has a well-engineered, comprehensive unit test suite tha

The 2% figure doesn't take into account opportunity cost. Maybe a project written in a dynamic language has a well-engineered, comprehensive unit test suite that is large enough to cover for most type errors. Maybe that same project in a statically-typed language might not require so many unit tests - or maybe it might. Maybe developers working on the dynamic language version of the project spend more time reading through the code to understand how unfamiliar modules work - or maybe they don't. This sort of stuff is far more useful to know - and far more difficult to measure. The 2% figure states little more than the fact that a project being developed by competent engineers can be debugged and tested to the point where the project becomes quite reliable and errors become rare, regardless of whether or not it is implemented using dynamic or static typing. I don't think any reasonable static typing advocate would try to argue that static typing is the only way to catch type errors. The parser study is even less informative. It covers a project of very small scope using both a custom language (with a type system of very little expressive power) and a custom development environment, and does not take into account long-term maintainability or extensibility. If you want evidence, keep on looking.