On Monday, 20 January 2014 at 19:27:31 UTC, Walter Bright wrote:
I infer you think that my arguments here are based on something I dreamed up in 5 minutes of tip-tapping at my keyboard. They are not. They are what Boeing and the aviation industry use extremely successfully to create incredibly safe airliners, and the track record is there for anyone to see.
No, but I think you are conflating narrow domains with a given practice and broader programming application development needs and I wonder what the relevance is to this discussion of having other options than bailing out. I assume that you were making a point that is of relevance to application programmers?? I assume that there is more to this than an anecdote?
And… no it is not ok to say that one should accept a buggy program to be in a inconsistent state until the symptoms surface and only then do a headshot, which is the reasoning behind one-buggy-implementation-running-until-null-crash. "you aren't ill until you look ill"?
But that is not what Boeing does, is it? Because they use a comparator: "we may be ill, but we are unlikely to show the same symptoms, so if we agree we assume that we are well." Which is a much more acceptable "excuse" (in terms of probability of damage). Why? Because a 0.001% chance of implementation related failure could be reduced to say 0.000000001% (depending on the resolution of the output etc).
Ideally safe-D should conceptually give you isolates so that an application can call a third party library that loads a corrupted file and crash on a null-ptr (because that code path has never been run before) and you catch that crash and continue. Yes, the library is buggy and only handles consistent files well, but as an application programmer that is fine. I only want to successfully load non-corrupt files, there is no need to fix that library. Iff the library/language assures that it behaves like it is run as an isolate (no side effects on the rest of the program). Wasting resources on handling corrupt files gracefully is pointless if you can isolate and contain the problem.
It is fine if HALT is the default in D, defaults should be conservative. It is not fine if the attitude is that HALT is the best option if the programmer thinks otherwise and anticipates trouble.
