Program logic bugs vs input/environmental errors

[Ola Fosheim Grostad via Digitalmars-d]

On Saturday, 4 October 2014 at 09:40:26 UTC, Walter Bright wrote:
> Sorry, Ola, you've never written bug-free software, and nobody 
> else has, either.

I have, but only simple ones. This is also key to making systems 
robust. Army equipment tend to consist of few parts, robust 
construction, and as little fancy features as you can get away 
with. But it us often rather unconvinient and hard to adapt to 
non-army settings.

D is on the other side of the spectrum. Nothing wrong with it, 
but not really following the principles that would make it 
suitable for creating simple robust systems.

>> by the transaction engine. The world outside of the
>> transaction engine has NO WAY of affecting integrity.
>
> Hardware fails, too.

Sure, but the point is to have integrity ensured in a 
conceptually simple system that has been harnessed at a cost 
level that exceeds the budget of any single application.

> That doesn't mean there are no backups to the primary flight 
> control computer.

No, but the point is that the operational context matters. 
Robustness is something you have to reason about on a 
probabilistic level in relation to the operational context.

> The assumption that "proof" means the code doesn't have bugs is 
> charming, but still false.

A validated correctness proof ensures that the code follows the 
specification, so no bugs.

> > Failure can still happen if the stabilizing model is
> inadequate.
>
> It seems we can't escape bugs.

An inadeqate specification is not a bug!

> Again, warplanes are not built to airliner safety standards. 
> They have different priorities.

Indeed, so the operational context is what matters, therefore the 
app should set the priorities, not the language and libraries.