Why Ada Is the Language You Want to Be Programming Your Systems With

> When we controlled for class size all of the effects disappeared, providing compelling evidence for a confounding effect of class size

Holy crap; are they really saying that all the various correlations seen between numerous software metrics and fault proneness are actually the effect of nothing but raw size?

That's so intuitive. Because in our daily experience, almost all reasonable approaches to to various aspects of program organization actually work fine in programs of a size that one programmer can comfortably fully understand and maintain. Even for any technique reviled as "bad" and discouraged in coding standards, there are counterexamples of it working fine. Those counterexamples are in the context of small programs, so we are told, "just wait, that approach will burn you in a big program". But it looks like what will burn you is just the size of that big program, no matter what techniques you wield, whether blessed or not.

That little paper you pointed to there (thank you) looks pretty darn important.

    class foo {
      foo() = default;
      ~foo() = default;
    };

Is actually the idiomatic version of that C++ class, far less repetitive.

From what I understand, the vast bulk of the onboard F-35 software is written in C++.

One wonders how much that's contributed to the lengthy delays in software delivery...

Regardless, it seems possible to eventually produce effective software using C++. ;-)

The answer for this is sanity checking and some kind of layered "reflexes".

I design for mission critical things on a regular basis, and one of the error modes I must accommodate is random bit flipping by cosmic rays, emf, or other failures.

Sometimes, it is possible to push things to a "safe" failure state and reboot (which often takes only 100 ms or so)

Sometimes, though, the error must be caught and corrected to a last known good value or something like that. Everything critical is sanity checked : overall boundaries, rate of change, state related boundaries, etc. Layers of "reflexes" are more robust than a single programmed behavior, because an error in one will be resisted by the others. So much the better when there are segregated systems to check each other.

Often, I'll have a "brilliant" system that performs to a very high standard and is complex and brittle. If the brilliant system fails, it just shuts down or reboots. Underneath the brilliant system is another layer or two. A "competent" system that is simpler and more robust, but less efficient and with soft failure modes, and a "brainstem" system that takes nothing for granted, even checking basic functions by bit flipping to negate stuck ram bits or broken ALU logic, but only tries to do a pasable job, reducing algorythmic complexity to its bare acceptable minimum.

Typically the system will generate a basic range of acceptable parameters at the lowest level (and take corrective action if needed), then refine the range at each subsequent level..rinse and repeat. That way, each lower level checks the ones above.

Or, you just fail downwards if errors are suspected. Either way.

Designing failure tolerant systems is not impossible, but it requires a different mindset.

I'm interested in generally applicable rules, too; in this case, the generally applicable rule is that there is no generally applicable default robust behavior—the behavior of detecting numeric errors and crashing the system was the worst possible behavior in this context, but in other contexts it would be the best possible behavior. As I explained in https://news.ycombinator.com/item?id=20935662, there was no acceptable way to handle such an error if it was detected at runtime. The only acceptable solution is to rigorously verify before runtime that the error is not going to happen, as Rust does with, for example, multithreaded data races. (Well, you can't rule out hardware malfunction, but if you can make it sufficiently improbable you can use the strategy that they did in fact use.)

However, default-ignore vs. default-explode isn't a difference between handling errors with IEEE-754-qNaN-style dataflow-tainting and CLU-style nonlocal control flow transfers, as you seem to think. In either case, algorithms that need data that could not be computed successfully will fail to get that data; in either case, you can write the code to either propagate that failure or to attempt to recover from it somehow. In either case, you will not be able to control the spacecraft if you needed that data to control it. The difference I was mentioning, which is not generally applicable, is that in unusual cases like the Ariane 5 disaster, where the erroneous data shouldn't have been computed in the first place because it wasn't needed, qNaN-style error handling clearly results in safer behavior.

But, in general, real-time control is not a place where there exists a "robust choice" when your software is broken. If your jet engine control software or your antilock braking software is broken, you're likely to die, and no error handling strategy can prevent that, at least not at the level we're talking about. Biological systems manage this situation by having a melange of somewhat-independent control loops using different algorithms that are constantly fighting for control of the organism; while this does seem to produce systems that are more resilient than engineered systems, it's less efficient and enormously more difficult to develop or understand, and it's the opposite direction from the rigorous certainty you and I favor.