Fixing C's Biggest Mistake

[Walter Bright]

On 12/29/2022 12:46 PM, Timon Gehr wrote:
> The bad thing is allowing programs to enter unanticipated, invalid states in the 
> first place...

We both agree on that one. But invalid states happen in the real world.


> Not all disasters are silent. Maybe you are biased because you only write batch 
> programs that are intended to implement a very precise spec.

I'm biased from my experience designing aircraft systems. You never, ever want 
an avionics program to proceed if it has entered an invalid state. It must fail 
instantly, fail hard, and allow the backup to take over.

The idea that a program should soldier on once it is in an invalid state is very 
bad system design. Perfect programs cannot be made. The solution is to not 
pretend that the program is perfect, but be able to tolerate its failure by 
shutting it down and engaging the backup.

I think the Chrome was the first browser to do this. It's an amalgamation of 
independent processes. The processes do not share memory, they communicate with 
interprocess protocols. If one process fails, its failure is isolated, it is 
aborted, and a replacement is spun up.

The hubris of "can't be allowed to fail" software is what allowed hackers to 
manipulate a car's engine and brakes remotely by hacking in via the keyless door 
lock. (Saw this on an episode of "60 Minutes".)