Re: status of PL/I as a viable language

["John R. Strohm" <strohm@airmail.net>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1045839283.86671@master.nyc.kbcfp.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.

One of the luminaries of Computer Science answered that one many years ago.

He compared that strategy (specifically with array bounds checking) to
wearing a life jacket while playing about inside the sheltered harbor, but
discarding the life jacket upon venturing into the open ocean.

I think it was Tony Hoare, but it might have been Edsger Dijkstra or
Nicklaus Wirth.