https://news.ycombinator.com/item?id=17880722

Typical comments:

"`assertAndContinue` crashes in dev and logs an error and keeps going in prod. Each time we want to verify a runtime assumption, we decide which type of assert to use. We prefer `assertAndContinue` (and I push for it in code review),"

"Stopping all executing may not be the correct 'safe state' for an airplane though!"

"One faction believed you should never intentionally crash the app"

"One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble."

And on and on. It's unbelievable. The conventional wisdom in software for how to deal with programming bugs simply does not exist.

Here's the same topic on Reddit with the same awful ideas:

https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/

No wonder that DVD players still hang when you insert a DVD with a scratch on it, and I've had a lot of DVD and Bluray players over the last 20 years. No wonder that malware is everywhere.

On 8/31/18 3:50 PM, Walter Bright wrote:
> https://news.ycombinator.com/item?id=17880722
> 
> Typical comments:
> 
> "`assertAndContinue` crashes in dev and logs an error and keeps going in prod. Each time we want to verify a runtime assumption, we decide which type of assert to use. We prefer `assertAndContinue` (and I push for it in code review),"

e.g. D's assert. Well, actually, D doesn't log an error in production.

-Steve

On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:
> https://news.ycombinator.com/item?id=17880722
>
> Typical comments:
>
> "`assertAndContinue` crashes in dev and logs an error and keeps going in prod. Each time we want to verify a runtime assumption, we decide which type of assert to use. We prefer `assertAndContinue` (and I push for it in code review),"
>
> "Stopping all executing may not be the correct 'safe state' for an airplane though!"
>
> "One faction believed you should never intentionally crash the app"
>
> "One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble."
>
> And on and on. It's unbelievable. The conventional wisdom in software for how to deal with programming bugs simply does not exist.
>
> Here's the same topic on Reddit with the same awful ideas:
>
> https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/
>
> No wonder that DVD players still hang when you insert a DVD with a scratch on it, and I've had a lot of DVD and Bluray players over the last 20 years. No wonder that malware is everywhere.

You would probably enjoy this talk.

"Hayley Denbraver We Are 3000 Years Behind: Let's Talk About Engineering Ethics"

https://www.youtube.com/watch?v=jUSJePqplDA

I think that until lawsuits and software refunds due to malfunctions escalate to a critical level, the situation will hardly change.

Some countries do have engineering certifications and professional permits for software engineering, but its still a minority.

--
Paulo

On Fri, Aug 31, 2018 at 08:42:38PM +0000, Paulo Pinto via Digitalmars-d wrote:
> On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:
> > https://news.ycombinator.com/item?id=17880722
[...]
> > And on and on. It's unbelievable. The conventional wisdom in software for how to deal with programming bugs simply does not exist.
> > 
> > Here's the same topic on Reddit with the same awful ideas:
[...]
> Some countries do have engineering certifications and professional permits for software engineering, but its still a minority.
[...]

It's precisely for this reason that the title "software engineer" makes me cringe on the one hand, and snicker on the other hand.  I honestly cannot keep a straight face when using the word "engineering" to describe what a typical programmer does in the industry these days.

Where are the procedures, documentations, verification processes, safeguards, certifications, culpability, etc., etc., that make engineering the respected profession that it is?  They are essentially absent in typical software development environments, or only poorly aped in the most laughable ways.  Most "enterprise" software has no proper design document at all; what little documentation does exist is merely a lip-service shoddy hack-job done after the fact to justify the cowboying that has gone on before.  It's an embarrassment to call this "engineering", and a shame to real engineers who have actual engineering procedures to follow.

Until the software industry gets its act together and become a real, respectable engineering field, we will continue to suffer from unreliable software that malfunctions, eats your data, and crashes on unusual inputs for no good reason other than that it was never properly engineered.  And malware and catastrophic security breaches will continue to run rampant in spite of millions and billions of dollars being poured into improving security every year.  And of course, more and more of modern life is becoming dependent on devices controlled by software of such calibre (IoT... *shudder*).  It's a miracle that society hasn't collapsed yet!


T

-- 
There are three kinds of people in the world: those who can count, and those who can't.

On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:
> https://news.ycombinator.com/item?id=17880722
>
> Typical comments:
>
> "Stopping all executing may not be the correct 'safe state' for an airplane though!"

Depends on the aircraft and how it is implemented. If you have a plane that is fly by wire, and you stop all executing then even the pilot no longer has control of the plane anymore, which would be very bad.


> "One faction believed you should never intentionally crash the app"
>
> "One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble."
>
> And on and on. It's unbelievable. The conventional wisdom in software for how to deal with programming bugs simply does not exist.

Depends on the software being developed, for a game? Stopping at every assert would be madness. Let a lone having an over ubundance of asserts. Can't even imagine how many asserts there would be in for something like a matrix multiplication. An operation that would otherwise be branchless having numerous branches for all the index checks that would be done. Twice per scalar value access. And so on and so on.

> Here's the same topic on Reddit with the same awful ideas:
>
> https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/
>
> No wonder that DVD players still hang when you insert a DVD with a scratch on it, and I've had a lot of DVD and Bluray players over the last 20 years. No wonder that malware is everywhere.

TIL people still use DVD players all the while my desktops and laptops from the last 7+ years have not even had an optical drive.

On Friday, 31 August 2018 at 21:21:16 UTC, tide wrote:
> Depends on the software being developed, for a game? Stopping at every assert would be madness. Let a lone having an over ubundance of asserts. Can't even imagine how many asserts there would be in for something like a matrix multiplication.

If one is aware that something is asserting quite often, why don't they just fix the bug that causes that assertion to fail?

Furthermore, how often have we cursed about games that hung up with a blackscreen and didn't let us close them by any mean other than logging off? If they just crashed, we'd not have run into such problems.

On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote:
> On Friday, 31 August 2018 at 21:21:16 UTC, tide wrote:
>> Depends on the software being developed, for a game? Stopping at every assert would be madness. Let a lone having an over ubundance of asserts. Can't even imagine how many asserts there would be in for something like a matrix multiplication.
>
> If one is aware that something is asserting quite often, why don't they just fix the bug that causes that assertion to fail?

The asserts being there still cause slow downs in things that would otherwise not be slow. Like how D does assert checks for indices.

> Furthermore, how often have we cursed about games that hung up with a blackscreen and didn't let us close them by any mean other than logging off? If they just crashed, we'd not have run into such problems.

That's assuming an assert catches every error. Not all bugs are going to be caught by an assert. I don't think I've ever had a game hung up in a black screen and not be able to close it.

On Friday, 31 August 2018 at 21:40:50 UTC, tide wrote:
> The asserts being there still cause slow downs in things that would otherwise not be slow. Like how D does assert checks for indices.

After the bug is fixed and the app is debugged, there's no need to keep those assertions.
The release switch will do the job. Anyway, what's that got to do with the topic of this thread?


> That's assuming an assert catches every error. Not all bugs are going to be caught by an assert.

not really, at least that's not what I meant. (well, in theory one could write enough assertions to detect any error, but... nvm, I agree with you). What I meant were apps misbehaving because of obviously ignored errors.


> I don't think I've ever had a game hung up in a black screen and not be able to close it.

Lucky one :)

On Fri, Aug 31, 2018 at 09:40:50PM +0000, tide via Digitalmars-d wrote:
> On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote:
[...]
> > Furthermore, how often have we cursed about games that hung up with a blackscreen and didn't let us close them by any mean other than logging off? If they just crashed, we'd not have run into such problems.
> 
> That's assuming an assert catches every error. Not all bugs are going to be caught by an assert. I don't think I've ever had a game hung up in a black screen and not be able to close it.

I have, and that's only one of the better possible scenarios.  I've had games get into a bad state, which becomes obvious as visual glitches, and then proceed to silently and subtly corrupt the save file so that on next startup all progress is lost.

Had the darned thing aborted at the first visual glitch or unexpected internal state, instead of blindly barging on pretending that visual glitches are not a real problem, the save file might have still been salvageable.

(Yes, visual glitches, in and of themselves, aren't a big deal.  Most people may not even notice them.  But when they happen unexpectedly, they can be a symptom of a deeper, far more serious problem. Just like an assert detecting that some variable isn't the expected value. Maybe the variable isn't even anything important; maybe it just controls the color of the title bar or something equally irrelevant. But it could be a sign that there's been a memory corruption.  It could be a sign that the program is in the middle of being exploited by a security hack. The unexpected value in the variable isn't merely an irrelevant thing that we can safely ignore; it could be circumstantial evidence of something far more serious.  Continuing to barrel forward in spite of clear evidence pointing to a problem is utterly foolish.)


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy

On 8/31/2018 1:42 PM, Paulo Pinto wrote:
> Some countries do have engineering certifications and professional permits for software engineering, but its still a minority.

That won't fix anything, because there is NO conventional wisdom in software engineering for how to deal with program bugs. I suspect I am the first to try to apply principles from aerospace to general engineering (including software).

For example, in any CS program, are there any courses at all about this?