5 ms·

I see a number of posts that proudly claim (in different forms) "fail early and fast" like it's a good thing to simply do a run-time crash always, and even that

by acqq 10y ago

I see a number of posts that proudly claim (in different forms) "fail early and fast" like it's a good thing to simply do a run-time crash always, and even that the article author is "misguided and inflammatory." I don't agree with both claims. Regarding the first, as an example where the crash is definitely not the solution, see the planteen's post: https://news.ycombinator.com/item?id=13117170 https://news.ycombinator.com/item?id=13117170 Or consider that 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. Regarding the second, allow me to just roll my eyes. The politics is not allowed this week on HN, but the political approaches start to be used automatically. Please just write which his claim is wrong. Labeling is destructive.

mikeash 10y ago
A crash is never the right solution. It is, however, likely to be a better solution than whatever random default behavior you might get. Regarding the linked comment, if the default had been to crash on overflow (or whatever the FPGA equivalent might be, if there is such a thing) then the problem would have been apparent the first time it happened, and they wouldn't be describing it as "a nasty bug" in the first place. A crash would not have been the best solution there, but it would have been miles better than the wrap that they actually got. As far as real life stuff, my understanding is that it's pretty common to fail fast and design the system to restart quickly so it can get back to work. If your needs are more sophisticated then you'd need to actually analyze the problem and come up with ways to handle unexpected data gracefully, not just hope that default behavior from the compiler ends up doing something sensible for your problem.
- z3t4 10y ago
  If 1-2 ms is too much to recover from a crash, you better have three or four backup systems written in different languages and running on different hardware. Yet there is no guarantee you will have 100% uptime. And in such a system, having data corruption would probably be far worse then a crash. One application where I think crashes are bad are computer games, for example if you are fighting a boss, it's better to get a few glitches then having the game crash.
  - mikeash 10y ago
    I'm not sure it's even true of computer games, since you might end up corrupting the player's save and destroying all of their progress. The argument for crashing is at least a bit weaker there, though.
- acqq 10y ago
  > If your needs are more sophisticated then you'd need to actually analyze the problem and come up with ways to handle unexpected data gracefully The case I've linked to provided exactly that kind of example: "The correct solution there was to saturate, not wrap, which is almost always the case in DSP code." I have an impression you've written your whole answer without reading it. And if you don't know what that means: https://en.wikipedia.org/wiki/Saturation_arithmetic https://en.wikipedia.org/wiki/Saturation_arithmetic Note that something like that is necessary only for the very performance critical code using integers, as today's FPU are also very fast and allow the representation of much bigger range of values: more than the number of the atoms in the observable universe can be fit in the FP number. Also note "Saturation arithmetic operations are available on many modern platforms, and in particular was one of the extensions made by the Intel MMX platform, specifically for such signal processing applications. This functionality is also available in wider versions in the SSE2 and AVX2 integer instruction sets." Not to mention the DSP processors. https://www.arm.com/products/processors/technologies/dsp-simd.php https://www.arm.com/products/processors/technologies/dsp-sim... "Zero overhead saturation extension support" Moreover, "the IEEE floating-point standard, the most popular abstraction for dealing with approximate real numbers, uses a form of saturation." All of this is a common knowledge by the professionals, and it's completely different from "just make an exception" approach that is so popular here. I claim that there's much bigger possibility that the author of the article knows about that than the commenters here that are responding (and voting) with the "just fail fast" mantra (or even claim that those who don't agree with their (probably poorly founded, as far as I see that) understanding are "inflammatory."
  - mikeash 10y ago
    I read it and understood it. I think we're talking past each other. You're saying, crashing is bad, it's better to figure out a correct response to overflow. I'm saying, choosing some default overflow behavior without any analysis is bad, it's better to crash. In some cases, you want to wrap. In others, you want to saturate. In others, you'll want to signal a failure. In still others, you'll want to fall back to bignums. There's no universal correct answer. But the discussion here is about what the language should do about overflow. The language has to pick some default behavior for the + operator, and it can only pick one. Some people are arguing that wrapping by default is the best choice, because it at least gives the program a chance of continuing to operate. I am arguing that the best default behavior is to crash, because continuing on when the programmer hasn't explicitly chosen the appropriate behavior is potentially disastrous. Of course the person who posted that comment didn't want their stuff to crash. But if the default behavior had been to crash (ignoring the likely impossibility of that in the context of an FPGA), their bug would have been a simple fix instead of something so nasty they still remember it. Sure, if the default had been to saturate then they would have avoided the bug, but only by coincidence, and this would just cause bugs elsewhere when people needed wrapping instead. The fourth word of your quote is key: "The correct solution there...." That was the correct solution in that spot, but it would not be the correct choice for default behavior for the + operator in a language.
Ericson2314 10y ago
Woah woah. The bug you link was hard to debug because the wrapping hid the error. Let's be clear, this is the opposite of fail fast.
iainmerrick 10y ago
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.

by acqq 10y ago

mikeash 10y ago

A crash is never the right solution. It is, however, likely to be a better solution than whatever random default behavior you might get. Regarding the linked comment, if the default had been to crash on overflow (or whatever the FPGA equivalent might be, if there is such a thing) then the problem would have been apparent the first time it happened, and they wouldn't be describing it as "a nasty bug" in the first place. A crash would not have been the best solution there, but it would have been miles better than the wrap that they actually got. As far as real life stuff, my understanding is that it's pretty common to fail fast and design the system to restart quickly so it can get back to work. If your needs are more sophisticated then you'd need to actually analyze the problem and come up with ways to handle unexpected data gracefully, not just hope that default behavior from the compiler ends up doing something sensible for your problem.

z3t4 10y ago
If 1-2 ms is too much to recover from a crash, you better have three or four backup systems written in different languages and running on different hardware. Yet there is no guarantee you will have 100% uptime. And in such a system, having data corruption would probably be far worse then a crash. One application where I think crashes are bad are computer games, for example if you are fighting a boss, it's better to get a few glitches then having the game crash.
- mikeash 10y ago
  I'm not sure it's even true of computer games, since you might end up corrupting the player's save and destroying all of their progress. The argument for crashing is at least a bit weaker there, though.
acqq 10y ago
> If your needs are more sophisticated then you'd need to actually analyze the problem and come up with ways to handle unexpected data gracefully The case I've linked to provided exactly that kind of example: "The correct solution there was to saturate, not wrap, which is almost always the case in DSP code." I have an impression you've written your whole answer without reading it. And if you don't know what that means: https://en.wikipedia.org/wiki/Saturation_arithmetic https://en.wikipedia.org/wiki/Saturation_arithmetic Note that something like that is necessary only for the very performance critical code using integers, as today's FPU are also very fast and allow the representation of much bigger range of values: more than the number of the atoms in the observable universe can be fit in the FP number. Also note "Saturation arithmetic operations are available on many modern platforms, and in particular was one of the extensions made by the Intel MMX platform, specifically for such signal processing applications. This functionality is also available in wider versions in the SSE2 and AVX2 integer instruction sets." Not to mention the DSP processors. https://www.arm.com/products/processors/technologies/dsp-simd.php https://www.arm.com/products/processors/technologies/dsp-sim... "Zero overhead saturation extension support" Moreover, "the IEEE floating-point standard, the most popular abstraction for dealing with approximate real numbers, uses a form of saturation." All of this is a common knowledge by the professionals, and it's completely different from "just make an exception" approach that is so popular here. I claim that there's much bigger possibility that the author of the article knows about that than the commenters here that are responding (and voting) with the "just fail fast" mantra (or even claim that those who don't agree with their (probably poorly founded, as far as I see that) understanding are "inflammatory."
- mikeash 10y ago
  I read it and understood it. I think we're talking past each other. You're saying, crashing is bad, it's better to figure out a correct response to overflow. I'm saying, choosing some default overflow behavior without any analysis is bad, it's better to crash. In some cases, you want to wrap. In others, you want to saturate. In others, you'll want to signal a failure. In still others, you'll want to fall back to bignums. There's no universal correct answer. But the discussion here is about what the language should do about overflow. The language has to pick some default behavior for the + operator, and it can only pick one. Some people are arguing that wrapping by default is the best choice, because it at least gives the program a chance of continuing to operate. I am arguing that the best default behavior is to crash, because continuing on when the programmer hasn't explicitly chosen the appropriate behavior is potentially disastrous. Of course the person who posted that comment didn't want their stuff to crash. But if the default behavior had been to crash (ignoring the likely impossibility of that in the context of an FPGA), their bug would have been a simple fix instead of something so nasty they still remember it. Sure, if the default had been to saturate then they would have avoided the bug, but only by coincidence, and this would just cause bugs elsewhere when people needed wrapping instead. The fourth word of your quote is key: "The correct solution there...." That was the correct solution in that spot, but it would not be the correct choice for default behavior for the + operator in a language.

Ericson2314 10y ago

Woah woah. The bug you link was hard to debug because the wrapping hid the error. Let's be clear, this is the opposite of fail fast.

iainmerrick 10y ago

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.