I see a number of posts that proudly claim [...] that the article author is "misguided and inflammatory." I wrote that. I definitely don't mean to attack the a

I see a number of posts that proudly claim [...] that the article author is "misguided and inflammatory." I wrote that. I definitely don't mean to attack the author personally, just the content of this one article! I did try to choose those words carefully, though. I went back and forth a few times before deciding that, yes, the article is pushing what I think is a very counterproductive line, so the "totally misguided" seemed strong but fair. And it draws rather grand (and I think incorrect) conclusions from very thin data, hence "inflammatory". But it's hard to stay civil while also saying what you really mean; maybe I was a little too harsh. once you use the computers to calculate the real life stuff (like the movement of your car, or even the spaceship 50 million kilometers away) the worst thing you can do is introduce the "fatal discontinuities" in the processing I definitely agree with that, but silent overflows are just as likely to kill you in that scenario as a crash (and hopefully fast reboot) in a submodule. Imagine if the calculated brake pressure in your car wraps around from +MAX to 0, for example. And there's a story (apocryphal, I think) about a fighter jet that would roll 180 degrees if you flew into the southern hemisphere (negative latitude). A submodule crash is at least something you can plan for and test -- that's standard practice in large Erlang programs, for example. For safety-critical stuff, extremely careful and painstaking specification, coding and testing is the only solution. There's no silver bullet. Runtime overflow checks won't save you, but turning them off won't save you either.