3 ms·

They're probably BOTH quite literally billion dollars mistakes.

WalterBright 4y ago
I remember the bad old DOS days where a null pointer write would scramble DOS. I absolutely hated that, and it cost me a lot of extra work. Enter protected mode programming. It was a miracle! Null pointer writes now meant a seg fault with a traceback, and voila! A few minutes of fix and I'm on my way. I immediately switched all my dev work to a protected mode system, and ported to real mode only as a last step. Buffer overflows are the primary entry point for malware. Seg faults are not. Hence the former are far more costly.
unxdfa 4y ago
I can confirm I have fucked up on numerous occasions which resulted in NPEs which caused business processes to fail spectacularly and write off millions of dollars instantly. Fortunately in every case it was possible to recover, replay or repair the data so the only real cost was a little bit of reputation and time and money. But that adds up across tens of thousands of engineers, probably to billions by now globally. I learned a lot from this and discovered that the real issue is that a process can fail spectacularly and do any damage at all. There are so many other concerns other than NPEs which need to be considered.
- imoverclocked 4y ago
  > There are so many other concerns other than NPEs which need to be considered. Yes. However, not all of those are trivially avoidable by just slightly changing the tech underneath. I chose a battle with NPEs in a giant Java codebase and largely won. It wasn't trivial to do but the main take-away is that in order for Java to be backward compatible, javac can't enforce any mechanism to make a codebase consistent enough to be NPE free. One way to get this consistency is to change the semantics slightly to trace nulls accurately (some JVM languages attempt this and fail with 3rd party dependencies for eg) and enforce that you can't write code that will produce an NPE. There is even an errorprone plugin that does a pretty good (though not perfect) job of this called NullAway. For codebases that think they can do better and that "need" more flexibility in null handling, there are other frameworks. I'm hard-pressed to meet that need outside of legacy/untouchable code constraints.
- WalterBright 4y ago
  > the real issue is that a process can fail spectacularly and do any damage at all Yes, you nailed it!
jbverschoor 4y ago
I think a billion is heavily usually the impact
- jbverschoor 4y ago
  Underestimating

I remember the bad old DOS days where a null pointer write would scramble DOS. I absolutely hated that, and it cost me a lot of extra work. Enter protected mode programming. It was a miracle! Null pointer writes now meant a seg fault with a traceback, and voila! A few minutes of fix and I'm on my way. I immediately switched all my dev work to a protected mode system, and ported to real mode only as a last step. Buffer overflows are the primary entry point for malware. Seg faults are not. Hence the former are far more costly.

unxdfa 4y ago

I can confirm I have fucked up on numerous occasions which resulted in NPEs which caused business processes to fail spectacularly and write off millions of dollars instantly. Fortunately in every case it was possible to recover, replay or repair the data so the only real cost was a little bit of reputation and time and money. But that adds up across tens of thousands of engineers, probably to billions by now globally. I learned a lot from this and discovered that the real issue is that a process can fail spectacularly and do any damage at all. There are so many other concerns other than NPEs which need to be considered.

imoverclocked 4y ago
> There are so many other concerns other than NPEs which need to be considered. Yes. However, not all of those are trivially avoidable by just slightly changing the tech underneath. I chose a battle with NPEs in a giant Java codebase and largely won. It wasn't trivial to do but the main take-away is that in order for Java to be backward compatible, javac can't enforce any mechanism to make a codebase consistent enough to be NPE free. One way to get this consistency is to change the semantics slightly to trace nulls accurately (some JVM languages attempt this and fail with 3rd party dependencies for eg) and enforce that you can't write code that will produce an NPE. There is even an errorprone plugin that does a pretty good (though not perfect) job of this called NullAway. For codebases that think they can do better and that "need" more flexibility in null handling, there are other frameworks. I'm hard-pressed to meet that need outside of legacy/untouchable code constraints.
WalterBright 4y ago
> the real issue is that a process can fail spectacularly and do any damage at all Yes, you nailed it!

jbverschoor 4y ago

I think a billion is heavily usually the impact

jbverschoor 4y ago
Underestimating