Re: status of PL/I as a viable language

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

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1045763933.848350@master.nyc.kbcfp.com...
> Richard Riehle wrote:
> > Ada is designed to maximize the amount of error checking possible
> > as early in the development process as possible.
>
> The problem is that those errors which are caught are gross errors
> of coding - buffer overruns, null pointer accesses, arithmetic
> overflow, etc. But serious errors in complex software aren't caused
> (only) by these sorts of errors.

So what's your point?

Are you trying to say you DON'T want to catch those "gross errors of
coding - buffer overruns, null pointer accesses, arithmetic overflow, etc."?

Any one of those "gross errors of coding" can and will crash an embedded
system, or, worse, cause it to fail in a bad way.  It was an overflowed
counter that caused a Patriot battery not to engage an incoming Scud,
resulting in the deaths of several U.S. servicemen.  The list of Microsoft
buffer overruns that have been exploited by virus authors is probably a LOT
longer than your johnson.  I saw a lot of VAX access violations on two
different TI products, years ago.

All of those errors CAN AND DO escape the development process, and they CAN
AND DO cause headaches for end users.

The last bug I found and fixed at my last employer was a null pointer
access.  That company has an internal coding policy that pointers will
ALWAYS be tested for null before being dereferenced.  They have mandatory
code walkthroughs.  This one still got through and crashed the box.  It took
about an hour just to SET UP the test to see the box crash, and I had to do
the test several times before I tracked down the error.  That was test time
I could have used doing something USEFUL, if the error had been caught
earlier.