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.
