It's an inevitably frustrating debate because everyone has just drawn totally different conclusions from their experiences. For pretty much all your points, my

It's an inevitably frustrating debate because everyone has just drawn totally different conclusions from their experiences. For pretty much all your points, my conclusions are the exact opposite. (Except for "You need to do runtime validation" - of course that's true; but you absolutely can avoid doing most runtime validation.) Just to take one somewhat at random: > And good luck untangling your type definitions when your requirements change. I think it is exactly the opposite of the case that static types make it harder to adapt to changing requirements. In every dynamically typed system I've ever worked on, there have been important assumptions about data structures - sometimes checked dynamically in pre- or post- conditions, sometimes only checked in tests, and often simply not checked at all - scattered all around, such that changing requirements necessitated reasoning through the impact of the change on all these implicit assumptions. It was terrifying to make changes. Sure, easy to make a change and start up the application with the new code without a fuss. But to know whether the change broke some obscure codepath I hadn't considered or been aware of? Very difficult! I much prefer a static analysis pass saying, "hey, you changed this interface, did you know this codepath over here relied on that thing you changed?". Static type systems are not the only way to accomplish this, but in my view, they are a much less burdensome way to accomplish it than the level of dynamic validation and testing necessary to do so otherwise. But again, it's just a frustrating debate, because clearly you have the exact opposite experience! So where does it get us? Nowhere really...