There's a reason I used the word "problem" and not "bug" in my original post. In fact every time I found myself writing "bug", I deleted it and wrote "problem" instead. You're thinking very specifically about "bugs": clear spots a codebase that are clearly causing some clear error. That's actually a small percentage of the scope of "problems" that I'm talking about. Problems can be: your idea is bad, your architecture doesn't fit together, your performance is bad, your calculations are wrong, etc. Static typing, when done well, can help prevent many more of these issues than that narrow definition of "bug". Static typing helps you think clearly about your code.

> the marginal cost [of fixing a red squiggly] is approaching zero. But how many percentage of all bugs is that? And what is the cost?

The marginal cost of fixing a red squiggly underline is indeed basically zero for typos, and typos are a class of bugs I'd like my static type system to help me catch; and it does, and dynamic type systems generally don't. So the percentage of typos that become bugs is basically zero, but that's partly because of static typing! When you say "the percentage of all bugs", your definition of "bug" is a-priori excluding things that were caught before they became bugs!

But you can also get a red squiggly underline because you thought some variable was in scope when it's actually not -- that bug could have been caught earlier. The cost of fixing that bug is not near zero: the structure of your program is different between your brain and your code. The easiest bug to fix is the one you never write in the first place.

Or you get a red squiggly because you thought you could pass an object of type X into a method you're relying on, but you actually can't. Dynamic typing will not help you with this, and the cost of fixing that bug is not zero: again, your assumptions about how your program is fitting together are incorrect. I'd much rather realize that I can't use a method in exactly the way I thought right at the moment of typing it than later during test time. The latter requires writing and maintaining a test in order to catch a problem late that I could have caught early with no test.

> And why stop at static typing? Why don't you run ALL your code through Property Based Testing AND Mutation Testing 100% before shipping?

I directly addressed the subject of testing in my original post. Static typing allows me to write many fewer tests than dynamic typing.

> If the cost is a trillion dollars in programmer time to find a bug that takes 1 second to fix in production at a cost of a few dollars of programmer time, by definition it was NOT worth it.

I just don't understand this hypothetical. Why would it ever take a trillion dollars to prevent a bug that takes 1 second to fix in production? This just doesn't jive with any developer experience I've ever heard about, any example I've ever read about, or anything I can even imagine.

You seem to be operating under the assumption that introducing static typing makes you slower at programming, but we're claiming it's worth it. No, that's not my claim. My claim is that above some level of program complexity, static typing makes you strictly faster at programming, full stop. That level of program complexity may not be your internal server or whatever, but it definitely is most production-grade software out there.

> It's ALWAYS a tradeoff. Of course it is. Everything is. It's maddening to me that people refuse to see this when it's so blatantly obvious.

This is generally true in engineering, but not always. It is actually possible to simply advance the discipline. When you're building a suspension bridge, there's a tradeoff between Stainless Steel and High-Carbon Steel, but there's not a tradeoff between Steel and Popsicle Sticks. Unless, of course, you're building a toy or a proof of concept. Dynamic typing is fine for toys and proofs of concepts; nobody is disputing that. Professional engineers don't spend most of their time discussing the best way to build toys.