[taneq]

Yeah, it's much better when you have to change something, and you miss an important step in the guts of the code somewhere, and the compiler DOESN'T warn you, and you continue merrily on your way, unaware that six months from now when that code path executes in the wild, it'll take your company offline for six hours while someone (probably you) sweats their box off trying to figure out what the hell just happened.

[wellpast]

This scares the hell out of me when I hear people say stuff like this, because if you think a type system is going to save you from your outages then that means you're not aware of a whole other more comprehensive, efficient and dynamic set of programming idioms and tools that will actually save you.

Here's how you know what I'm saying is true. Because you can go across the landscape of systems in the real world and see both crappy systems falling over and rock-solid systems humming along happily -- and the differentiation between these two categories is NOT a type system. It's one thing: it's who wrote it and what was their level of experience and what was their value system.

[taneq]

It's not going to automatically save me any more than a motorbike helmet will save me if I crash my bike. That's not going to stop me from wearing one, though.

I actually agree with your second paragraph, and I like to think the systems I build fall in the latter category, but I'm still not too proud to take whatever help the compiler can give me.

[wellpast]

You would stop wearing a bike helmet if:

   - It made you top heavy and more likely to crash
   - It reduced your speed in half

The tacit implication (or elephant in the room) when someone argues for types and the presumed safety they bring is the severe cost they impose. Now they save some costs too, for sure. But the balance that I see is far, far in the direction that they save much less than they cost. (When applied universally as they almost always are when applied.)