Re: status of PL/I as a viable language

Re: status of PL/I as a viable language

[Richard Riehle]

"Donald L. Dobbs" wrote:

> Richard Riehle wrote:
> > "Donald L. Dobbs" wrote:
>
> >>PS: ADA ain't that great.  Even with the Pentagon's (DoD) legislative
> >>fiat they couldn't achieve widespread adoption.  It proved to be far too
> >>clunky for its original intent which was embedded real-time applications
> >>such as radar and fire-control systems.  Over time ADA will join Pascal
> >>as one of the wannabes that just didn't have enduring traction.
> >
> >
> > Actually, Ada is that great ...
> >
> >
> > It is used (I know this from first hand experience) very successfully
> > in a large number of embedded weapon systems, embedded avionics,
> > embedded commercial systems.   It flies airplanes (all the software
> > in the Boeing 777), drives communication satellites,  controls electrical
> > power plants (including nuclear),  and keeps ships active at sea.  It
> > is the primary language of the F-22, among others.
>
> Not to belabor a point, but one of the lead stories today on the
> Aviation Week web site www.aviationnow.com describes how the F-22
> program is now some $800 million overrun because of delays caused by
> unreliable software.  They can get it to run for about 8 hrs in the lab
> before it crashes, but in the actual test flights it fails within 3.5
> hours forcing the pilot to reboot the system while in mid-flight.  If
> they are using Ada as you contend, then this is a terrible indictment
> and confirms what I had heard earlier about the language's shortcomings.

Donald,

I will cross-post this to comp.lang.ada.

The F-22 is one of the most complex systems, software and
hardware, even conceived.   As we discussed earlier, with
regard to other language environments,  the quality of the
available tools can help only so much.

Ada is designed to maximize the amount of error checking possible
as early in the development process as possible.  I know of no other language
does this as well as Ada.    As stated earlier, competent people have used
Ada for a wide variety of successful large-scale, safety-critical software
systems.  On the other hand, less competent people have used Ada, PL/I,
C++, C, etc. for a wide variety of unsuccessful systems.   At least one
Ada failure that I know of by reports from participants rather than from
first-hand knowledge was an Air Traffic Control system.   The people
who were managing the system blamed Ada when they, the managers,
were the real problem.   At that time, other ATC systems had already
been completed in Ada and were successfully doing their job.   The
problem is not the language.  As someone else once said, "A fool
with a tool is still a fool."    From my vantage point, having a fairly
broad experience with a lot of programming languages, Ada, once it
is understood, continues to be the most appropriate choice for systems
such as the F-22.   The fact that developers can find a way to screw it
up does not detract from the value of the language.   If they can make
a mess using a language with the rigorous controls built into Ada,
imagine the magnitude of the mess they could make with, say, C++.
And, no, PL/I would not help with a system this large and complex.

Richard Riehle

Re: status of PL/I as a viable language

[Donald L. Dobbs]

Richard Riehle wrote:
> "Donald L. Dobbs" wrote:
> 
> 
>>Richard Riehle wrote:
>>
>>>"Donald L. Dobbs" wrote:
>>
>>>>PS: ADA ain't that great.  Even with the Pentagon's (DoD) legislative
>>>>fiat they couldn't achieve widespread adoption.  It proved to be far too
>>>>clunky for its original intent which was embedded real-time applications
>>>>such as radar and fire-control systems.  Over time ADA will join Pascal
>>>>as one of the wannabes that just didn't have enduring traction.
>>>
>>>
>>>Actually, Ada is that great ...
>>>
>>>
>>>It is used (I know this from first hand experience) very successfully
>>>in a large number of embedded weapon systems, embedded avionics,
>>>embedded commercial systems.   It flies airplanes (all the software
>>>in the Boeing 777), drives communication satellites,  controls electrical
>>>power plants (including nuclear),  and keeps ships active at sea.  It
>>>is the primary language of the F-22, among others.
>>
>>Not to belabor a point, but one of the lead stories today on the
>>Aviation Week web site www.aviationnow.com describes how the F-22
>>program is now some $800 million overrun because of delays caused by
>>unreliable software.  They can get it to run for about 8 hrs in the lab
>>before it crashes, but in the actual test flights it fails within 3.5
>>hours forcing the pilot to reboot the system while in mid-flight.  If
>>they are using Ada as you contend, then this is a terrible indictment
>>and confirms what I had heard earlier about the language's shortcomings.
> 
> 
> Donald,
> 
> I will cross-post this to comp.lang.ada.
> 
> The F-22 is one of the most complex systems, software and
> hardware, even conceived.   As we discussed earlier, with
> regard to other language environments,  the quality of the
> available tools can help only so much.
> 
> Ada is designed to maximize the amount of error checking possible
> as early in the development process as possible.  I know of no other language
> does this as well as Ada.    As stated earlier, competent people have used
> Ada for a wide variety of successful large-scale, safety-critical software
> systems.  On the other hand, less competent people have used Ada, PL/I,
> C++, C, etc. for a wide variety of unsuccessful systems.   At least one
> Ada failure that I know of by reports from participants rather than from
> first-hand knowledge was an Air Traffic Control system.   The people
> who were managing the system blamed Ada when they, the managers,
> were the real problem.   At that time, other ATC systems had already
> been completed in Ada and were successfully doing their job.   The
> problem is not the language.  As someone else once said, "A fool
> with a tool is still a fool."    From my vantage point, having a fairly
> broad experience with a lot of programming languages, Ada, once it
> is understood, continues to be the most appropriate choice for systems
> such as the F-22.   The fact that developers can find a way to screw it
> up does not detract from the value of the language.   If they can make
> a mess using a language with the rigorous controls built into Ada,
> imagine the magnitude of the mess they could make with, say, C++.
> And, no, PL/I would not help with a system this large and complex.
> 
> Richard Riehle
> 
Richard,

You're right in that good (really good) programmers can produce 
successful code not matter what tools (languages) they have to tolerate 
while poor programmers (or at least poorly trained) will screw it up no 
matter how good or bulletproof the language.  Your ATC example 
undoubtedly proves the point.

Regards,

   -- Don.

Re: status of PL/I as a viable language

[Preben Randhol]

Donald L. Dobbs wrote:
> Richard,
> 
> You're right in that good (really good) programmers can produce 
> successful code not matter what tools (languages) they have to tolerate 
> while poor programmers (or at least poorly trained) will screw it up no 
> matter how good or bulletproof the language.  Your ATC example 
> undoubtedly proves the point.

Yes, but if you are a good programmer you would want to use the most
appropriate tool. Espceially when time is not something you have a lot
of in a project.

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Hyman Rosen]

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.

Re: status of PL/I as a viable language

[John R. Strohm]

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

Re: status of PL/I as a viable language

[Larry Kilgallen]

In article <42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net>, "John R. Strohm" <strohm@airmail.net> writes:

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

Can you provide a citation for that incident ?

Re: status of PL/I as a viable language

[John R. Strohm]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:HVDh3osH+3al@eisner.encompasserve.org...
> In article
<42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net>, "John
R. Strohm" <strohm@airmail.net> writes:
>
> > 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.
>
> Can you provide a citation for that incident ?

This is from memory, twelve years ago.

Operation Desert Storm, near the end of the party, when Saddam Hussein was
lobbing Scuds and the U.S. was going crazy trying to find all of his Scud
launchers.  Incoming Scud detected, Patriot failed to engage, missile hit,
destroying (as I recall) a warehouse tent or a barracks tent, killing some
twenty troops.  Investigation showed that a timer had overflowed.  The
Patriot system designers assumed that the system would never be operated for
more than a few hours at a time, and the timer couldn't overflow in that
time.  This particular one had been up for several days.

Re: status of PL/I as a viable language

[Hyman Rosen]

John R. Strohm wrote:
> So what's your point?

My point is that the attitude I often sense on this newsgroup
is that using Ada will give you perfect code. (Not in so many
words, mind you, but definitely in attitude.)

> It was an overflowed counter

Assuming that this is even true, would it have been better
if the Patriot battery threw an exception? The (first?)
Ariane 5 incident was pretty much the same, and that was in Ada.

Re: status of PL/I as a viable language

[Hyman Rosen]

John R. Strohm wrote:
> The Patriot system designers assumed that the system  would never
 > be operated for more than a few hours at a time, and the timer
 > couldn't overflow in that time.

And so is this an illustration of how Ada would have helped,
or an illustration of how Ada would not have helped? Had Ada
code raised a numeric error at the overflow, would that have
caused the missile to engage its target properly?

Re: status of PL/I as a viable language

[Vinzent Hoefler]

Hyman Rosen wrote:

> Assuming that this is even true, would it have been better
> if the Patriot battery threw an exception?

In that particular case I'd assume, yes. Some kind of reboot/restart 
would have helped.

> The (first?) Ariane 5 incident was pretty much the same,

Not exactly. It was proven that this exception could never occur in 
normal operation, so assuming a hardware failure if that exception 
occured was IMO the right decision.

> and that was in Ada.

Yes. But the code was originally written for another system, the Ariane 
4.

Using the same code in Ariane 5 with the same assumptions as were valid 
for Ariane 4 was the failure, not the code itself. It was never written 
for the system it was used on and then - naturally - failed horribly.


Vinzent.

-- 
71:
        69 with two fingers up your ass.
                -- George Carlin

Re: status of PL/I as a viable language

[Hyman Rosen]

Vinzent Hoefler wrote:
> In that particular case I'd assume, yes. Some kind of reboot/restart 
> would have helped.

Which actually sounds just like what's happening in the F-22 case,
doesn't it? Things run for a few hours, then have to be rebooted.
That's not exactly a hallmark of a reliable system.

> It was proven that this exception could never occur in normal operation

Sounds pretty much the same to me - a design assumption is violated,
and the programming language error handlers start doing stuff that is
completely inappropriate to the situation out in the world.

> Using the same code in Ariane 5 with the same assumptions as were valid 
> for Ariane 4 was the failure, not the code itself.

And the people who used the Patriot battery for too long (again, assuming
this incident is true) caused the failure, not the software.

Which is to say, complex systems can have complex failure modes,
and the fact that some programming languages will catch simple
errors isn't going to help at all with the complex ones.

Re: status of PL/I as a viable language

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1045770511.855483@master.nyc.kbcfp.com...
> John R. Strohm wrote:
> > The Patriot system designers assumed that the system  would never
>  > be operated for more than a few hours at a time, and the timer
>  > couldn't overflow in that time.
>
> And so is this an illustration of how Ada would have helped,
> or an illustration of how Ada would not have helped? Had Ada
> code raised a numeric error at the overflow, would that have
> caused the missile to engage its target properly?

Yes, it probably would.

The uncaught exception would have taken the battery down, requiring an
operator restart, a few days at the very least, before the Scud in question
was launched.  This in turn would have generated a frantic phone call back
to Raytheon in the United States, and quite possibly generated a field patch
to eliminate the problem.  The workaround would be to reset the system
periodically, which opens very narrow windows during which a Scud might not
be engaged because the battery was rebooting, as opposed to having the
battery down AND NOT KNOWING ABOUT IT.  The obvious other step is to move a
second battery in, and NOT reboot both of them at the same time.

Re: status of PL/I as a viable language

[Vinzent Hoefler]

Hyman Rosen wrote:

> Vinzent Hoefler wrote:
>> In that particular case I'd assume, yes. Some kind of reboot/restart
>> would have helped.
> 
> Which actually sounds just like what's happening in the F-22 case,
> doesn't it?

To be honest, I don't know what's going on with the F-22.

> Things run for a few hours, then have to be rebooted.
> That's not exactly a hallmark of a reliable system.

I surely agree with that.

>> It was proven that this exception could never occur in normal
>> operation
> 
> Sounds pretty much the same to me - a design assumption is violated,

No, in the Ariane case, it was not an assumption, it was a proof. For 
the Ariane 4 system.

> and the programming language error handlers start doing stuff that is
> completely inappropriate to the situation out in the world.

It switched over to the backup system. Sounds reasonable when the 
exception should only occur in case of hardware failures.

>> Using the same code in Ariane 5 with the same assumptions as were
>> valid for Ariane 4 was the failure, not the code itself.
> 
> And the people who used the Patriot battery for too long (again,
> assuming this incident is true) caused the failure, not the software.

Well, let's say so: If the manual would have said, reboot the system 
every two hours, then... ;-)

But IMO the Ariane case was different. The system that failed on Ariane 
5 was proven to work correct on Ariane 4. The failure was in using the 
same software without reconsidering the proofs for the new parameters.

You wouldn't expect a controller software written for some system in a 
tank to work the same on a similar system in a - let's say - 
Volkswagen, where a lot of physics parameter are different, would you? 
Would you then blame the software engineer who wrote the initial 
tank-software when your Volkswagen crashes because the software behaves 
like it is controlling a tank?

> Which is to say, complex systems can have complex failure modes,

Right.

> and the fact that some programming languages will catch simple
> errors isn't going to help at all with the complex ones.

NAK. One thing is for sure: The ability to get rid of all the small, 
stupid, simple errors - and even those have very bad consequences a lot 
of times - helps to keep concentrated on avoiding the complex ones.


Vinzent.

-- 
Dope will get you through times of no money better that money will get
you through times of no dope.
                -- Gilbert Shelton

Re: status of PL/I as a viable language

[Bobby D. Bryant]

On Thu, 20 Feb 2003 13:27:43 -0600, John R. Strohm wrote:

> This is from memory, twelve years ago.
> 
> Operation Desert Storm, near the end of the party, when Saddam Hussein
> was lobbing Scuds and the U.S. was going crazy trying to find all of his
> Scud launchers.  Incoming Scud detected, Patriot failed to engage,
> missile hit, destroying (as I recall) a warehouse tent or a barracks
> tent, killing some twenty troops.  Investigation showed that a timer had
> overflowed.  The Patriot system designers assumed that the system would
> never be operated for more than a few hours at a time, and the timer
> couldn't overflow in that time.  This particular one had been up for
> several days.

I thought I remembered that the Patriot *did* intercept the Scud, and
knocked it out of the sky but didn't destroy the warhead.  Then the
warhead fell at a bad-luck spot, killing people who wouldn't have died if
it hadn't been intercepted at all.

(By a strange coincidence, my memory of the matter is also 12 years old!)

-- 
Bobby Bryant
Austin, Texas

Re: status of PL/I as a viable language

[Larry Kilgallen]

In article <1045772065.590669@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:

> Which is to say, complex systems can have complex failure modes,
> and the fact that some programming languages will catch simple
> errors isn't going to help at all with the complex ones.

The average denizen of comp.lang.ada does not claim that compiler
capabilities will solve all problems.  Some of us claim they _help_
with complex problems by freeing the humans from obsessing over
simple bugs, allowing more time for consideration of complex issues.

Re: status of PL/I as a viable language

[Peter Flass]

"John R. Strohm" wrote:
> 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.  

I would submit that this should be done by hardware, not software (i.e.
location 0, assuming null is 0) should be fetch-protected from
everywhere but a few O/S routines.  Anything else is a colossal waste of
computing resources.

Re: status of PL/I as a viable language

[Peter Flass]

Hyman Rosen wrote:
>  [Patriot missle failure]
> > It was an overflowed counter
> 

This rings a bell with me, too.

> Assuming that this is even true, would it have been better
> if the Patriot battery threw an exception? The (first?)
> Ariane 5 incident was pretty much the same, and that was in Ada.

What do you want to do, reboot the missle with the Scud on the way? 
This is a case of "assume makes an ASS out of yoU and ME".

Re: status of PL/I as a viable language

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1045769690.126389@master.nyc.kbcfp.com...
> John R. Strohm wrote:
> > So what's your point?
>
> My point is that the attitude I often sense on this newsgroup
> is that using Ada will give you perfect code. (Not in so many
> words, mind you, but definitely in attitude.)
>

Well I can't help you with your senses ;) but I do not sense that attitude
in the majority of the posters for CLA.  Perhaps you are confusing it with
the "Let the compiler detect those simple program errors so you can
concentrate on the complex errors" altitude.  Naturally this leads to the
feeling (or sense) that Ada helps build more reliable programs.

-CRM

Re: status of PL/I as a viable language

[Larry Kilgallen]

In article <3E554AF4.C8F0EF2E@yahoo.com>, Peter Flass <peter_flass@yahoo.com> writes:
> "John R. Strohm" wrote:
>> 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.  
> 
> I would submit that this should be done by hardware, not software (i.e.
> location 0, assuming null is 0) should be fetch-protected from

Typically it is, and an exception will be thrown.

Coding standards to test first typically include the notion that
some reasonable action should be taken in lieu of the fetch.

> everywhere but a few O/S routines.  Anything else is a colossal waste of
> computing resources.

Once you are handling exceptions, performance is not very important,
since exceptions are, by definition, not supposed to be the normal
course of events.

Re: status of PL/I as a viable language

[John R. Strohm]

"Peter Flass" <peter_flass@yahoo.com> wrote in message
news:3E554AF4.C8F0EF2E@yahoo.com...
> "John R. Strohm" wrote:
> > 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.
>
> I would submit that this should be done by hardware, not software (i.e.
> location 0, assuming null is 0) should be fetch-protected from
> everywhere but a few O/S routines.  Anything else is a colossal waste of
> computing resources.

On just about every machine I've ever dealt with, dereferencing a null
pointer throws a hardware trap.  Dereferencing a null pointer is ALWAYS an
error.  It may be a case of "This pointer should NEVER be null" or it may be
a case of "OK, there is no existing entry for this object, so we have to
create a new one".

Catching a hardware trap and recovering from it is almost always MUCH more
expensive than checking a pointer for null.  It gets seriously ugly if you
are trying to control the granularity of the trap catching code, so you know
that an exception handled here could only be a pointer fault.

Re: status of PL/I as a viable language

[Anders Wirzenius]

"Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message news:3E550205.1010702@cox.net...
> 
> 
> Richard Riehle wrote:
...
> > such as the F-22.   The fact that developers can find a way to screw it
> > up does not detract from the value of the language.   If they can make
> > a mess using a language with the rigorous controls built into Ada,
> > imagine the magnitude of the mess they could make with, say, C++.
> > And, no, PL/I would not help with a system this large and complex.
> > 
> > Richard Riehle
> > 
> Richard,
> 
> You're right in that good (really good) programmers can produce 
> successful code not matter what tools (languages) they have to tolerate 
> while poor programmers (or at least poorly trained) will screw it up no 
> matter how good or bulletproof the language.  Your ATC example 
> undoubtedly proves the point.
> 
> Regards,
> 
>    -- Don.

The masters are masters and the poor are poor.  
The majority of the programmers are just mediocre human beings like me (and you).
The interesting question could be:
What are the tools that helps us to do a good job?

Anders

Re: status of PL/I as a viable language

[Ondřej Tučný]

> And the people who used the Patriot battery for too long (again, assuming
> this incident is true) caused the failure, not the software.
>
> Which is to say, complex systems can have complex failure modes,
> and the fact that some programming languages will catch simple
> errors isn't going to help at all with the complex ones.

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.

So there is a class of complex failures that are caused by simple errors, 
and
so these complex failures can be eliminated by eliminating (detecting & 
handling)
simple errors.

-- 
Ond�ej Tu�n�

Re: status of PL/I as a viable language

[Jean-Pierre Rosen]

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


"John R. Strohm" <strohm@airmail.net> a �crit dans le message de news: > This is from memory, twelve years ago.
>
> Operation Desert Storm, near the end of the party, when Saddam Hussein was
> lobbing Scuds and the U.S. was going crazy trying to find all of his Scud
> launchers.  Incoming Scud detected, Patriot failed to engage, missile hit,
> destroying (as I recall) a warehouse tent or a barracks tent, killing some
> twenty troops.  Investigation showed that a timer had overflowed.  The
> Patriot system designers assumed that the system would never be operated for
> more than a few hours at a time, and the timer couldn't overflow in that
> time.  This particular one had been up for several days.
>
My memory is slightly different.
I think the problem was that time was represented as a floating point value, not fixed point.
As a consequence, the absolute error increased as time went by, leading to more and more
imprecise trajectory computations. The engineers were aware of the problem, and hence required
a daily reboot of the system, but of course it was a bit hard to understand for a military on-the-field...

The main error (IMHO) was to represent time as a floating point, I always argue it must always be
represented as a fixed point. It is possible even if your language does not provide predefined fixed points,
it's just more work.

Now, it can be argued that this error would have been less likely in Ada, since Ada provides fixed point types,
and the programmers would have been less tempted of using floats.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: status of PL/I as a viable language

[Dmitry A. Kazakov]

On Thu, 20 Feb 2003 14:34:50 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>John R. Strohm wrote:
>> So what's your point?
>
>My point is that the attitude I often sense on this newsgroup
>is that using Ada will give you perfect code. (Not in so many
>words, mind you, but definitely in attitude.)

Should it mean that an unability to create a perfect code (a thing I
never saw) in one language excuses any design fault of another?

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: status of PL/I as a viable language

[Peter Flass]

"John R. Strohm" wrote:
> 
> "Peter Flass" <peter_flass@yahoo.com> wrote in message
> news:3E554AF4.C8F0EF2E@yahoo.com...
> > "John R. Strohm" wrote:
> > > 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.
> >
> > I would submit that this should be done by hardware, not software (i.e.
> > location 0, assuming null is 0) should be fetch-protected from
> > everywhere but a few O/S routines.  Anything else is a colossal waste of
> > computing resources.
> 
> On just about every machine I've ever dealt with, dereferencing a null
> pointer throws a hardware trap.  Dereferencing a null pointer is ALWAYS an
> error.  It may be a case of "This pointer should NEVER be null" or it may be
> a case of "OK, there is no existing entry for this object, so we have to
> create a new one".

Well, not "always", remember some O/S code has to access virtual address
0, but almost always.

> 
> Catching a hardware trap and recovering from it is almost always MUCH more
> expensive than checking a pointer for null.  It gets seriously ugly if you
> are trying to control the granularity of the trap catching code, so you know
> that an exception handled here could only be a pointer fault.

Right, except that dreferencing a null pointer is an *error*, and should
not occur in normal code.  Better to let the hardware trap it for the 1
in 10**6 times it may occur than execute a lot of useless checking every
time you run the program.  Just so someone checks.  As for granularity,
I'm reading this on comp.lang.pl1 and not comp.lang.ada.  PL/I provides
the tools to handle this, as long as the programmer puts a litt;e
thought into the design.

Re: status of PL/I as a viable language

[Hyman Rosen]

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.

Re: status of PL/I as a viable language

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Should it mean that an unability to create a perfect code (a thing I
> never saw) in one language excuses any design fault of another?

Nope. I'm just objecting to "If it broke, and it's C++, it's the
language's fault. If it broke, and it's Ada, it's the programmer's
fault."

Re: status of PL/I as a viable language

[Vinzent Hoefler]

Hyman Rosen wrote:

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

Or just overwrite some more important data so that the device still 
seems to work but gives wrong results.

> whereas detecting the error will just blow the program away.

Or the other way around. Depends.

The only solution would be an error free program and even that cannot 
protect you from malfunctioning hardware. Better to catch the exception 
and turn on the backup system then.


Vinzent.

-- 
"Water?  Never touch the stuff!  Fish fuck in it."
                -- W. C. Fields

Re: status of PL/I as a viable language

[Preben Randhol]

Hyman Rosen wrote:
> 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

So your point is that it is better to use C/C++ which doesn't have these
test in the first place? How come there are so many security holes in
software then?

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Preben Randhol]

Hyman Rosen wrote:
> Nope. I'm just objecting to "If it broke, and it's C++, it's the
> language's fault. If it broke, and it's Ada, it's the programmer's
> fault."

No, error are always the programmers fault. However some languages like
Ada makes it much harder to make common simple mistakes (not logical
mistakes mind you) than other languages whoes design more or less
encourage these mistakes. This leaves the programmer more time to work
on reviewing the code to find the complex mistakes. One of the nice
things with Ada is that you hardly need to use a debugger on smaller
projects (on big projects I don't know as I don't have experience with
this). But for C/C++ you sure have to use a debugger at some stage even
in small projects. Looking for the needle in the haystack takes a long
time compared to having the compiler tell you both the location of the
haystack and where the needle is/was last seen.

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Preben Randhol]

Dennis Lee Bieber wrote:
>         I seem to recall reading that the Patriot timer was a problem in M$ 
> Windows itself... a 49day uptime for W95 or something?

Patriots run on Windows? Mamma mia *tremble*

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Hyman Rosen]

Preben Randhol wrote:
> So your point is that it is better to use C/C++ which doesn't have these
> test in the first place?

Oh no, not at all. It's much better for the checks to be there.
But you have to be aware of their limitations, and know when
you want to disable them.

> How come there are so many security holes in software then?

My point was that checks should be disabled when it is
important for programs to continue operation. Security
situations are just the opposite. In that case, you want
to abort at any sign of error, perhaps even with timeouts
to kill things which run too long, because any such issue
can be a sign of attack.

Re: status of PL/I as a viable language

[Preben Randhol]

Hyman Rosen wrote:
> 
> My point was that checks should be disabled when it is
> important for programs to continue operation. Security
> situations are just the opposite. In that case, you want
> to abort at any sign of error, perhaps even with timeouts
> to kill things which run too long, because any such issue
> can be a sign of attack.

Yes, but in the case you want to have a program running continously it
won't help if there are errors in the program which makes the program
behave in strange ways. Say a nuclear powerplant. You don't want an
untreated integer overflow to cause the rods to be pulled up causing a new
nuclear meltdown. You want that the program to catch this error and
go into a backup/safe-mode program IMHO.

In my simple program I have an outer exception handling. If an exception
is caught here the program will try to save the data in an EMERGENCY
file before it quits. It will also give the user a notice of the error
of course. When the program starts it always checks if there is an
EMERGENCY file which if it exists will be loaded and the user will be told
that the data is restored and ought to be checked. This works.

Another example, when I'm running my experiments (chemistry) in the lab,
I'm logging the data from an electrode onto a computer. The logging
software worked fine except that I sometimes found that the log had
stopped at some random place in the experiment. These experiments can
be 10 or more hours and I'm not there during this time. After some checking
I found out that what made the program crash was that the some strange
feed came from the logger causing the logging program to crash. I
changed the program so that in case it got this feed it should simply
write -1000 (as this is not a value I would get from my electrode and
thus I can remove it later from the log) and then I got the program to
continue. I can see in my logs that in some experiments I get this
strange error, but after 3 years I still have no idea what causes it,
and it is not important as it doesn't influence my experiment now that
the logging is working.  Note this was not written in Ada, but
some language of the logger.  So my point is that I don't think that one
are more safe turning off all checks in the distributed code. You newer
know the side-effects that this will have. It is better to make an
outer safty net which can catch the any error and deal with it and
notify the user.

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Preben Randhol]

Preben Randhol wrote:
> feed came from the logger causing the logging program to crash. I
> changed the program so that in case it got this feed it should simply
> write -1000 (as this is not a value I would get from my electrode and
> thus I can remove it later from the log) and then I got the program to
> continue. I can see in my logs that in some experiments I get this

By continue I mean that I got it to continue from the right point in the
stream. If the program would be able to cope with the erranous feed and
write this to the log it would have continued in the wrong place and
written gibberish for the rest of the log and this would have been
useless.

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Larry Kilgallen]

In article <1045845919.135559@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Preben Randhol wrote:
>> So your point is that it is better to use C/C++ which doesn't have these
>> test in the first place?
> 
> Oh no, not at all. It's much better for the checks to be there.
> But you have to be aware of their limitations, and know when
> you want to disable them.
> 
>> How come there are so many security holes in software then?
> 
> My point was that checks should be disabled when it is
> important for programs to continue operation.

For the Patriot case, I think "continue operations" is the wrong
action in the presence of an error, since the whole system deploys
explosives "somewhere".

Re: status of PL/I as a viable language

[Hyman Rosen]

Preben Randhol wrote:
> You don't want an untreated integer overflow to cause
 > the rods to be pulled up causing a new nuclear meltdown.
 > You want that the program to catch this error and go
 > into a backup/safe-mode program IMHO.

The problem is that we're talking about unanticipated
situations, so fallback handling is always going to be
iffy. The fallback handling for the Ariane 5 made it
blow up, after all.

I'm saying that things like buffer overruns and bad
memory accesses and to some extent arithmetic overflow
can be limited problems - some bit of memory on the
stack might get clobbered, but then goes away when the
subroutine returns, for example. This means that even
though the program has acted erroneously in programming
language terms, it is still working properly from an
outside point of view - the toaster is still heating
the bread.

On the other hand, noticing the error will almost
certainly abort the operation, and since we're talking
about unanticipated errors, things may just come to a
halt. Whether this is desirable depends on the application.

Re: status of PL/I as a viable language

[Preben Randhol]

Hyman Rosen wrote:
> Preben Randhol wrote:
>> You don't want an untreated integer overflow to cause
> > the rods to be pulled up causing a new nuclear meltdown.
> > You want that the program to catch this error and go
> > into a backup/safe-mode program IMHO.
> 
> The problem is that we're talking about unanticipated
> situations, so fallback handling is always going to be
> iffy. The fallback handling for the Ariane 5 made it
> blow up, after all.

Which was the correct thing to do! You don't want the rocket to
accelerate down and hit your head do you?

> I'm saying that things like buffer overruns and bad
> memory accesses and to some extent arithmetic overflow
> can be limited problems - some bit of memory on the
> stack might get clobbered, but then goes away when the
> subroutine returns, for example. This means that even
> though the program has acted erroneously in programming
> language terms, it is still working properly from an
> outside point of view - the toaster is still heating
> the bread.

Heating it until it starts to burn? I guess one see buffer overruns as a
limited problem to the computer that was broken into? Well it happened
at the university here and 25000 had to change passwords in some hours.

> On the other hand, noticing the error will almost
> certainly abort the operation, and since we're talking
> about unanticipated errors, things may just come to a
> halt. Whether this is desirable depends on the application.

Well that's why you have: "anticipated the unexpected!"

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Preben Randhol]

Preben Randhol wrote:
> 
> Well that's why you have: "anticipated the unexpected!"
                             anticipate the unexpected!

those pesky tyops. :-(
-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Vinzent Hoefler]

Hyman Rosen wrote:

> The problem is that we're talking about unanticipated
> situations, so fallback handling is always going to be
> iffy. The fallback handling for the Ariane 5 made it
> blow up, after all.

Mmh. Yes. As I said, the code in question was not wrong, it was just 
used in the wrong system.

Would it have happened on Ariane 4, the fallback would have been the 
perfectly right decision.

> I'm saying that things like buffer overruns and bad
> memory accesses and to some extent arithmetic overflow
> can be limited problems

*can be*, yes. My experience says, most of the times they are not worse 
or better than any other kind of error.

Real life example:

The calculation for a list of machine parameters caused on overflow. It 
went through undetected and everything was fine just until the last set 
of parameter should have been activated. That did not happen, because 
it was not accessed anymore, it was out of the defined bounds. In the 
end this rendered the whole process useless. Catching the error 
beforehand would have caused the same uselessness just in another 
(time- and moneysaving) degree. The chance of detecting and fixing it 
earlier also would have been higher.

I guess, we can both bring one example after the other, where on 
approach is better than the other.
In the end, we both probably agree, such errors should not happen at 
all.

> On the other hand, noticing the error will almost
> certainly abort  the operation, and since we're talking
> about unanticipated errors, things may just come to a
> halt.

Or the big fat global exception handler just initiates a complete reboot 
or tries to get the thing into a safe state.

Whatever you may do, it *can* under some circumstances be the wrong 
decision.

> Whether this is desirable depends on the application.

Yes. And IMO one of the main problem of deciding what might be better 
is: You never know until it actually happens.

So I think, trying to minimize the number of possible errors is a good 
start.


Vinzent.

-- 
Nuke the gay, unborn, baby whales for Jesus.

Re: status of PL/I as a viable language

[John R. Strohm]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
news:ZCj5a.24$m%2.4@read3.inet.fi...
>
> "Donald L. Dobbs" <donaldldobbs@cox.net> wrote in message
news:3E550205.1010702@cox.net...
> >
> >
> > Richard Riehle wrote:
> ...
> > > such as the F-22.   The fact that developers can find a way to screw
it
> > > up does not detract from the value of the language.   If they can make
> > > a mess using a language with the rigorous controls built into Ada,
> > > imagine the magnitude of the mess they could make with, say, C++.
> > > And, no, PL/I would not help with a system this large and complex.
> > >
> > > Richard Riehle
> > >
> > Richard,
> >
> > You're right in that good (really good) programmers can produce
> > successful code not matter what tools (languages) they have to tolerate
> > while poor programmers (or at least poorly trained) will screw it up no
> > matter how good or bulletproof the language.  Your ATC example
> > undoubtedly proves the point.
> >
> > Regards,
> >
> >    -- Don.
>
> The masters are masters and the poor are poor.
> The majority of the programmers are just mediocre human beings like me
(and you).
> The interesting question could be:
> What are the tools that helps us to do a good job?

Some years ago, in a discussion with a coworker, I opined that there were
three levels of programmer: novice (or apprentice), journeyman, master.  He
added a fourth: wizard.

The REAL interesting question is: what are the appropriate tools that help
each level to do a "good" job?

The related question is: to what extent can the tools of e.g. a wizard be
made SAFELY available to a novice?

The overriding question is: how do we structure our projects and our project
teams and our toolsets to allow each level of programmer to achieve maximum
productivity?

That last question, incidentally, reflects back on the Joel Aron/Harlan
Mills "Chief Programmer Team" concept.  It is well-known in computing that
there may be as much as two orders of magnitude difference between
programmers.  It is utter idiocy to expect a low-end programmer to perform
at the level of a Chief Programmer, and it is even more idiotic to restrain
a Chief Programmer so he is only allowed to perform at the level of a
low-end coder.

Re: status of PL/I as a viable language

[John R. Strohm]

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

Re: status of PL/I as a viable language

[Hyman Rosen]

Preben Randhol wrote:
> Which was the correct thing to do!

I believe that if the error had gone undetected instead
of handled, the rocket would have flown properly.

> Heating it until it starts to burn?

With toasters, that's actually a fine mode of operation.
You begin to smell the toast overheating, and you go and
manually release it. A little scraping if necessary, and
then you munch away.

> I guess one see buffer overruns as a limited problem to
 > the computer that was broken into?

I've already said that things like this are situational.
If you're worried about security then you have to deal
with these kinds of problems differently and then the
most stringent runtime checks are appropriate because
you would rather abort than be compromised. But no one
is sending deliberately malformed strings to a toaster
or a rocket.

Re: status of PL/I as a viable language

[John R. Strohm]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:f2rb5v8020kkvq6tsf0uqg91pfbk9errs7@4ax.com...
> On Thu, 20 Feb 2003 14:34:50 -0500, Hyman Rosen <hyrosen@mail.com>
> wrote:
>
> >John R. Strohm wrote:
> >> So what's your point?
> >
> >My point is that the attitude I often sense on this newsgroup
> >is that using Ada will give you perfect code. (Not in so many
> >words, mind you, but definitely in attitude.)
>
> Should it mean that an unability to create a perfect code (a thing I
> never saw) in one language excuses any design fault of another?

Actually, it IS possible to create perfect code.  See:
http://www.cs.utexas.edu/users/boyer/ftp/ics-reports/cmp34.pdf

Re: status of PL/I as a viable language

[Vinzent Hoefler]

Hyman Rosen wrote:

> Preben Randhol wrote:

[Ariane 5]
> I believe that if the error had gone undetected instead
> of handled, the rocket would have flown properly.

No. I am not sure about that. Maybe...

>> Heating it until it starts to burn?
> 
> With toasters, that's actually a fine mode of operation.

Are you serious?

> You begin to smell the toast overheating, and you go and
> manually release it. A little scraping if necessary, and
> then you munch away.

Or standing with a fire extinguisher in the completely burned down 
kitchen.

> I've already said that things like this are situational.

ACK. But even on one single system you cannot say if a better approach 
would be ignoring or eventually handling the error.

> But no one is sending deliberately malformed strings to a toaster
> or a rocket.

For the rocket : Malfunctioning sensor hardware might act like one.
For the toaster: Not yet.


Vinzent.

-- 
Q:  How many right-to-lifers does it take to change a light bulb?
A:  Two.  One to screw it in and one to say that light started when the
    screwing began.

Re: status of PL/I as a viable language

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1045839419.823502@master.nyc.kbcfp.com>...
> Dmitry A. Kazakov wrote:
> > Should it mean that an unability to create a perfect code (a thing I
> > never saw) in one language excuses any design fault of another?
> 
> Nope. I'm just objecting to "If it broke, and it's C++, it's the
> language's fault. If it broke, and it's Ada, it's the programmer's
> fault."

No, no, no!  If it broke, and it's C++, it's the language's fault AND
the programmer's fault.  If it broke and it's Ada, it's management's
fault.  ;-)

Hmmm, add management in the C++ case too...

Re: status of PL/I as a viable language

[Hyman Rosen]

John R. Strohm wrote:
> Actually, it IS possible to create perfect code.  See:
> http://www.cs.utexas.edu/users/boyer/ftp/ics-reports/cmp34.pdf

It took them almost two years to write a simple little
limited regular expression matcher.

Re: status of PL/I as a viable language

[Hyman Rosen]

Vinzent Hoefler wrote:
> ACK. But even on one single system you cannot say if a better approach 
> would be ignoring or eventually handling the error.

Pretty much by definition, no one expects these kinds
of errors, since they represent errors in the logic of
the code; you would just fix the logic, not add error
handlers.

So the only thing you might have is some outer catch-all
handler which when invoked knows only that a disaster
has happened. So what do you do? Assume a bounded software
error and reboot, hoping the problem will go away? Assume
hardware failure, and go to your backups? Shut down?

Maybe it's just that someone miscounted the number of
letters in 'September' and has managed to overrun an
array by one character, and if you left it alone, the
program would keep going just fine.

There's no one right answer, but I'm firmly convinced
that ignoring errors is in the set of reasonable actions.

Re: status of PL/I as a viable language

[Shmuel (Seymour J.) Metz]

In <1045763933.848350@master.nyc.kbcfp.com>, on 02/20/2003
   at 12:58 PM, Hyman Rosen <hyrosen@mail.com> said:

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

True. But a huge proportion of the exploits in Internet software rely
on buffer underruns, which wouldn't exist in a language like Ada that
has an equivalent to SUBSCRIPTRANGE. And, yes, the checking can be
turned off in Ada, but I would hope that such an abomination would
never get through code review.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Re: status of PL/I as a viable language

[Richard Riehle]

Hyman Rosen wrote:

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

HmmmMMMmmmmm.  Sounds as if you just invented SPARK.

Richard Riehle

Re: status of PL/I as a viable language

[Shmuel (Seymour J.) Metz]

In
<819A9E0CA1094B88.6E582670555DCA33.F06C4B2BCD076570@lp.airnews.net>,
on 02/20/2003
   at 05:30 PM, "John R. Strohm" <strohm@airmail.net> said:

>On just about every machine I've ever dealt with, dereferencing a
>null pointer throws a hardware trap. 

If the compiler takes the easy route and represents a null pointer as
0, there won't be a hardware trap on, e.g., a system running MVS[1] or
VM[2].

>Catching a hardware trap and recovering from it is almost always
>MUCH more expensive than checking a pointer for null. 

Why do you care? Explicitly testing is always much more expensive when
the pointer is valid, which is much more common, so in aggregate it is
more expensive than using an invalid address for null and letting the
hardware catch it. Your argument only holds water if the path for
handling an exception is itself time critical.

[1] Of any vintage from OS/VS2 R2 through z/OS.

[2] Of any vintage from VMF/370 through z/VM.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Re: status of PL/I as a viable language

[Frank J. Lhota]

> It took them almost two years to write a simple little
> limited regular expression matcher.

When it comes to software (or hardware, or buildings, or novels, or just
about everything), customers want three things: they want it fast, they want
it cheap, and they want it good. Generally, you can provide them with any
combination of two of these three things. AFAIK, this is an example of
someone producing software that is cheap and extremely good, and the expense
of not being very fast.

Re: status of PL/I as a viable language

[Shmuel (Seymour J.) Metz]

In <3E56203D.BD1F694@yahoo.com>, on 02/21/2003
   at 01:46 PM, Peter Flass <peter_flass@yahoo.com> said:

>Well, not "always", remember some O/S code has to access virtual
>address 0, but almost always.

That depends very much on the architecture. It's certainly true on the
more common systems.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Re: status of PL/I as a viable language

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1045856952.418085@master.nyc.kbcfp.com...
> John R. Strohm wrote:
> > Actually, it IS possible to create perfect code.  See:
> > http://www.cs.utexas.edu/users/boyer/ftp/ics-reports/cmp34.pdf
>
> It took them almost two years to write a simple little
> limited regular expression matcher.

And that "simple little limited regular expression matcher" passed the
formal customer acceptance test on the first try, with no deviations or
waivers or anything.  They never saw the acceptance test suite until the
formal test, in front of the customer.  The acceptance test was developed by
a different company, in California.

That was the FIRST time *ANY* computer program had EVER done that, in all
the history of the U.S. Department of Defense.

The critical part of the project was the verification.  They KNEW that the
code was correct, because they'd proven it, with mathematical rigor, subject
to the one assumed lemma about the ordering of certain characters in the
ASCII character code.

Re: status of PL/I as a viable language

[Randy Brukardt]

Bobby D. Bryant wrote in message ...
>On Thu, 20 Feb 2003 13:27:43 -0600, John R. Strohm wrote:
>
>> This is from memory, twelve years ago.
>>
>> Operation Desert Storm, near the end of the party, when Saddam
Hussein
>> was lobbing Scuds and the U.S. was going crazy trying to find all of
his
>> Scud launchers.  Incoming Scud detected, Patriot failed to engage,
>> missile hit, destroying (as I recall) a warehouse tent or a barracks
>> tent, killing some twenty troops.  Investigation showed that a timer
had
>> overflowed.  The Patriot system designers assumed that the system
would
>> never be operated for more than a few hours at a time, and the timer
>> couldn't overflow in that time.  This particular one had been up for
>> several days.
>
>I thought I remembered that the Patriot *did* intercept the Scud, and
>knocked it out of the sky but didn't destroy the warhead.  Then the
>warhead fell at a bad-luck spot, killing people who wouldn't have died
if
>it hadn't been intercepted at all.
>
>(By a strange coincidence, my memory of the matter is also 12 years
old!)


I very recently saw a History Channel documentary where they described
the incident pretty much as John described it. As I recall, they said
that the Patriot missed the Scud entirely because of the error.

I do recall some cases in Israel like you describe, not the barracks
one.

               Randy.

Re: status of PL/I as a viable language

[Vinzent Hoefler]

Hyman Rosen wrote:

> Vinzent Hoefler wrote:
>> ACK. But even on one single system you cannot say if a better
>> approach would be ignoring or eventually handling the error.
> 
> Pretty much by definition, no one expects these kinds
> of errors,

Well, I always expect errors. ;)

> since they represent errors in the logic of
> the code; you would just fix the logic, not add error
> handlers.

ACK. But to do that you should first know there is an error.

> So the only thing you might have is some outer catch-all
> handler which when invoked knows only that a disaster
> has happened. So what do you do? Assume a bounded software
> error and reboot, hoping the problem will go away? Assume
> hardware failure, and go to your backups? Shut down?

Such a "global failure" action highly depends on the system you are 
controlling. In the case of a nuclear plant a clean shutdown is 
probably the safest you can do, on a mobile phone simply restarting it 
could be a more appropiate decision.

I think a significant part of the embedded systems out there currently 
use the approach to restart the system by using some watchdog timers or 
catch-all handlers and they just run fine with that.

Needless to say, that such a decision might be the wrong one for the one 
particular "unthinkable" error.

> Maybe it's just that someone miscounted the number of
> letters in 'September' and has managed to overrun an
> array by one character, and if you left it alone, the
> program would keep going just fine.

Maybe it overwrote some other parameter and now will do weird and 
possibly dangerous things. As I said, you never know until it actually 
happens.

> There's no one right answer, but I'm firmly convinced
> that ignoring errors is in the set of reasonable actions.

Sometimes, yes. At least in Ada you always have the option to turn off 
all the checks if you really want to do so.

But I think, as soon as such error is detected it should be fixed.

So IMO it should be a strong requirement to either avoid the error 
completely by doing it correct the first time or detect such error at 
runtime in whatever system we are talking about. So, even in the case 
of letting the program go on after detecting such a violation, at least 
having a chance to log it and try to recover the system without a 
"real" dedicated error handler then *could* be fine.

BTW, especially in the case of buffer overruns the system will crash 
anyway most of the times, because of a corrupted stack. Detecting the 
error before it screws everything up just makes the crash look more 
clean. ;)


Vinzent.

-- 
"I own my own body, but I share"

Re: status of PL/I as a viable language

[John R. Strohm]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:T1w5a.53$8f7.22@nwrdny02.gnilink.net...
> > It took them almost two years to write a simple little
> > limited regular expression matcher.
>
> When it comes to software (or hardware, or buildings, or novels, or just
> about everything), customers want three things: they want it fast, they
want
> it cheap, and they want it good. Generally, you can provide them with any
> combination of two of these three things. AFAIK, this is an example of
> someone producing software that is cheap and extremely good, and the
expense
> of not being very fast.

It wasn't cheap.

It wasn't extremely good; it was PERFECT.  It did PRECISELY what it was
designed to do.  It did PRECISELY what the customer WANTED it to do.  And it
didn't just CLAIM to do that, and CLAIM to have no lurking faults; it was
rigorously KNOWN to have no lurking faults.

This was part of a long project aimed at developing verification technology
to the point that it would be possible to build perfect software.  One can
easily envision domains where exhaustive testing is just not possible, where
it is necessary to KNOW by other techniques that the software is absolutely,
positively, correct.  In those domains, "debugging" until it LOOKS like it
works just isn't good enough.

Re: status of PL/I as a viable language

[Richard Riehle]

Hyman Rosen wrote:

> Dmitry A. Kazakov wrote:
> > Should it mean that an unability to create a perfect code (a thing I
> > never saw) in one language excuses any design fault of another?
>
> Nope. I'm just objecting to "If it broke, and it's C++, it's the
> language's fault. If it broke, and it's Ada, it's the programmer's
> fault."

Good point.   We need to understand that there are limits to what
can be accomplished by depending only on our tools.   Ada has
a lot to recommend it for high-integrity software.   Other languages
have a lot to recommend them.  This started as a PL/I thread, and
I have learned, more recently, of improvements in PL/I since I
last used it.   Even so, PL/I, for all its improvements, requires
skilled programmers.  Ada requires skilled programmers.  C++
requires skilled programmers.

My personal preference, based on my experience and current
knowledge of competing languages continues to be Ada, for
the kind of software (such as F-22) we have been discussing.
However, I realize that a highly skilled C++ programmer, one
who understands the built-in pitfalls of the language, and one
who understands how to use smart-pointers, smart arrays, and
lots of other useful C++ classes, can create reliable software.
The same is  probably true of a PL/I programmer, but I am not
aware of PL/I being used for many safety-critical applications.
Someone can help me on that, I suppose.

The key to successful safety-critical software remains, good
engineering.   Most programmers have no engineering education,
and all too often, they have insufficient mathematics.   On systems
such as the F-22, it is critical that the developers are engineering
aware, and that they have strong mathematics.

Yesterday, I particiapted in a discussion of requirements specifications
where some of the participants thought it was enough to simply specify
the mathematics needed for the application.   The mathematics happened
to involve relatively simple calculus.   The eventual design of the
algorithm was expected to be the job of the programmer.  Of course,
there would checking, inspection, and testing at some stage, but my
point was that the algorithm should be specified in more detail and
not left to the programmer.

As long as we ignore the importance of engineering when developing
safety-critical software, we are going to continue to make a mess of it,
and no programming language will save us.

Ada is like using a torque wrench.  C++ is like using any convenient
long-handled wrench.   If the mechanic is careful and has a lot of
experience, using that long-handled wrench, it will work just fine.  In
most cases, though, we might find the toque wrench a little more
reliable.   However, if we have no clue about the appropriate level
of torque, cannot before-hand do the required computations, and
have no idea what torque is, we are going to twist off the head of
the bolt just as easily as the guy with the simple long-handled wrench.

Richard Riehle

Re: Donald's F-22 Question

[Richard Riehle]

Returning to Donald's original question, repeated at the end of this message.

I have been interested in the thread that started this.   Lots of good
comments have been posted.  No one has directly address Donald's
question vis a vis the F-22.

The F-22 software is clearly a problem.   There are probably programmers
out there who read these forums and have direct involvment with
this project.   It would be interesting to hear from one or more of
them.

Richard Riehle


======================================================

> "Donald L. Dobbs" wrote:
>
> > Not to belabor a point, but one of the lead stories today on the
> > Aviation Week web site www.aviationnow.com describes how the F-22
> > program is now some $800 million overrun because of delays caused by
> > unreliable software.  They can get it to run for about 8 hrs in the lab
> > before it crashes, but in the actual test flights it fails within 3.5
> > hours forcing the pilot to reboot the system while in mid-flight.  If
> > they are using Ada as you contend, then this is a terrible indictment
> > and confirms what I had heard earlier about the language's shortcomings.

Re: status of PL/I as a viable language

[Randy Brukardt]

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


Usually it is better to make the checks and prevent the "wrong answer".
This is, after all, the cause of some many of the security holes on the
Internet.

The web server for AdaIC is written in Ada. I've left all of the
checking on, and provide a global exception handler for each worker
thread. Thus, the worst that can happen for a mistaken check is the
currently processed operation to be abandoned (the server sends an
internal error response to the client). That prevents all sort of
security holes from buffer overflows and the like.

It of course does not prevent all errors, but it allowed me to focus on
blocking the common security problems that are algorithmic in nature,
like traversal errors.

Although the code has had a variety of buffer overflow and other bugs
cause individual operations to fail, the server has continued to run and
process other operations correctly for the entire 18 months. (And, all
failures have been logged so that the cause can be tracked down easily).
This has allowed the focus to be on the web site's contents, not on
keeping the server running.

There probably are cases where it is better to run with checks off. (We
always did that with Janus/Ada for MS-DOS, just to keep the compiler
size managable. That's not an issue on Windows.) But I would generally
prefer to err on the side of leaving checks on unless it is necessary to
do otherwise.

               Randy.

Re: status of PL/I as a viable language

[Randy Brukardt]

Hyman Rosen wrote:
> But no one is sending deliberately malformed strings to a toaster
> or a rocket.


Yet. You can bet if there is a way to do it, it will happen. Security is
something you do all the time, on every program, because anything can be
the vector of an attack. "It's only Notepad" or "It's only a toaster"
doesn't cut it.

        Randy.

Re: status of PL/I as a viable language

[Hyman Rosen]

Randy Brukardt wrote:
> the cause of some many of the security holes

As I keep saying, the security case is one in which
you would rather halt altogether than allow errors
to occur. But not everything warrants that approach.
Some things, like bombs and rockets, should just
keep going, because there's no good alternative.
In that case, detecting the error is probably not
as good as ignoring it.

Re: status of PL/I as a viable language

[Hyman Rosen]

John R. Strohm wrote:
> And that "simple little limited regular expression matcher" passed the
> formal customer acceptance test on the first try, with no deviations or
> waivers or anything.

But it took them *two years* to get it specified,
designed, and built. Maybe it was a polished piece
of perfection, but that's a very long time to build
a message filter.

Re: status of PL/I as a viable language

[Vinzent Hoefler]

Hyman Rosen wrote:

> Some things, like bombs and rockets, should just
> keep going, because there's no good alternative.

Really?

|exception
|  when others =>
|     Self_Destroy;

;-)

> In that case, detecting the error is probably not
> as good as ignoring it.

Well, still better it simply falls down doing nothing more harmful than 
to bury some sheep under it, than to detonate over the wrong (friendly) 
target.


Vinzent.

-- 
"He could be a poster child for retroactive birth control."

Re: status of PL/I as a viable language

[Pointless Harlows]

"John R. Strohm" <strohm@airmail.net> wrote in message
> Actually, it IS possible to create perfect code.

You may recall the perfect IBM mainframe utility routine IEFBR14 ;-)

However, I did hear it said once that even the first version of IEFBR14 had
a fault in that it didnt return a zero return code.
Can anyone actually confirm that?

Re: status of PL/I as a viable language

[Donald L. Dobbs]

Richard Riehle wrote:
> Hyman Rosen wrote:
> 
> 
>>Dmitry A. Kazakov wrote:
>>
>>>Should it mean that an unability to create a perfect code (a thing I
>>>never saw) in one language excuses any design fault of another?
>>
>>Nope. I'm just objecting to "If it broke, and it's C++, it's the
>>language's fault. If it broke, and it's Ada, it's the programmer's
>>fault."
> 
> 
> Good point.   We need to understand that there are limits to what
> can be accomplished by depending only on our tools.   Ada has
> a lot to recommend it for high-integrity software.   Other languages
> have a lot to recommend them.  This started as a PL/I thread, and
> I have learned, more recently, of improvements in PL/I since I
> last used it.   Even so, PL/I, for all its improvements, requires
> skilled programmers.  Ada requires skilled programmers.  C++
> requires skilled programmers.
> 
> My personal preference, based on my experience and current
> knowledge of competing languages continues to be Ada, for
> the kind of software (such as F-22) we have been discussing.
> However, I realize that a highly skilled C++ programmer, one
> who understands the built-in pitfalls of the language, and one
> who understands how to use smart-pointers, smart arrays, and
> lots of other useful C++ classes, can create reliable software.
> The same is  probably true of a PL/I programmer, but I am not
> aware of PL/I being used for many safety-critical applications.
> Someone can help me on that, I suppose.
> 
> The key to successful safety-critical software remains, good
> engineering.   Most programmers have no engineering education,
> and all too often, they have insufficient mathematics.   On systems
> such as the F-22, it is critical that the developers are engineering
> aware, and that they have strong mathematics.
> 
> Yesterday, I particiapted in a discussion of requirements specifications
> where some of the participants thought it was enough to simply specify
> the mathematics needed for the application.   The mathematics happened
> to involve relatively simple calculus.   The eventual design of the
> algorithm was expected to be the job of the programmer.  Of course,
> there would checking, inspection, and testing at some stage, but my
> point was that the algorithm should be specified in more detail and
> not left to the programmer.
> 
> As long as we ignore the importance of engineering when developing
> safety-critical software, we are going to continue to make a mess of it,
> and no programming language will save us.
> 
> Ada is like using a torque wrench.  C++ is like using any convenient
> long-handled wrench.   If the mechanic is careful and has a lot of
> experience, using that long-handled wrench, it will work just fine.  In
> most cases, though, we might find the toque wrench a little more
> reliable.   However, if we have no clue about the appropriate level
> of torque, cannot before-hand do the required computations, and
> have no idea what torque is, we are going to twist off the head of
> the bolt just as easily as the guy with the simple long-handled wrench.
> 
> Richard Riehle
> 

Richard, you have touched on a subject (actually pet peeve of mine for 
many years in this industry) that I will elaborate on, now.

When I first got into the computing business (circa 1962 -- oh my, that 
probably makes me older than David Frank) we had systems analysts and 
programmers.  The latter were actually "coders".  The systems analysts 
were subject matter experts for the application being contemplated.  If 
it was an accounting or payroll package the S.A. was either a CPA or 
someone who had a strong background in accounting/bookkeeping, etc.  If 
it was a guidance program for a missile the S.A. was probably a Ph.D. in 
math or celestial mechanics. The programmer (coder) only had to know his 
Cobol, Fortran, PL/I or assembly language.  He didn't have to know the 
subject matter of the application to any great degree because the S.A. 
wrote an air-tight spec that the coder was to rigorously implement.  His 
was not to reason why.  We developed pretty good software in those days.

Somewhere along the way, it all fell apart when we (as an economy 
measure in smaller shops, I suppose) invented the Programmer-Analyst. 
This, IMHO, is the worst single act that has occurred in this industry 
because we now expect the PA to be both subject matter expect and 
programmer/coder expert at the same time. The trade journals and web 
sites are replete with help wanted ads always demanding an individual 
who is a brain surgeon with ten years of Java, etc.  (I exaggerate the 
point but not by much in many cases.)  I suspect that big aerospace 
projects require so many bodies that there is still some division of 
labor, but in the commercial world this just isn't sufficiently the 
case.  Dual experts are a rare commodity and even when you find them 
they have a self-contained conflict of interest because the quality of 
the Analyst functions will be compromised by the Coder subconscious 
telling himself that the requirement is too hard to implement or should 
be implemented in a different way which diminishes the original 
requirements.

I suspect these opinions will instigate a whole new discussion, which I 
welcome because I think we've all been victim of this phenomenon, 
directly or indirectly.

Re: status of PL/I as a viable language

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1045863617.243086@master.nyc.kbcfp.com...
> John R. Strohm wrote:
> > And that "simple little limited regular expression matcher" passed the
> > formal customer acceptance test on the first try, with no deviations or
> > waivers or anything.
>
> But it took them *two years* to get it specified,
> designed, and built. Maybe it was a polished piece
> of perfection, but that's a very long time to build
> a message filter.

Depends on what kind of defect density you can tolerate, and on whether you
can afford to find the defects in actual operation.

Re: Donald's F-22 Question

[Jerry Petrey]

Richard Riehle wrote:

> Returning to Donald's original question, repeated at the end of this message.
>
> I have been interested in the thread that started this.   Lots of good
> comments have been posted.  No one has directly address Donald's
> question vis a vis the F-22.
>
> The F-22 software is clearly a problem.   There are probably programmers
> out there who read these forums and have direct involvment with
> this project.   It would be interesting to hear from one or more of
> them.
>
> Richard Riehle
>
> ======================================================
>
> > "Donald L. Dobbs" wrote:
> >
> > > Not to belabor a point, but one of the lead stories today on the
> > > Aviation Week web site www.aviationnow.com describes how the F-22
> > > program is now some $800 million overrun because of delays caused by
> > > unreliable software.  They can get it to run for about 8 hrs in the lab
> > > before it crashes, but in the actual test flights it fails within 3.5
> > > hours forcing the pilot to reboot the system while in mid-flight.  If
> > > they are using Ada as you contend, then this is a terrible indictment
> > > and confirms what I had heard earlier about the language's shortcomings.

I worked for Lockheed during part of the F22 development period although not
directly
on the F22 program but on another aircraft system (in Ada also).  The problem is
a common one on large programs - mostly one of management.  Managers assume
all engineers are alike.  There were a few good Ada programmers and a lot of
average
or below average AdaTran and AdaC programmers ("I can write Fortran (or C) in any

language" people).  The overall code that resulted, while Ada, was certainly not
good Ada.
It was a mess to get working and resulted in huge cost overruns, but I would
guess it would
have been much worse if they had used some other language.  Certainly using Ada
does
not solve all the problems but it does make the job a little easier of having a
wide variety
of skill levels involved on a large project.  With some good management (rarer
than hen's
teeth) and letting the minority of top notch software engineers manage and
enforce a good
process, great results can be achieved even with a lot of lessor skilled people
on the team.
This may be true in other languages as well, but more so in Ada, and every
advantage helps
in a large project like this.

Jerry
--
---------------------------------------------------------------------------------

-- Jerry Petrey
-- Senior Principal Systems Engineer - Navigation (GPS/INS), Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to reply
---------------------------------------------------------------------------------

Re: status of PL/I as a viable language

[John W. Kennedy]

Pointless Harlows wrote:
> You may recall the perfect IBM mainframe utility routine IEFBR14 ;-)

> However, I did hear it said once that even the first version of IEFBR14 had
> a fault in that it didnt return a zero return code.
> Can anyone actually confirm that?

The story is quite true; I remember it well.

It had a second fault; it wasn't tagged re-entrant.

I've heard that it had a third, but it must have been documentation-only.

Of course, every "Hello World" program is perfect.

And I once tested a Julian-date converter (the _real_ Julian date -- 
serially numbered days from January 1, 4713 BC) to exhaustion, so it was 
perfect, too.

-- 
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"

Re: status of PL/I as a viable language

[Preben Randhol]

Hyman Rosen wrote:
> But it took them *two years* to get it specified, designed, and built.
> Maybe it was a polished piece of perfection, but that's a very long
> time to build a message filter.

But two years is nothing!

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Preben Randhol]

Randy Brukardt wrote:
> The web server for AdaIC is written in Ada. I've left all of the

RRS Ada HTTP Server right?

> Although the code has had a variety of buffer overflow and other bugs

Buffer overflow? How?

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Peter Flass]

"Shmuel (Seymour J.) Metz" wrote:
> 
> True. But a huge proportion of the exploits in Internet software rely
> on buffer underruns, which wouldn't exist in a language like Ada that
> has an equivalent to SUBSCRIPTRANGE. And, yes, the checking can be
> turned off in Ada, but I would hope that such an abomination would
> never get through code review.

Once again, it all depends.  If I write (PL/I) code like:
    DO i=LBOUND(array,1) TO HBOUND(array,1); ...
I'm *guaranteed* that I'll never have a subscript problem, no matter
what, and range checking is redundant.  If I take some random value read
from a file and try to use it as a subscript, a range check might be
appropriate, although I'd prefer to do the check myself to better handle
the resulting error.  Most of the internet problems are caused by a
conbination of C, which leaves itself wide open to overflow/underflow,
and poor programming, which can be found in any language.

IEFBR14, was Re: status of PL/I as a viable language

[Peter Flass]

Pointless Harlows wrote:
> 
> "John R. Strohm" <strohm@airmail.net> wrote in message
> > Actually, it IS possible to create perfect code.
> 
> You may recall the perfect IBM mainframe utility routine IEFBR14 ;-)
> 
> However, I did hear it said once that even the first version of IEFBR14 had
> a fault in that it didnt return a zero return code.
> Can anyone actually confirm that?

I've head the same thing, and at one point I believe someone posted the
PTF number for the fix.  This should still be readable in the load
module, since (AFAIK) IEFBR14 hasn't been rewritten since release 1.0 of
OS/360.

Re: IEFBR14, was Re: status of PL/I as a viable language

[Robert Munck]

On Sat, 22 Feb 2003 13:04:06 GMT, Peter Flass <peter_flass@yahoo.com>
wrote:

> (AFAIK) IEFBR14 hasn't been rewritten since release 1.0 of
>OS/360.

Not true. I wrote an upgrade of it for R6.0, renamed it IEFBR15.

(If you know what that did, well, you're old and in the way.)

Bob Munck

Re: IEFBR14, was Re: status of PL/I as a viable language

[John W. Kennedy]

Peter Flass wrote:
> Pointless Harlows wrote:
> 
>>"John R. Strohm" <strohm@airmail.net> wrote in message
>>
>>>Actually, it IS possible to create perfect code.
>>
>>You may recall the perfect IBM mainframe utility routine IEFBR14 ;-)
>>
>>However, I did hear it said once that even the first version of IEFBR14 had
>>a fault in that it didnt return a zero return code.
>>Can anyone actually confirm that?
> 
> 
> I've head the same thing, and at one point I believe someone posted the
> PTF number for the fix.  This should still be readable in the load
> module, since (AFAIK) IEFBR14 hasn't been rewritten since release 1.0 of
> OS/360.

Huh?

IDR data only came in around Release 20 or so, anyway.

-- 
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"

Re: status of PL/I as a viable language

[Everett M. Greene]

Preben Randhol <randhol+news@pvv.org> writes:
> Hyman Rosen wrote:
> > But it took them *two years* to get it specified, designed, and built.
> > Maybe it was a polished piece of perfection, but that's a very long
> > time to build a message filter.
> 
> But two years is nothing!

On a six-month schedule?

Re: status of PL/I as a viable language

[Everett M. Greene]

Hyman Rosen <hyrosen@mail.com> writes:
> John R. Strohm wrote:
> > And that "simple little limited regular expression matcher" passed the
> > formal customer acceptance test on the first try, with no deviations or
> > waivers or anything.
> 
> But it took them *two years* to get it specified, designed, and built.
> Maybe it was a polished piece of perfection, but that's a very long
> time to build a message filter.

One has to consider the economics of the situation.  Is perfection
a requirement or just a target?  There is a point of diminishing
returns beyond which it isn't worth the time and expense to ensure
perfection.

Re: status of PL/I as a viable language

[John R. Strohm]

"Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message
news:20030222.7982838.ABFA@mojaveg.iwvisp.com...
> Hyman Rosen <hyrosen@mail.com> writes:
> > John R. Strohm wrote:
> > > And that "simple little limited regular expression matcher" passed the
> > > formal customer acceptance test on the first try, with no deviations
or
> > > waivers or anything.
> >
> > But it took them *two years* to get it specified, designed, and built.
> > Maybe it was a polished piece of perfection, but that's a very long
> > time to build a message filter.
>
> One has to consider the economics of the situation.  Is perfection
> a requirement or just a target?  There is a point of diminishing
> returns beyond which it isn't worth the time and expense to ensure
> perfection.

In this case, perfection was a requirement.

The message flow modulator is a filter.  Grossly oversimplifying, the data
line carried messages with varying security markings.  Anything carrying
certain marks had to be stopped.

You really don't want a previously-undiscovered bug in your security box to
hand a Top Secret / compartmented message to someone who is not allowed to
receive it.  You REALLY don't want to find out that it has been doing that
for over a year.  In this application, you have to KNOW that there are no
bugs in the software.  You have to PROVE it.  Testing just isn't good enough
to get you there.

Re: status of PL/I as a viable language

[Larry Kilgallen]

In article <828DE23B3B00B2F4.378802739B5A1D47.F69B281EC119A34F@lp.airnews.net>, "John R. Strohm" <strohm@airmail.net> writes:
> "Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message
> news:20030222.7982838.ABFA@mojaveg.iwvisp.com...

>> One has to consider the economics of the situation.  Is perfection
>> a requirement or just a target?  There is a point of diminishing
>> returns beyond which it isn't worth the time and expense to ensure
>> perfection.

> You really don't want a previously-undiscovered bug in your security box to
> hand a Top Secret / compartmented message to someone who is not allowed to
> receive it.  You REALLY don't want to find out that it has been doing that
> for over a year.  In this application, you have to KNOW that there are no
> bugs in the software.  You have to PROVE it.  Testing just isn't good enough
> to get you there.

And based on that description, the decision regarding the need for
perfection was made by the people in charge of the funding.

Re: status of PL/I as a viable language

[James J. Weinkam]

John W. Kennedy wrote:
> 
> And I once tested a Julian-date converter (the _real_ Julian date -- 
> serially numbered days from January 1, 4713 BC) to exhaustion, so it was 
> perfect, too.
> 
Did you test it to exhaustion if the forward as well as the backward direction? :)

Re: IEFBR14, was Re: status of PL/I as a viable language

[Shmuel (Seymour J.) Metz]

In <3E574C46.2F195258@yahoo.com>, on 02/22/2003
   at 01:04 PM, Peter Flass <peter_flass@yahoo.com> said:

>I've head the same thing, and at one point I believe someone posted
>the PTF number for the fix.  

There was an APAR for not setting the return code and a later APAR for
not having an eyecatcher. The latter was in vain, since IBM eventually
removed the eye catcher.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Re: status of PL/I as a viable language

[Shmuel (Seymour J.) Metz]

In <3E569E8C.4050709@cox.net>, on 02/21/2003
   at 09:46 PM, "Donald L. Dobbs" <donaldldobbs@cox.net> said:

>When I first got into the computing business (circa 1962 -- oh my,
>that  probably makes me older than David Frank) we had systems
>analysts and  programmers.  The latter were actually "coders".  The
>systems analysts  were subject matter experts for the application
>being contemplated.  If  it was an accounting or payroll package the
>S.A. was either a CPA or  someone who had a strong background in
>accounting/bookkeeping, etc.  If  it was a guidance program for a
>missile the S.A. was probably a Ph.D. in  math or celestial
>mechanics. The programmer (coder) only had to know his  Cobol,
>Fortran, PL/I or assembly language.  He didn't have to know the 
>subject matter of the application to any great degree because the
>S.A.  wrote an air-tight spec that the coder was to rigorously
>implement.  His  was not to reason why.  We developed pretty good
>software in those days.

Every time someone says "I don't believe in theories.", another theory
dies. What you describe was the conventional wisdom, but in practice
the SA would make mistakes that the coder was not permitted to
correct. It turned out to be more reliable to forget the
coder-as-automaton and go back to the idea of programmers who
understood what they were doing. The good software in the 1960s was
*not* the stuff designed on the hermetic wall methodology.

>Somewhere along the way, it all fell apart when we (as an economy 
>measure in smaller shops, I suppose) invented the
>Programmer-Analyst.  This, IMHO, is the worst single act that has
>occurred in this industry 

While I see it as a return to sanity.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Re: status of PL/I as a viable language

[Shmuel (Seymour J.) Metz]

In <3E574AF3.73E9C38A@yahoo.com>, on 02/22/2003
   at 12:57 PM, Peter Flass <peter_flass@yahoo.com> said:

>Once again, it all depends.  If I write (PL/I)

Ah, but the exploits tend to involve C code, where there is no bounds
check.

>I'd prefer to do the check myself

Well, if I saw (NOSUBSCRIPTRANGE) or (NOSTRINGRANGE) in a code review,
I'd raise a red flag. But I wouldn't complain about a redundant
validity check.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

Re: status of PL/I as a viable language

[John W. Kennedy]

James J. Weinkam wrote:
> John W. Kennedy wrote:
>> And I once tested a Julian-date converter (the _real_ Julian date -- 
>> serially numbered days from January 1, 4713 BC) to exhaustion, so it 
>> was perfect, too.

> Did you test it to exhaustion if the forward as well as the backward 
> direction? :)

Yup.  The original algorithms as I received them had used floating 
point, with unstated assumptions about precision and rounding, so I 
adjusted them to do all calculations with positive integers, so that I 
could be sure that, no matter what language or system I ported to in the 
future, it would work.  Having made so fundamental a change, I wanted to 
be sure that I got it right.

Doing the two-way test over the entire range was just an overnight on a 
4.77MHz 8088.

-- 
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
   -- G. K. Chesterton, "The Man Who Was Thursday"

Re: status of PL/I as a viable language

[Hyman Rosen]

Donald L. Dobbs wrote:
> the S.A. wrote an air-tight spec that the coder was to rigorously implement.

I've rarely seen domain experts who are capable of producing air-tight specs.
They have several problems. They speak in the language of their domain, which
is not the language of the programmer. They know their domain so well that
they fail to explain the things which are obvious to them. And because they
do not think like programmers, their specs rarely cover the corner-cases, so
that they leak badly rather than being air-tight. In fact, they often have no
answer for what to do in these cases, because they have never seen them!

Re: status of PL/I as a viable language

[Hyman Rosen]

Vinzent Hoefler wrote:
> Well, still better it simply falls down doing nothing more harmful than 
> to bury some sheep under it, than to detonate over the wrong (friendly) 
> target.

I meant that there's no time or ability to restart, so it may as well
keep on going instead of shut down. Self-destruct is usually handled
by the ground controllers anyway.

Re: status of PL/I as a viable language

[Hyman Rosen]

Dennis Lee Bieber wrote:
>         From http://www.ima.umn.edu/~arnold/disasters/patriot.html

Interesting. So there was no overflow involved at all,
and no language error, just a bad algorithm. So would
Ada have helped any here?

Re: IEFBR14, was Re: status of PL/I as a viable language

[Pointless Harlows]

"Robert Munck" <munck@mindspring.com> wrote in message
news:jeif5vgolm3m7ovrs8ogvjk2u77vlm0ttq@4ax.com...
> On Sat, 22 Feb 2003 13:04:06 GMT, Peter Flass <peter_flass@yahoo.com>
> wrote:
>
> > (AFAIK) IEFBR14 hasn't been rewritten since release 1.0 of
> >OS/360.
>
> Not true. I wrote an upgrade of it for R6.0, renamed it IEFBR15.
>
> (If you know what that did, well, you're old and in the way.)
>
> Bob Munck

I guess that upgrade has some serious advantages:
  a) It required half the memory of IEFBR14
  b) It didnt suffer from the non-sero return code problem.
  c) Nobody could prove it was wrong because nobody could wait around long
enough for it to finish....

:-)

Re: status of PL/I as a viable language

[Preben Randhol]

Everett M. Greene wrote:
> Preben Randhol <randhol+news@pvv.org> writes:
>> Hyman Rosen wrote:
>> > But it took them *two years* to get it specified, designed, and built.
>> > Maybe it was a polished piece of perfection, but that's a very long
>> > time to build a message filter.
>> 
>> But two years is nothing!
> 
> On a six-month schedule?

Yes

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Donald L. Dobbs]

Hyman Rosen wrote:
> Donald L. Dobbs wrote:
> 
>> the S.A. wrote an air-tight spec that the coder was to rigorously 
>> implement.
> 
> 
> I've rarely seen domain experts who are capable of producing air-tight 
> specs.
> They have several problems. They speak in the language of their domain, 
> which
> is not the language of the programmer. They know their domain so well that
> they fail to explain the things which are obvious to them. And because they
> do not think like programmers, their specs rarely cover the 
> corner-cases, so
> that they leak badly rather than being air-tight. In fact, they often 
> have no
> answer for what to do in these cases, because they have never seen them!
> 

You have obviously never worked on a really huge software development 
project.  Also, you are assuming that no further discourse takes place 
between analyst and programmer and that there are no reviews and 
checkpoints along the way.

If you have a subject matter expert and an excellent programmer both 
assigned to a project you get the best of both worlds.  When you try to 
find some one individual who purports to be both you end up with 
mediocre subject matter expertise compromised by the conflict of 
interest because the programmer hat is telling the subject matter hat to 
go easy on certain legitimate requirements.

There is tons of crap in the marketplace today that tries to pass itself 
off as software.  It is usually incomplete from a domain standpoint and 
is poorly coded to boot.  It takes a beta release and several version 
upgrades before the product really becomes useful.  The manufacturer is 
letting the customer (the subject matter expert in this case) do his 
homework for him -- both in design and debugging.  We just didn't have 
those situations with the products I was associated with.

I've observed both approaches, been involved in both approaches and 
experienced both approaches.  I merely report my observations and remain 
unmoved by your response.

Re: status of PL/I as a viable language

[Berend de Boer]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

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

I'm pretty sure that with those checks included we would have zero
buffer overflow errors and your credit card info would be a lot safer.

-- 
Regards,

Berend. (-:

Re: status of PL/I as a viable language

[tmoran]

> > Although the code has had a variety of buffer overflow and other bugs
>
> Buffer overflow? How?
  Randy may be refering to an off-by-one buffer size error in some code
I wrote passing a buffer to a C (Windows) routine.  :(

Re: status of PL/I as a viable language

[Hyman Rosen]

Berend de Boer wrote:
> I'm pretty sure that with those checks included we would have zero
> buffer overflow errors and your credit card info would be a lot safer.

For the upteenth time, I qualified my statement with "when continued
operation is important". It's not important for a web server to stay
up when it's being attacked if it discovers that it is behaving
erroneously. It is important that a rocket or an airplane which is in
the middle of flying not have its software decide to shut down.

As for my credit card safety, have you seen the news lately? About
the easy attacks on ATM PIN numbers that can have bank insiders
steal your money in fifteen tries or less? Complex software has
complex failure modes. Patting yourself on the back for catching
buffer overruns is a little premature.

Re: status of PL/I as a viable language

[Hyman Rosen]

Donald L. Dobbs wrote:
> I've observed both approaches, been involved in both approaches and 
> experienced both approaches.  I merely report my observations and remain 
> unmoved by your response.

Come to think of it, this is probably what caused the Y2K problem.

Re: status of PL/I as a viable language

[Preben Randhol]

tmoran@acm.org wrote:
>> > Although the code has had a variety of buffer overflow and other bugs
>>
>> Buffer overflow? How?
>   Randy may be refering to an off-by-one buffer size error in some code
> I wrote passing a buffer to a C (Windows) routine.  :(

Ok so the buffer overflow happend in C. 

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Larry Kilgallen]

In article <UPi6a.4466$8f7.333@nwrdny02.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:

> As for my credit card safety, have you seen the news lately? About
> the easy attacks on ATM PIN numbers that can have bank insiders
> steal your money in fifteen tries or less? Complex software has
> complex failure modes. Patting yourself on the back for catching
> buffer overruns is a little premature.

Patting oneself on the back for always avoiding automated tools for
catching buffer overflows is also silly, and some C* programmers do
that.  (Yes, I group C, C++, C# all together, because many of their
advocates do, praising the ability to write C with a C++ compiler.)

Re: status of PL/I as a viable language

[Vinzent Hoefler]

Hyman Rosen <hyrosen@mail.com> wrote:

>Vinzent Hoefler wrote:
>> Well, still better it simply falls down doing nothing more harmful than 
>> to bury some sheep under it, than to detonate over the wrong (friendly) 
>> target.
>
>I meant that there's no time or ability to restart, so it may as well
>keep on going instead of shut down.

Depending on what the error actually does, both things can be
dangerous.

>Self-destruct is usually handled
>by the ground controllers anyway.

Hopefully it is running on a secondary system, otherwise the
off-by-one error in the guidance control system might disable this
feature suddenly. :->


Vinzent.

Re: status of PL/I as a viable language

[Randy Brukardt]

Preben Randhol wrote in message ...
>Randy Brukardt wrote:
>> The web server for AdaIC is written in Ada. I've left all of the
>
>RRS Ada HTTP Server right?


Right. It was based Tom Moran's Simple Server, but of course it was
improved a lot.

>> Although the code has had a variety of buffer overflow and other bugs
>
>Buffer overflow? How?


In order to avoid dynamic allocation of commands, I put the parsed
commands into a record type with a bunch of statically bounded strings.
These have to be carefully handled for overflow, and there were a couple
of obscure cases where I got it wrong. Of course, nothing bad happened,
I just got a logged Constraint_Error and the command was aborted. (Since
the problems all came from people trying to break in, I wasn't even
particularly upset that they weren't served...)

               Randy.

Re: status of PL/I as a viable language

[Preben Randhol]

Randy Brukardt wrote:
> In order to avoid dynamic allocation of commands, I put the parsed
> commands into a record type with a bunch of statically bounded strings.
> These have to be carefully handled for overflow, and there were a couple
> of obscure cases where I got it wrong. Of course, nothing bad happened,
> I just got a logged Constraint_Error and the command was aborted. (Since
> the problems all came from people trying to break in, I wasn't even
> particularly upset that they weren't served...)

So in reality it wasn't a buffer overflow as Ada caught it, while if it
had been in C you would have had a buffer overflow and possibly people
breaking in. Did I understand it correctly?

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Quality (Re: status of PL/I as a viable language)

[Anders Wirzenius]

"John R. Strohm" <strohm@airmail.net> wrote in message news:CACF786833CAF67E.50C10DC07731FD2D.0DEBE34F2ECDF3F2@lp.airnews.net...
> It wasn't extremely good; it was PERFECT.  It did PRECISELY what it was
> designed to do.  It did PRECISELY what the customer WANTED it to do.  And it
> didn't just CLAIM to do that, and CLAIM to have no lurking faults; it was
> rigorously KNOWN to have no lurking faults.
>
> This was part of a long project aimed at developing verification technology
> to the point that it would be possible to build perfect software.  One can
> easily envision domains where exhaustive testing is just not possible, where
> it is necessary to KNOW by other techniques that the software is absolutely,
> positively, correct.  In those domains, "debugging" until it LOOKS like it
> works just isn't good enough.
>
>
>

When you talk about quality, I think a key issue is a discussion about  building quality versus testing quality. What means
"building quality into something"?

The paradoxality lies in that you never can avoid the situation of "First Do It And Then Test What You Have Done".
With "testing" I mean any way (test, review ...) to convince that some entity is fulfilling the requirements put on it.
If you write an essay, the only way to have linguistically correct text is to write a sentence and check (test) your sentence. Then
write the next sentence. And check it.
The only way to guarantee that you spread butter all over your slice of bread is to spread the butter and then check that you have
it all over the slice.

So, how do you then _build_ quality into your product or computer program? By "testing" smartly! By taking your time to plan a
"testing" schedule all over the lifetime of the project. By leaving all testing to the end you just create a big bang and hope that
the bang is a positive one. By splitting the development project into smaller pieces the bangs are smaller and hence the damages of
having negative bangs become significantly smaller.

The thing you have to decide is then: How often do I test? How small pieces do I test?
In a software project you have requirements in the beginning and a running software at the end. What you have in between is your own
choice as a project manager. Your choice may be to build a protype and run a test suite on it, create next proto and test it. Or
your choice may be to divide your project into phases of specification, design and coding and have a testing or review after each
phase.
The specification and the final piece of code (maybe together with necessary hardware) both should demonstrate the end product
entirely. Hence it should be possible to test the requirements of the end product on both embodiments. If the tests show shortages
or inaccuracies the embodiment is incomplete and should be corrected before the project continues. If the specification has passed
your tests (or review, whatever), then you KNOW (as John R. Strohm writes) that you have a correct specification of the end product.

My experience of development projects in electronics and steel industry has strengthen my above described opinion about the value of
dividing the whole project into phases. I have participated in projects where we systematically worked through the project starting
from a verbal specification of the product and ending at a hand held measuring device with correct functions and accuracy and look.
I have also seen development projects ending in a bitter situation where the project manager defended his ideas about a successful
product because that discussion was never held earlier in the project. In the latter situation the project manager DID NOT KNOW
whether or not he was on the right track until at the end of the track.

Anders

Re: Quality (Re: status of PL/I as a viable language)

[Marin David Condic]

You can never escape the necessity of testing. Whatever you build will
ultimately be tested so long as it is actually used. Either you test it or
your customer tests it. But that said, testing can't build in quality. It
can only demonstrate quality - or the lack thereof. Ideally, you would build
a product, test it and find zero errors or defects. That would reflect
building the quality in. Going through a cycle of testing it, fixing it,
testing it again, fixing it again,,,,, is an attempt to test the quality
into a product. Using that approach, you might eventually get to zero
defects, but it takes longer and costs more than if the test immediately
revealed zero defects.

Ada is not the end-all, be-all of software development. It is absolutely not
going to guarantee that you get to zero defects. However, one of the things
I really like about Ada is that it tends to catch lots of simpler errors up
front and never lets them get into the finished product. (Things like type
checking, parameter/interface checking, bounds checking, etc.) On my project
I know from metrics that this saves me cost & schedule compared against the
use of some other languages. (Fortran, C and Assembler, mostly) To the
extent that a language eliminates errors up-front, I think that goes to
"Building Quality In" and the odd thing is that it costs less to build a
better product.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Anders Wirzenius <anders.wirzenius@pp.qnet.fi> wrote in message
news:mCH6a.102$8M5.44@read3.inet.fi...
>
> When you talk about quality, I think a key issue is a discussion about
building quality versus testing quality. What means
> "building quality into something"?
>
> The paradoxality lies in that you never can avoid the situation of "First
Do It And Then Test What You Have Done".
> With "testing" I mean any way (test, review ...) to convince that some
entity is fulfilling the requirements put on it.
> If you write an essay, the only way to have linguistically correct text is
to write a sentence and check (test) your sentence. Then
> write the next sentence. And check it.
> The only way to guarantee that you spread butter all over your slice of
bread is to spread the butter and then check that you have
> it all over the slice.
>
> So, how do you then _build_ quality into your product or computer program?
By "testing" smartly! By taking your time to plan a
> "testing" schedule all over the lifetime of the project. By leaving all
testing to the end you just create a big bang and hope that
> the bang is a positive one. By splitting the development project into
smaller pieces the bangs are smaller and hence the damages of
> having negative bangs become significantly smaller.
>
> The thing you have to decide is then: How often do I test? How small
pieces do I test?
> In a software project you have requirements in the beginning and a running
software at the end. What you have in between is your own
> choice as a project manager. Your choice may be to build a protype and run
a test suite on it, create next proto and test it. Or
> your choice may be to divide your project into phases of specification,
design and coding and have a testing or review after each
> phase.
> The specification and the final piece of code (maybe together with
necessary hardware) both should demonstrate the end product
> entirely. Hence it should be possible to test the requirements of the end
product on both embodiments. If the tests show shortages
> or inaccuracies the embodiment is incomplete and should be corrected
before the project continues. If the specification has passed
> your tests (or review, whatever), then you KNOW (as John R. Strohm writes)
that you have a correct specification of the end product.
>
> My experience of development projects in electronics and steel industry
has strengthen my above described opinion about the value of
> dividing the whole project into phases. I have participated in projects
where we systematically worked through the project starting
> from a verbal specification of the product and ending at a hand held
measuring device with correct functions and accuracy and look.
> I have also seen development projects ending in a bitter situation where
the project manager defended his ideas about a successful
> product because that discussion was never held earlier in the project. In
the latter situation the project manager DID NOT KNOW
> whether or not he was on the right track until at the end of the track.
>
> Anders
>
>

Re: status of PL/I as a viable language

[Randy Brukardt]

Preben Randhol wrote in message ...
>Randy Brukardt wrote:
>> In order to avoid dynamic allocation of commands, I put the parsed
>> commands into a record type with a bunch of statically bounded
strings.
>> These have to be carefully handled for overflow, and there were a
couple
>> of obscure cases where I got it wrong. Of course, nothing bad
happened,
>> I just got a logged Constraint_Error and the command was aborted.
(Since
>> the problems all came from people trying to break in, I wasn't even
>> particularly upset that they weren't served...)
>
>So in reality it wasn't a buffer overflow as Ada caught it, while if it
>had been in C you would have had a buffer overflow and possibly people
>breaking in. Did I understand it correctly?


Right. I think of "Constraint_Error" being raised as a detected buffer
overflow, because it was trying to write outside of a buffer. Of course,
its not actually doing any damage.

The point, of course, is that I didn't write any code to detect this
failure. Indeed, if I had realized where I'd forgotten to protect
against buffer overflow, of course I would have fixed it - adding
checking code beyond that would be silly. So the "being a great
programmer" would not have helped here - I had already tried to detect
all of the overflow cases, but I missed a few. That's called being
human.

             Randy.


            Randy.

Re: Quality (Re: status of PL/I as a viable language)

[Anders Wirzenius]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:b3fq1l$imc$1@slb6.atl.mindspring.net...
> You can never escape the necessity of testing. Whatever you build will
> ultimately be tested so long as it is actually used. Either you test it or
> your customer tests it. But that said, testing can't build in quality. It
> can only demonstrate quality - or the lack thereof. Ideally, you would build
> a product, test it and find zero errors or defects. That would reflect
> building the quality in. Going through a cycle of testing it, fixing it,
> testing it again, fixing it again,,,,, is an attempt to test the quality
> into a product. Using that approach, you might eventually get to zero
> defects, but it takes longer and costs more than if the test immediately
> revealed zero defects.

Product here means finished product, right?
My posting was an attempt to describe the words "build in quality".
When you are building something you have always something _half done_. To build in quality means to me that you convince yourself
that this _half done_ is on the right track. The key question is: how do you do the convincing?

Anders

Re: Quality (Re: status of PL/I as a viable language)

[Larry Kilgallen]

In article <c2Z6a.27$bW6.8@read3.inet.fi>, "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> writes:

> My posting was an attempt to describe the words "build in quality".

That involves (at least) a lot of design issues.

> When you are building something you have always something _half done_. To build in quality means to me that you convince yourself
> that this _half done_ is on the right track. The key question is: how do you do the convincing?

Formal inspections and unit testing.

Re: Quality (Re: status of PL/I as a viable language)

[Larry Kilgallen]

In article <YlYv8xcN9+Bi@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> In article <c2Z6a.27$bW6.8@read3.inet.fi>, "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> writes:
> 
>> My posting was an attempt to describe the words "build in quality".
> 
> That involves (at least) a lot of design issues.

One of which might be formal proof, as discussed for the message filter.

>> When you are building something you have always something _half done_. To build in quality means to me that you convince yourself
>> that this _half done_ is on the right track. The key question is: how do you do the convincing?
> 
> Formal inspections and unit testing.

Re: Quality (Re: status of PL/I as a viable language)

[Marin David Condic]

Anders Wirzenius <anders.wirzenius@pp.qnet.fi> wrote in message
news:c2Z6a.27$bW6.8@read3.inet.fi...
>
> Product here means finished product, right?

Maybe. Maybe it means "an executable image that is capable of undergoing
test". You do some programming. You produce an image. You conduct some
tests. You find some bugs. Go back to the beginning. If you found zero bugs,
that saves you time and money, correct? It means that what you built is of
high quality.


> My posting was an attempt to describe the words "build in quality".

Which I think has to come from proper design and proper processes. Its no
different from a widget manufacturer with his assembly line. The design of
the widget has to be sufficient for its task and the assembly line & tools
used there have to accurately realize that design. When the widget comes out
of any phase of the assembly line and is inspected, finding an error in it
then is not "built in quality".


> When you are building something you have always something _half done_. To
build in quality means to me that you convince yourself
> that this _half done_ is on the right track. The key question is: how do
you do the convincing?
>
I'm not sure what you mean by "half done" here? You are suggesting that the
iterative "code/compile/test/debug" cycle is just a natural part of building
software and finding bugs in that cycle doesn't count towards poor quality?
I think that this would not be a very helpful view in terms of developing
"quality" products because it implies that rework is O.K. Rework always
implies that you are building something poorly and always implies additional
expense. Most industries recognize that the sooner you catch something and
eliminate the problem, the cheaper it is to fix. They also accept that if
you don't put the defect into the product, it doesn't cost you anything to
take it out. Hence the notion of "built in quality"

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Re: status of PL/I as a viable language

[Stephen Leake]

Preben Randhol <randhol+news@pvv.org> writes:

> Randy Brukardt wrote:
> > In order to avoid dynamic allocation of commands, I put the parsed
> > commands into a record type with a bunch of statically bounded strings.
> > These have to be carefully handled for overflow, and there were a couple
> > of obscure cases where I got it wrong. Of course, nothing bad happened,
> > I just got a logged Constraint_Error and the command was aborted. (Since
> > the problems all came from people trying to break in, I wasn't even
> > particularly upset that they weren't served...)
> 
> So in reality it wasn't a buffer overflow as Ada caught it, 

I think the English meaning of the term "buffer overflow" is clear;
the program tried to write more data to the buffer than it had room
for.

> while if it had been in C you would have had a buffer overflow and
> possibly people breaking in. 

The _consequences_ of the buffer overflow are different in C and Ada;
in Ada the overflow is caught, and handled in a way that does not
allow security breaches.

In poorly programmed C, the buffer overflow is not caught, and does
(possibly) allow security breaches.

> Did I understand it correctly?

Not quite: it really is a buffer overflow :).

I suppose the term "buffer overflow" has been overloaded to mean
"buffer overflow that allows security breaches". But in this context,
I think the more narrow meaning is appropriate.

-- 
-- Stephe

Re: Quality (Re: status of PL/I as a viable language)

[Anders Wirzenius]

"Marin David Condic" <mcondic.auntie.spam@acm.org> wrote in message news:b3igbm$eb8$1@slb2.atl.mindspring.net...
> Anders Wirzenius <anders.wirzenius@pp.qnet.fi> wrote in message
> news:c2Z6a.27$bW6.8@read3.inet.fi...

> > When you are building something you have always something _half done_. To
> build in quality means to me that you convince yourself
> > that this _half done_ is on the right track. The key question is: how do
> you do the convincing?
> >
> I'm not sure what you mean by "half done" here? You are suggesting that the

By "half done" I mean that you have something that is not finished to be the end product. It may be a requirements specification. It
may be a flow chart. It is something that describes the goal, the end product. And it should describe it completely (weight, color,
functions, look, odor, packing, customer training ...). The "half done" may be composed of some prototype complemented by
specifications for those parts that you cannot implement using the prototype. If you cannot fulfil size requirements with the proto,
the proto should be enclosed by a specification how big the end product should be. And so on. You then review the whole thing, not
just that part that is in the proto phase.
So, since the "half done" is an instantiation of the complete end product at that particular state, it should be possible to "test"
it against the requirements for the end product.

Maybe I should have used the word review instead of the word test not to mislead people. With "test" I meant any activity to catch
any error or shortage. The word "test" seemed just short and handy to use. I once read about a Japanese company that "tested" their
product requirements specification (which in fact was an instantiation of the end product at that stage) by going out and asking
people what they thought about the product described in the specification. The development project did not continue until the
enquiry results were processed.

> ... You are suggesting that the
> iterative "code/compile/test/debug" cycle is just a natural part of building

No and yes, I am suggesting that you have to do some "testing" of your "half done" (please, understand the word in the wide sence I
tried to describe earlier). You have to know where you are before you can say anything about how much you have deviated from the
right course. You must have something concrete at hand when you do your reviewing. It does not have to be a compiled code. It may be
a flow chart, a state diagram, a whatever, you name it, that you "test". It just has to describe your end product.

> software and finding bugs in that cycle doesn't count towards poor quality?
> I think that this would not be a very helpful view in terms of developing
> "quality" products because it implies that rework is O.K. Rework always
> implies that you are building something poorly and always implies additional
> expense. Most industries recognize that the sooner you catch something and
> eliminate the problem, the cheaper it is to fix. They also accept that if

What is the difference between "rework" and "eliminate the problem" or "fix"?

> you don't put the defect into the product, it doesn't cost you anything to
> take it out. Hence the notion of "built in quality"

That is exactly my point. Fix it while it is cheap. A correction in the specification of the wrapping of the product is much cheaper
than to scrap the packing material at hand and make a new order to the packing material vendor.

My posting was about HOW to find out if you have something cheap to fix.
Unfortunately I just used the wrong word ("test") :-)

Anders

Re: status of PL/I as a viable language

[Preben Randhol]

Stephen Leake wrote:
>> So in reality it wasn't a buffer overflow as Ada caught it, 
> 
> I think the English meaning of the term "buffer overflow" is clear;
> the program tried to write more data to the buffer than it had room
> for.

[..]

> The _consequences_ of the buffer overflow are different in C and Ada;
> in Ada the overflow is caught, and handled in a way that does not
> allow security breaches.
> 
> In poorly programmed C, the buffer overflow is not caught, and does
> (possibly) allow security breaches.

[..]

> I suppose the term "buffer overflow" has been overloaded to mean
> "buffer overflow that allows security breaches". But in this context,
> I think the more narrow meaning is appropriate.

No, the problem arrises when English meaning /= English usage. If
you go saying that your program had an buffer overflow, everybody will
think you had a security hole in it and that somebody took/could take
advantage of this. I think it is better to look at common usage and
follow this eventhough it might not follow the English spec file ;-)

What about : It was a terribly good cake...
(we have the same in our language by the way)

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[Lutz Donnerhacke]

* Hyman Rosen wrote:
> Dennis Lee Bieber wrote:
>>         From http://www.ima.umn.edu/~arnold/disasters/patriot.html
>
> Interesting. So there was no overflow involved at all,
> and no language error, just a bad algorithm. So would
> Ada have helped any here?

Might possible.
 type Time is delta 0.1;
 for Time'Small use 0.0;

Re: status of PL/I as a viable language

[Vinzent Hoefler]

Lutz Donnerhacke <lutz@iks-jena.de> wrote:

> type Time is delta 0.1;
> for Time'Small use 0.0;

You meant "for Time'Small use 0.1", didn't you? I doubt that a value
of 0.0 would be legal, see LRM 3.5.9(8) and (9).


Vinzent.

Re: Quality (Re: status of PL/I as a viable language)

[Peter Flass]

AG wrote:
> 
> "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
> news:mCH6a.102$8M5.44@read3.inet.fi...
> 
> > The paradoxality lies in that you never can avoid the situation of "First
> Do It And Then Test What You Have Done".
> 
> Hmmm, jump off the tall building perhaps? Wanna do some tests?

That's what prototyping is for.  Nothing shows up design weknesses
faster than a good prototype.  Then scrap what you have (if necessary)
and do the *real* design.

Re: status of PL/I as a viable language

[Preben Randhol]

AG wrote:
> 
> "Preben Randhol" <randhol+news@pvv.org> wrote in message
> 
> 
>> Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
>> "Violence is the last refuge of the incompetent", Isaac Asimov
> 
> 
> "Armed society is polite society", Robert Heinlein [from "Beyond this
> Horizon"]
> 
> I think we are in a definite agreement there - pass the guns please :)
> 

No, we are definitely not.

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: Quality (Re: status of PL/I as a viable language)

[Anders Wirzenius]

"AG" <ang@xtra.co.nz> wrote in message news:n%T7a.112532$F63.2422763@news.xtra.co.nz...
> 
> "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
> news:mCH6a.102$8M5.44@read3.inet.fi...
> 
> 
> > The paradoxality lies in that you never can avoid the situation of "First
> Do It And Then Test What You Have Done".
> 
> Hmmm, jump off the tall building perhaps? Wanna do some tests?
> 
> 

So how do YOU build in quality "jumping off the tall building"? ;-)

Anders

Re: Quality (Re: status of PL/I as a viable language)

[Anders Wirzenius]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message news:MV28a.141$X63.124@read3.inet.fi...
> "AG" <ang@xtra.co.nz> wrote in message news:n%T7a.112532$F63.2422763@news.xtra.co.nz...
> > 
> > "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
> > news:mCH6a.102$8M5.44@read3.inet.fi...
> > 
> > 
> > > The paradoxality lies in that you never can avoid the situation of "First
> > Do It And Then Test What You Have Done".
> > 
> > Hmmm, jump off the tall building perhaps? Wanna do some tests?
> > 
> > 
> 
> So how do YOU build in quality "jumping off the tall building"? ;-)
> 
> Anders
> 

Sorry, failed the test:

Should have written: So how do YOU build in quality in "jumping off the tall building"?

Anders

Re: status of PL/I as a viable language

[Richard Riehle]

Preben Randhol wrote:

> No, the problem arrises when English meaning /= English usage. If
> you go saying that your program had an buffer overflow, everybody will
> think you had a security hole in it and that somebody took/could take
> advantage of this. I think it is better to look at common usage and
> follow this eventhough it might not follow the English spec file ;-)
>
> What about : It was a terribly good cake...
> (we have the same in our language by the way)

Context, in most languages, can make a lot of difference.

          The chicken is ready to eat.
          The steak is ready to eat.
          The children are ready to eat.

In the second sentence, there is little ambiguity. We would
hope there is no ambiguity in the third sentence.

Richard Riehle

Re: Quality (Re: status of PL/I as a viable language)

[Frank Clarke]

On Sat, 01 Mar 2003 12:56:42 GMT, Peter Flass <peter_flass@yahoo.com>
wrote:
<3E60AD4A.78002872@yahoo.com>

>That's what prototyping is for.  Nothing shows up design weknesses
>faster than a good prototype.  Then scrap what you have (if necessary)
>and do the *real* design.

Reminiscent of what Fred Brooks said: when you plan a project you
should plan to do it twice -- once to find out what you're really
dealing with, the second to solve the problem.

Re: Quality (Re: status of PL/I as a viable language)

[AG]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
news:mCH6a.102$8M5.44@read3.inet.fi...


> The paradoxality lies in that you never can avoid the situation of "First
Do It And Then Test What You Have Done".

Hmmm, jump off the tall building perhaps? Wanna do some tests?

Re: status of PL/I as a viable language

[AG]

"Stephen Leake" <Stephen.A.Leake@nasa.gov> wrote in message
news:uadgi6foa.fsf@nasa.gov...

> I think the English meaning of the term "buffer overflow" is clear;
> the program tried to write more data to the buffer than it had room
> for.

So much for the precision of the English language :)
To me, "buffer overflow" means that whatever tried
to write into it went over the buffer boundaries.

Never mind the amount of data etc etc - the whole
point of the definition is that the data went [or tried
to go] beyond the allowed range.

For example, if you have a buffer of 1024b and
try to write three zero bytes into it starting at
1023 - will it be a buffer overflow? But the
buffer itself sure had room for those 3 bytes ...

Re: status of PL/I as a viable language

[AG]

"Preben Randhol" <randhol+news@pvv.org> wrote in message


> Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
> "Violence is the last refuge of the incompetent", Isaac Asimov


"Armed society is polite society", Robert Heinlein [from "Beyond this
Horizon"]

I think we are in a definite agreement there - pass the guns please :)

Re: Quality (Re: status of PL/I as a viable language)

[Anders Wirzenius]

"AG" <ang@xtra.co.nz> wrote in message news:6V98a.113960$F63.2447189@news.xtra.co.nz...
>
> "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
> > Sorry, failed the test:
> >
> > Should have written: So how do YOU build in quality in "jumping off the
> tall building"?
> >
> Well, if I had to try that for some reason I would make darn sure that the
> ropes are
> strong and there are multiple ropes just in case one of them fails and there
> is a safety net
> somewhere along the way to the ground. You may say that testing the ropes is
> a test - yes
> it is but it's totally separate from testing the whole thing. The same ropes
> could be used

No, it is not totally separate, it is a (small) part of the "building in quality into the whole thing" . My point has in this thread
been to explain what "make darn sure" or "build in quality" or "catch the problem at an early state" in practice means. Please see
my earlier posts.

The creator of the Cooper's running test (12 min running) told in his book about people that asked him for concrete advises (How
often?, How much? How do I know that I am in good shape?) when he told them to exercise more. Since he wanted to give them an answer
to those excellent questions he developed a point system and also the famous 12 min test itself. My posting was a similar attempt to
open up "build in quality".

> to rig a sailing boat say. That's what built-in quality means - by the time
> you try to test it
> it's way too late.
>
>

I don't know what "That's" is pointing at. So the last sentence did not open to me.

Thank you, AG et.al., but ...
this conversation has now gone that far from Ada, that I put an end to it from my side and thank for the discussion. If somebody
wants to continue, please use my personal email address.

By for now
Anders

Re: status of PL/I as a viable language

[Preben Randhol]

AG wrote:
> Why?
> 
> The whole point of Heinlein's statement was
> that having citizens armed means it's a little
> bit harder for violent types do go violent.

Is this true in USA with 11000 gun related killings per year (if I
remember correctly)?

> Which seems to jive-in nicely with your signature ...

You apparently haven't grasped it then :-)

-- 
Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
"Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[John R. Strohm]

"Preben Randhol" <randhol+news@pvv.org> wrote in message
news:slrnb63urv.1jh.randhol+news@kiuk0152.chembio.ntnu.no...
> AG wrote:
> > Why?
> >
> > The whole point of Heinlein's statement was
> > that having citizens armed means it's a little
> > bit harder for violent types do go violent.
>
> Is this true in USA with 11000 gun related killings per year (if I
> remember correctly)?
>
> > Which seems to jive-in nicely with your signature ...
>
> You apparently haven't grasped it then :-)

Since you have decided to pick the fight...

It perhaps matches more closely with the experience in Australia and the
United Kingdom.

Both nations enacted total bans on private ownership of firearms.

Both nations then watched their firearm crime rates, and their overall
violent crime rates, skyrocket.  They have NO clue why this happened.

Meanwhile, some years back, the small town of Kennesaw, in the state of
Georgia, in the United States of America, passed a local ordinance that
REQUIRED every head-of-household to own a firearm.  While the ordinance was
apparently not taken all that seriously by the locals, Kennesaw nevertheless
saw their crime rate go to zero overnight.

The likely explanation for these observations is simple enough.  When a
cretin decides to commit an antisocial act against a law-abiding citizen,
the cretin must evaluate the likelihood that his target will be armed.  The
calculus is quite simple in those places that have outlawed personal
protection weapons: a law-abiding citizen in those places is known a priori
to be disarmed.  In Kennesaw, the calculus was quite different, a
law-abiding citizen in Kennesaw was now known a priori to be armed and
dangerous.  (The most dangerous armed person is one who does not really know
what he is doing: he is far more likely to shoot to kill.  An armed,
prepared citizen knows that the mere presentation of the business end of a
weapon is sufficient in the vast majority of cases to dissuade a cretin.)
It seems that the cretins who were responsible for the local crime problems
decided that the odds had just shifted against them.

Re: Quality (Re: status of PL/I as a viable language)

[AG]

"Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
news:AY28a.143$X63.104@read3.inet.fi...
>
> "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
news:MV28a.141$X63.124@read3.inet.fi...
> > "AG" <ang@xtra.co.nz> wrote in message
news:n%T7a.112532$F63.2422763@news.xtra.co.nz...
> > >
> > > "Anders Wirzenius" <anders.wirzenius@pp.qnet.fi> wrote in message
> > > news:mCH6a.102$8M5.44@read3.inet.fi...
> > >
> > >
> > > > The paradoxality lies in that you never can avoid the situation of
"First
> > > Do It And Then Test What You Have Done".
> > >
> > > Hmmm, jump off the tall building perhaps? Wanna do some tests?
> > >
> > >
> >
> > So how do YOU build in quality "jumping off the tall building"? ;-)
> >
> > Anders
> >
>
> Sorry, failed the test:
>
> Should have written: So how do YOU build in quality in "jumping off the
tall building"?
>
Well, if I had to try that for some reason I would make darn sure that the
ropes are
strong and there are multiple ropes just in case one of them fails and there
is a safety net
somewhere along the way to the ground. You may say that testing the ropes is
a test - yes
it is but it's totally separate from testing the whole thing. The same ropes
could be used
to rig a sailing boat say. That's what built-in quality means - by the time
you try to test it
it's way too late.

Re: status of PL/I as a viable language

[Georg Bauhaus]

John R. Strohm <strohm@airmail.net> wrote:
: Meanwhile, some years back, the small town of Kennesaw,

it is puzzling to see that people who professionally deal with
logic (programmers) start falling for any particular evidence supporting
something, despite its logical incompleteness, as long as it is in favour
of their views. On either side.

- Of course, one has to ask what kind of place Kennesaw is.
One has to ask how high the percentage of social cohesion
and homogeneity in a town like this is. From what I hear there
is no need to force people to get a gun in parts of Los Angeles,
however it is not particularly silent there.

- One has to ask why it is--again--not seen that the Kennesaw
success might as well have had to do with the "Hawthorne
experiment" effect. It works in part because everyone gets
involved, the emphasis being on getting involved, not on being
cretin or not, and not on weapons.

- One has to ask whether an average sample town is free
of Montagus and Capulets.  And for practical purposes the
average has to be the modus of towns of this kind, because
otherwise it is just one sample that seems to have displayed
some characteristics that cannot really be predicted to occur
elsewhere, given the same requirements.

- One has to assume(!) that there are no cretins in each town
to wich this model can be ported, if it can, see above. For
otherwise people couldn't trust each other; I guess you haven't
missed the "trust discussion" in the USA. Imagine: Every step
you make you will have one hand near your weapon.  - There is
more to add, as to every one-factor-theory.  - So, ...

- Facing community issues, one has to remember, how, for example,
men and women of (protestant christian) god, with no weapons
and a very homogeous social life
deal with people in their community who chose to obey differing
moral rules.  Rules which, as moral rules, are o.K. even for the
conservative U.S. citizen but not for the chiefs in the community.
For (an extreme) example, consider the Hutterer communities:
At best, the "disobedient" will have to leave, banned (without any
possesions). (Not exactly "fault tolerant social software", these
rules.)

As far as drawing conclusions from this example is concerned,
same thing as in the Kennesaw case: interesting but not near
general enough.

Certainly "Bowling for Columbine" is biased, but can you
explain, using Kennesaw theory, why there are less killings
per person in Canada, and why they don't lock their doors in
Toronto, apparently?

It is almost the same as saying, Ada is The Right Programming
Language because in a particular project, some goal had
been achieved. Even in a largely complexity-reduced field
such as programming, a one factor theory is just not enough,
it is detrimental.

And, finally, and most importantly, murder doesn't require the
murderer to have a gun, and gun owners have been murdered more
than once.

Re: status of PL/I as a viable language

[AG]

"Preben Randhol" <randhol+news@pvv.org> wrote in message
news:slrnb61eac.l7.randhol+news@kiuk0152.chembio.ntnu.no...
> AG wrote:
> >
> > "Preben Randhol" <randhol+news@pvv.org> wrote in message
> >
> >
> >> Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
> >> "Violence is the last refuge of the incompetent", Isaac Asimov
> >
> >
> > "Armed society is polite society", Robert Heinlein [from "Beyond this
> > Horizon"]
> >
> > I think we are in a definite agreement there - pass the guns please :)
> >
>
> No, we are definitely not.

Why?

The whole point of Heinlein's statement was
that having citizens armed means it's a little
bit harder for violent types do go violent.

Which seems to jive-in nicely with your signature ...

>
> --
> Preben Randhol ---------------- http://www.pvv.org/~randhol/ --
> "Violence is the last refuge of the incompetent", Isaac Asimov

Re: status of PL/I as a viable language

[John R. Strohm]

"Georg Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote in message
news:b3u73c$7uo$1@a1-hrz.uni-duisburg.de...
> John R. Strohm <strohm@airmail.net> wrote:
> : Meanwhile, some years back, the small town of Kennesaw,
>
> it is puzzling to see that people who professionally deal with
> logic (programmers) start falling for any particular evidence supporting
> something, despite its logical incompleteness, as long as it is in favour
> of their views. On either side.

I find it amazing that an individual who allegedly deals professionally with
logic should apparently be so totally unfamiliar with the concept of
"experiment".

I will simplify it for you.

The hypothesis is that legal availability of firearms correlates positively
with violent crime rate.  This suggests that curtailing the legal
availability of firearms should, if the hypothesis is correct, reduce the
violent crime rate.

A simple analysis would reveal a questionable assumption, namely, that an
individual who is predisposed to commit a violent crime might nevertheless
obey a law that denied him the right to own a firearm, but we will neglect
that particular contradiction for the purpose of this analysis.

An experimentalist immediately realizes that it is easy to test the
hypothesis by curtailing personal firearm ownership and seeing whether the
violent crime rate goes down, as the hypothesis would predict.

This, Herr Bauhaus, is called "conducting an experiment."

We first observe that this experiment has been conducted in varying degrees
in quite a number of places in the United States.  The results of those
experiments have been UNIVERSALLY negative: in EVERY venue in which it has
been tried, the result has been an INCREASE in the violent crime rate.  It
is a trivial exercise with an almanac to verify the statistical truth that
those locales in the United States with the toughest local gun control laws
also have the HIGHEST violent crime rates.

We further observe, Herr Bauhaus, that similar experiments were conducted,
on much larger scales, national rather than local or regional, in Australia
and the United Kingdom.  Both of those trials gave the same negative
results: both nations experienced a dramatic INCREASE in their violent crime
rates.

This evidence, by itself, should be enough to indicate that the proposed
hypothesis is, at best, faulty.

However, another trial was performed, at Kennesaw.  If the hypothesis was
true, then REQUIRING all citizens of Kennesaw to own firearms SHOULD have
resulted in an immediate and statistically-significant INCREASE in the
violent crime rate.

However, when the experiment was tried, It Didn't Work Out That Way.
Kennesaw instead saw an immediate, almost heart-stopping, decrease in the
local crime rate.

It should be noted in passing that Kennesaw is not much different from other
small towns in that part of Georgia.  Before the ordinance was passed, they
all had pretty comparable demographics, populations, institutions, and crime
rates.  After the ordinance passed, only Kennesaw saw the dramatic reduction
in crime.  The first-order interpretation of the data would tend to suggest
that, in this CONTROLLED study (the other towns being, of course, the
control group), the ordinance made a difference and the result emphatically
did not support the hypothesis, but rather argued forcefully that the
hypothesis was false.

 > - Of course, one has to ask what kind of place Kennesaw is.
> One has to ask how high the percentage of social cohesion
> and homogeneity in a town like this is. From what I hear there
> is no need to force people to get a gun in parts of Los Angeles,
> however it is not particularly silent there.

Actually, it is quite difficult.  California requires a three WEEK waiting
period between purchase and delivery.  This caused significant difficulty
during the civil unrest after the Rodney King verdict: local shopkeepers who
realized there was trouble brewing, and who wished to purchase weapons to
deter rioters and looters from destroying their businesses were prevented
from doing so.  Those few shopkeepers who had a more jaundiced view of the
local animals, who already owned firearms, had no difficulty persuading the
looters to go elsewhere: it is amazing how effective the mere sight of a
weapon is in deterring a cretin.

> - One has to ask why it is--again--not seen that the Kennesaw
> success might as well have had to do with the "Hawthorne
> experiment" effect. It works in part because everyone gets
> involved, the emphasis being on getting involved, not on being
> cretin or not, and not on weapons.

The Hawthorne Effect is that both positive and negative changes in the
control variable produce the same kind of change in the controlled variable.
For a Hawthorne Effect hypothesis to be supportable in this area, BOTH
increasing AND curtailing the legal availability of firearms must have had
the SAME qualitative effect, that of either increasing or decreasing the
crime rate.  A quick review of the experimental data, however, shows that
this is most emphatically not the case, and so the Hawthorne Effect
hypothesis must be rejected.

> - One has to ask whether an average sample town is free
> of Montagus and Capulets.  And for practical purposes the
> average has to be the modus of towns of this kind, because
> otherwise it is just one sample that seems to have displayed
> some characteristics that cannot really be predicted to occur
> elsewhere, given the same requirements.

Montague-Capulet feuds have historically not been common in the United
States.

While it is true that Kennesaw is a small town of a certain character, there
are MANY such small towns of similar character in the United States.  It is,
as I have discussed above, also the case that Kennesaw is not by any stretch
of the imagination the only data point under consideration.

> - One has to assume(!) that there are no cretins in each town
> to wich this model can be ported, if it can, see above. For
> otherwise people couldn't trust each other; I guess you haven't
> missed the "trust discussion" in the USA. Imagine: Every step
> you make you will have one hand near your weapon.  - There is
> more to add, as to every one-factor-theory.  - So, ...
>
> - Facing community issues, one has to remember, how, for example,
> men and women of (protestant christian) god, with no weapons
> and a very homogeous social life
> deal with people in their community who chose to obey differing
> moral rules.  Rules which, as moral rules, are o.K. even for the
> conservative U.S. citizen but not for the chiefs in the community.
> For (an extreme) example, consider the Hutterer communities:
> At best, the "disobedient" will have to leave, banned (without any
> possesions). (Not exactly "fault tolerant social software", these
> rules.)

This is true in those limited (!) cases.  Such communities are VERY rare in
the United States, far more so than towns like Kennesaw.

> As far as drawing conclusions from this example is concerned,
> same thing as in the Kennesaw case: interesting but not near
> general enough.
>
> Certainly "Bowling for Columbine" is biased, but can you
> explain, using Kennesaw theory, why there are less killings
> per person in Canada, and why they don't lock their doors in
> Toronto, apparently?

No, I can't.  Nor am I crazy enough to assume without testing that the
examples of what works in Canada, or specifically in Toronto, are likely to
be applicable elsewhere.

That is the key point.  It is necessary to test the hypotheses in the area
of interest.  The tests that have actually been performed, in many parts of
the United States, and in Australia and the United Kingdom, seem to argue
strongly that the Kennesaw model *IS* applicable.

As an extreme example, it is for all practical purposes unlawful for a
citizen of the District of Columbia, the capital of the United States, to
possess a firearm.  It is also the case that the District of Columbia has
the highest murder rate in the United States, almost all committed with
firearms.  It is a matter of fact that the District police department is
totally and completely outgunned by the local drug gangs, and the District
chief of police admitted it on television several years ago, during a highly
lethal "turf war" between two rival gangs.

> It is almost the same as saying, Ada is The Right Programming
> Language because in a particular project, some goal had
> been achieved. Even in a largely complexity-reduced field
> such as programming, a one factor theory is just not enough,
> it is detrimental.

Not proven.  A one-factor hypothesis that CONSISTENTLY gives the same
result, when everything else is held constant, is a strong indicator of
ground truth.  A one-factor hypothesis that continues to give consistent
results when other variables are varied, or that can be calibrated for other
variables, is even stronger.  A one-factor hypothesis must fail to give
consistent results in these cases before multiple-factor hypotheses can
reasonably be considered.  (Occam's Razor is, after all, required knowledge
for programmers.)

> And, finally, and most importantly, murder doesn't require the
> murderer to have a gun, and gun owners have been murdered more
> than once.

"Statistical significance" is the important concept here.  In Japan,
gun-related crime had been almost unknown.  There was and is still murder,
but it mostly used other weapons.  It is also significant to note that gun
possession is unlawful in Japan, but gun-related crime in Japan is
increasing steadily.

The fundamental rule is this:  One experimental result is worth a thousand
theories.  When theory and experimental result conflict, the experimental
result must win.

Re: status of PL/I as a viable language

[Preben Randhol]

John R. Strohm wrote:
> 
> Since you have decided to pick the fight...

Huh? I didn't pick any fight. I'm not interested in debating this on the
Ada list.


Preben

PS: I changed the signature again :-)
-- 
This is Ada95 land. On quiet nights you can hear C programmers debug.

Re: status of PL/I as a viable language

[Faust]

Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:

> explain, using Kennesaw theory, why there are less killings
> per person in Canada, and why they don't lock their doors in
> Toronto, apparently?

Or in large parts of Sydney.

My front door and french windows lie open all day.
I close the front door at night.
But leave the french windows open most nights.
( I close them in winter )

The back door and all the windows are left open 24 hours a day ,
regardless of whether or not there is someone at home.

However, I do live in a rather low crime part of Sydney.


-- 

natsu-gusa ya   / tsuwamono-domo-ga   / yume no ato
summer grasses  / strong ones         / dreams site
 
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)

OT: Crime

[Frank J. Lhota]

> Or in large parts of Sydney.
>
> My front door and french windows lie open all day.
> I close the front door at night.
> But leave the french windows open most nights.
> ( I close them in winter )
>
> The back door and all the windows are left open 24 hours a day ,
> regardless of whether or not there is someone at home.
>
> However, I do live in a rather low crime part of Sydney.

Or in large parts of Ohio, USA. As a child growing up in Canton and
Ashtabula, the only time I recall locking the doors was when we moved.
Recently, I was reading a memoir of a woman who grew up in Harlem (a
primarily African-American section of New York City) in the early 50's. She
said that her family did not lock their doors either.