7 ms·

I’m surprised that with your experience you come to such unbalanced conclusions. Everything in engineering is about trade-offs and while your conclusions may be

by lixtra 6y ago

I’m surprised that with your experience you come to such unbalanced conclusions. Everything in engineering is about trade-offs and while your conclusions may be indisputable for the design goals of D they may wrong in other contexts. 1. If I scribble some one time code etc. the probability of having an error coming from implicit declarations is in the same order of magnitude as missing out edge cases or not getting the algorithm right for most people. The extra convenience may well be worth it. 2. I would relax this it should be clear to the programmer where a statement ends. 3. Go on with a warning is a sane strategy in some situations. I happily ruin my car engine to drive out of the dessert. The assert might have been to strict and i know something about the data so the program can ignore the assert failure.

tralarpa 6y ago
> 1. If I scribble some one time code .... and here is another entry for Walter's list of bad ideas: 4. "It's okay. I will use this code only once"
- erik_seaberg 6y ago
  My favorite Red Green quote is “now, this is only temporary … unless it works.”
unionpivo 6y ago
I disagree with most of what you said but I want to specifically call out: > 3. Go on with a warning is a sane strategy in some situations. No, if its sometimes ok, to continue, than you should not assert it. Assert means "I assert this will always be true, and if it's not our runtime is in unknown/bad state." If you think you can recover, or partially recover, throw/return appropriate error, and go into emergency/recovery mode.
- lixtra 6y ago
  Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits. Downvote me if you want to open a bug ticket with the vendor and wait a week for the fix. Upvote me if you’d give it a try to restart with a switch to ignore assertions. You may abstain if you never shipped a bug. Edit: not to forget that this website runs on lisp which violates all three. Was it really a bad choice for the website?
  - unionpivo 6y ago
    > Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits. Several points: 1. Most of such critical components have several different and independent implementations, with analog backup (if possible). 2. You are arguing one specific safety critical case, that 99.999% or even more programmers will never face, should somehow inform decision about general purpose programming language. 3. Even if you are working in such safety critical situation, you should not really on assertion bypass, but have separate emergency procedure, which bypasses all the checks and try's to force the issue. (ever saw a --force flag ?) Because what happens in reality, is developer encounters a bug (maybe while its still in development), notice you can bypass it by disabling assertions (or they are disabled by default), log it as a low priority bug, that never gets fixed. Then a decade later me or someone like me is cursing you because you enterprise app just shit the bed, and is generating tons of assertion warnings, even when it running normally, so I have to figure out, which of them are "just normal" program flow, and which one just caused an outage. I never experienced situation like you described, but I have experienced behavior like I wrote above, too many times. Botom line is: - don't assert if you don't mean it - if you need bypass for various runtime checks, code one in explicitly. Edit: Hacker News is written in ARC which is schema dialect. ARC doesn't have assertions as far as i can tell. ARC doesn't have its own runtime and is run on racket language, that has optional assertion, that exit the runtime if they fail https://docs.racket-lang.org/ts-reference/Utilities.html https://docs.racket-lang.org/ts-reference/Utilities.html
    - jrockway 6y ago
      I agree with this. Nuclear reactors are a special case of systems where removing energy from the system makes it more unsafe, because it generates its own energy and without a control system it will generate so much energy that it destroys itself (and due to the nature of radiation, destroys the surrounding suburbs too). With most systems, the safest state is off. CNC machine making a weird noise? Smash that e-stop. Computer overheating? Unplug it. With this in mind, "assert" transitions the system from an undefined state to an inoperative state, which is safer. That isn't to say that that you want bugs in your code, and that energizing some system is free of consequences. Your emergency stop of your mill just scrapped a $10,000 part. Unplugging your server made your website go down and you lost a million dollars in revenue. But, it didn't kill someone or burn the building down, so that's nice.
WalterBright 6y ago
Your rationale in this and your followups are exactly what I'm talking about. 1. You're actually right if the entire program is less than about 20 lines. But bad programs always grow, and implicit declaration will inevitably lead you to have a bug which is really hard to find. 2. The trouble comes from programmer typos that turn out to be real syntax, so the compiler doesn't complain, and people tend to be blind to such mistakes so don't see it. My favorite actual real life C example: for (i = 0; i < 10; ++i); { do_something(); } My friend who coded this is an excellent, experienced programmer. He lost a day trying to debug this, and came to me sure it was a compiler bug. I pointed to the spurious ; and he just laughed. (I incorporated this lesson into D's design, spurious ; produce a compiler error.) 3. I used to work for Boeing on flight critical systems, so I speak about how these things are really designed. Critical systems always have a backup. An assert fail means the system is in an unknown, unanticipated state, and cannot be relied on. It is shut down and the backup is engaged. The proof of this working is how incredibly safe air travel is.
- lixtra 6y ago
  > 3. I used to work for Boeing on flight critical systems, so I speak about how these things are really designed. Critical systems always have a backup. An assert fail means the system is in an unknown, unanticipated state, and cannot be relied on. It is shut down and the backup is engaged. I ask you to reconsider your assumptions. How did this play out in the 737 MAX crashes? Was there a backup AoA sensor? Did MCAS properly shut down and backup engaged? Was manual overriding the system not vital knowledge to the crew? You don’t have to answer. I probably wouldn’t get it anyway. But rest assured that I won’t try to program flight control and I strongly appreciate your strive for better software.
  - WalterBright 6y ago
    > How did this play out in the 737 MAX crashes? They didn't follow the rule in the MCAS design that a single point of failure cannot lead to a crash. > Was manual overriding the system not vital knowledge to the crew? It was, and if the crew followed the procedure they wouldn't have crashed.

by lixtra 6y ago

tralarpa 6y ago

> 1. If I scribble some one time code .... and here is another entry for Walter's list of bad ideas: 4. "It's okay. I will use this code only once"

erik_seaberg 6y ago
My favorite Red Green quote is “now, this is only temporary … unless it works.”

unionpivo 6y ago

I disagree with most of what you said but I want to specifically call out: > 3. Go on with a warning is a sane strategy in some situations. No, if its sometimes ok, to continue, than you should not assert it. Assert means "I assert this will always be true, and if it's not our runtime is in unknown/bad state." If you think you can recover, or partially recover, throw/return appropriate error, and go into emergency/recovery mode.

lixtra 6y ago
Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits. Downvote me if you want to open a bug ticket with the vendor and wait a week for the fix. Upvote me if you’d give it a try to restart with a switch to ignore assertions. You may abstain if you never shipped a bug. Edit: not to forget that this website runs on lisp which violates all three. Was it really a bad choice for the website?
- unionpivo 6y ago
  > Your reactor is boiling. Your control software shut down with assertion failed: temperature too high, cannot display more than 3 digits. Several points: 1. Most of such critical components have several different and independent implementations, with analog backup (if possible). 2. You are arguing one specific safety critical case, that 99.999% or even more programmers will never face, should somehow inform decision about general purpose programming language. 3. Even if you are working in such safety critical situation, you should not really on assertion bypass, but have separate emergency procedure, which bypasses all the checks and try's to force the issue. (ever saw a --force flag ?) Because what happens in reality, is developer encounters a bug (maybe while its still in development), notice you can bypass it by disabling assertions (or they are disabled by default), log it as a low priority bug, that never gets fixed. Then a decade later me or someone like me is cursing you because you enterprise app just shit the bed, and is generating tons of assertion warnings, even when it running normally, so I have to figure out, which of them are "just normal" program flow, and which one just caused an outage. I never experienced situation like you described, but I have experienced behavior like I wrote above, too many times. Botom line is: - don't assert if you don't mean it - if you need bypass for various runtime checks, code one in explicitly. Edit: Hacker News is written in ARC which is schema dialect. ARC doesn't have assertions as far as i can tell. ARC doesn't have its own runtime and is run on racket language, that has optional assertion, that exit the runtime if they fail https://docs.racket-lang.org/ts-reference/Utilities.html https://docs.racket-lang.org/ts-reference/Utilities.html
  - jrockway 6y ago
    I agree with this. Nuclear reactors are a special case of systems where removing energy from the system makes it more unsafe, because it generates its own energy and without a control system it will generate so much energy that it destroys itself (and due to the nature of radiation, destroys the surrounding suburbs too). With most systems, the safest state is off. CNC machine making a weird noise? Smash that e-stop. Computer overheating? Unplug it. With this in mind, "assert" transitions the system from an undefined state to an inoperative state, which is safer. That isn't to say that that you want bugs in your code, and that energizing some system is free of consequences. Your emergency stop of your mill just scrapped a $10,000 part. Unplugging your server made your website go down and you lost a million dollars in revenue. But, it didn't kill someone or burn the building down, so that's nice.

WalterBright 6y ago

Your rationale in this and your followups are exactly what I'm talking about. 1. You're actually right if the entire program is less than about 20 lines. But bad programs always grow, and implicit declaration will inevitably lead you to have a bug which is really hard to find. 2. The trouble comes from programmer typos that turn out to be real syntax, so the compiler doesn't complain, and people tend to be blind to such mistakes so don't see it. My favorite actual real life C example: for (i = 0; i < 10; ++i); { do_something(); } My friend who coded this is an excellent, experienced programmer. He lost a day trying to debug this, and came to me sure it was a compiler bug. I pointed to the spurious ; and he just laughed. (I incorporated this lesson into D's design, spurious ; produce a compiler error.) 3. I used to work for Boeing on flight critical systems, so I speak about how these things are really designed. Critical systems always have a backup. An assert fail means the system is in an unknown, unanticipated state, and cannot be relied on. It is shut down and the backup is engaged. The proof of this working is how incredibly safe air travel is.

lixtra 6y ago
> 3. I used to work for Boeing on flight critical systems, so I speak about how these things are really designed. Critical systems always have a backup. An assert fail means the system is in an unknown, unanticipated state, and cannot be relied on. It is shut down and the backup is engaged. I ask you to reconsider your assumptions. How did this play out in the 737 MAX crashes? Was there a backup AoA sensor? Did MCAS properly shut down and backup engaged? Was manual overriding the system not vital knowledge to the crew? You don’t have to answer. I probably wouldn’t get it anyway. But rest assured that I won’t try to program flight control and I strongly appreciate your strive for better software.
- WalterBright 6y ago
  > How did this play out in the 737 MAX crashes? They didn't follow the rule in the MCAS design that a single point of failure cannot lead to a crash. > Was manual overriding the system not vital knowledge to the crew? It was, and if the crew followed the procedure they wouldn't have crashed.