Fixing C's Biggest Mistake

[Timon Gehr]

On 12/30/22 03:17, Walter Bright wrote:
> 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.
> ...

That's certainly not a reason to introduce even _more_ opportunities for 
bad things to happen...

> 
>> 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.
> ...

That's context-specific and for the programmer to decide. You can't have 
the backup take over if you blow up the plane.

> The idea that a program should soldier on once it is in an invalid state 
> is very bad system design.

Well, here it's the language that is encouraging people to choose a 
design that allows invalid states.

> 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.
> ...

Great, so let's just give up I guess. All D programs should just 
segfault on startup. They were not perfect anyway.

> 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".)

I am not saying software can't be allowed to fail, just that it should 
fail compilation, not at runtime.