6 ms·

Don't terminate a mission-critical process. Garden variety software: yes, PLEASE, DO kill it. You don't seem to realize that many of SW practices that are adeq

by zvrba 12y ago

Don't terminate a mission-critical process. Garden variety software: yes, PLEASE, DO kill it. You don't seem to realize that many of SW practices that are adequate for "normal" software, are NOT applicable to mission-critical, fault-tolerant scenarios.

mpweiher 12y ago
What's mission critical depends on the mission, it's not the language's job to decide what is or is not mission critical. Please tell me why killing my spreadsheet program is OK because the cat walked on the keyboard.
- pohl 12y ago
  If it's the case that your spreadsheet program can tolerate overflow on addition, shouldn't that program be using the &+ operator instead of the + operator? If, instead, detecting and responding to the overflow is what you want, then someone has already filed a rdar on that and Chris Lattner has replied saying: "It would be straight-forward for us to provide arithmetic functions that return the result as an optional (i.e., nil on overflow). We'll take a look, thanks for filing a bug!" https://devforums.apple.com/thread/232791 https://devforums.apple.com/thread/232791
  - mpweiher 12y ago
    Sorry, I'd rather have a language with sensible defaults. In this case, the sensible solution would be to have a proper Numeric tower like, for example, Smalltalk, where such overflows simply don't matter. The default "Int" type should be part of that system. You can then add Int32/Int64 or maybe IntNative to get to the built-in processor types, which then have built-in processor behavior, and possibly arithmetic overflow traps as an extension. The current defaults are just nuts, IMHO.
    - pohl 12y ago
      You've made that pretty clear in your writings (which I have enjoyed, by the way.) I'm curious, do you want Swift to be that language - and, if so, have you been participating in the dev forums[1] and filing bug reports into rdar? Would you mind sharing the rdar number that you filed about this issue so that others whose preferences lean in the same direction can add our voices to the chorus? And, if not, what is your goal? Edit: I see that you've answered my question on your blog[2] by answering someone else who asked the same thing. Thank you! [1] https://devforums.apple.com/community/tools/languages/swift https://devforums.apple.com/community/tools/languages/swift [2] http://openradar.appspot.com/17472835 http://openradar.appspot.com/17472835
      - vor_ 12y ago
        Marcel has made his feelings on Swift clear: http://openradar.appspot.com/17180612 http://openradar.appspot.com/17180612
    - dalke 12y ago
      In the context of the Ariane rocket, it seems like a language with a proper numeric tower would have been unlikely to run on the given hardware. That is, the decision to not add explicit range checks to a few of the variables (including the critical one which overflowed) was based in part on keeping the processor load down. > It has been stated to the Board that not all the conversions were protected because a maximum workload target of 80% had been set for the SRI computer. To determine the vulnerability of unprotected code, an analysis was performed on every operation which could give rise to an exception, including an Operand Error. In particular, the conversion of floating point values to integers was analysed and operations involving seven variables were at risk of leading to an Operand Error. This led to protection being added to four of the variables, evidence of which appears in the Ada code. I find it hard to believe that a language which checks every case for possible overflow would be faster than a language which does not (excluding possible program flow analysis that wasn't available then). Thus, I don't think the engineering tradeoffs for the Ariane really apply for a spreadsheet where gobs of excess cycles are available, so I find it difficult to use the errors with the former to guide the latter. That said, I recognize that you're on a different topic. I wanted only to point out that "the current default are just nuts" has nothing to do with exception handling in the Ariane, and I think using the Ariane as a basis for your explanation doesn't apply.
dalke 12y ago
I believe you have left out an important point. The correct failure mode is very dependent on the problem. For example, an off-course rocket just after launch may need to be blown up, because the primary concern is not "the mission" but range safety. While a rocket which lost an engine but is near LEO can likely recover by going to a lower orbit. What distinguishes avionics software from most "normal" software is the extensive (and expensive) analysis to determine the best fail-safe behavior for a wide variety of failure modes. Sometimes "fail-safe" means "self-destruct."

by zvrba 12y ago

mpweiher 12y ago

What's mission critical depends on the mission, it's not the language's job to decide what is or is not mission critical. Please tell me why killing my spreadsheet program is OK because the cat walked on the keyboard.

pohl 12y ago
If it's the case that your spreadsheet program can tolerate overflow on addition, shouldn't that program be using the &+ operator instead of the + operator? If, instead, detecting and responding to the overflow is what you want, then someone has already filed a rdar on that and Chris Lattner has replied saying: "It would be straight-forward for us to provide arithmetic functions that return the result as an optional (i.e., nil on overflow). We'll take a look, thanks for filing a bug!" https://devforums.apple.com/thread/232791 https://devforums.apple.com/thread/232791
- mpweiher 12y ago
  Sorry, I'd rather have a language with sensible defaults. In this case, the sensible solution would be to have a proper Numeric tower like, for example, Smalltalk, where such overflows simply don't matter. The default "Int" type should be part of that system. You can then add Int32/Int64 or maybe IntNative to get to the built-in processor types, which then have built-in processor behavior, and possibly arithmetic overflow traps as an extension. The current defaults are just nuts, IMHO.
  - pohl 12y ago
    You've made that pretty clear in your writings (which I have enjoyed, by the way.) I'm curious, do you want Swift to be that language - and, if so, have you been participating in the dev forums[1] and filing bug reports into rdar? Would you mind sharing the rdar number that you filed about this issue so that others whose preferences lean in the same direction can add our voices to the chorus? And, if not, what is your goal? Edit: I see that you've answered my question on your blog[2] by answering someone else who asked the same thing. Thank you! [1] https://devforums.apple.com/community/tools/languages/swift https://devforums.apple.com/community/tools/languages/swift [2] http://openradar.appspot.com/17472835 http://openradar.appspot.com/17472835
    - vor_ 12y ago
      Marcel has made his feelings on Swift clear: http://openradar.appspot.com/17180612 http://openradar.appspot.com/17180612
  - dalke 12y ago
    In the context of the Ariane rocket, it seems like a language with a proper numeric tower would have been unlikely to run on the given hardware. That is, the decision to not add explicit range checks to a few of the variables (including the critical one which overflowed) was based in part on keeping the processor load down. > It has been stated to the Board that not all the conversions were protected because a maximum workload target of 80% had been set for the SRI computer. To determine the vulnerability of unprotected code, an analysis was performed on every operation which could give rise to an exception, including an Operand Error. In particular, the conversion of floating point values to integers was analysed and operations involving seven variables were at risk of leading to an Operand Error. This led to protection being added to four of the variables, evidence of which appears in the Ada code. I find it hard to believe that a language which checks every case for possible overflow would be faster than a language which does not (excluding possible program flow analysis that wasn't available then). Thus, I don't think the engineering tradeoffs for the Ariane really apply for a spreadsheet where gobs of excess cycles are available, so I find it difficult to use the errors with the former to guide the latter. That said, I recognize that you're on a different topic. I wanted only to point out that "the current default are just nuts" has nothing to do with exception handling in the Ariane, and I think using the Ariane as a basis for your explanation doesn't apply.

dalke 12y ago

I believe you have left out an important point. The correct failure mode is very dependent on the problem. For example, an off-course rocket just after launch may need to be blown up, because the primary concern is not "the mission" but range safety. While a rocket which lost an engine but is near LEO can likely recover by going to a lower orbit. What distinguishes avionics software from most "normal" software is the extensive (and expensive) analysis to determine the best fail-safe behavior for a wide variety of failure modes. Sometimes "fail-safe" means "self-destruct."