Re: status of PL/I as a viable language

[Hyman Rosen <hyrosen@mail.com>]

Ond�ej Tu�n� wrote:
> Not in all cases. Here a complex failure (failure of a Patriot battery) 
> was originally caused by a simple overflow error. And as someone already 
> pointed out, the complex failure would have never happened if the originating 
> simple error was detected and handled properly.

No. The claim was that the code was written under the assumption
that the overflow would not happen. In such a case, the problem
would never be "handled properly" since proper handling assumes
the belief that the problem can happen.

There also seems to be the assumption that the overflow error
happens while the battery was just sitting there. It is just
as possible that the overflow manifests only during launch, in
which case causing a reboot wouldn't be very helpful.

I've mentioned this many times before. Language checks such as
bounds checking, pointer checking, and overflow checking are
fine for testing. But when the application is released, it is
better to disable such checks in cases where continued operation
is important, because it's more likely that a program which
"gets away" with making such an error can keep working, whereas
detecting the error will just blow the program away.