Re: Fortran or Ada?

["Condic, Marin D." <condicma@PWFL.COM>]

You know, I heard that the oxygen canisters which blew up on the ValueJet
that crashed here a couple of years ago got on board because of an error
made by some baggage handling software written in Ada.

And I had heard that Linda Tripp's tape recorder was programmed in Ada, and
see how much trouble that has caused!

And Jeffrey Dhalmer was an Ada programmer before he became a mass murder and
cannibal. Coincidence? I think not!

Just more examples of how terribly dangerous Ada must be. (tongue firmly
embedded in cheek ;-)

In all seriousness, there are always going to be people who have some sort
of predisposition to dislike Ada and then they are going to go off fishing
for reasons why that is somehow a rational belief. Any rational being, upon
reading the accident report, would have to conclude that the problem was one
rooted in the fact that they took software that successfully operated on
project A and moved it to project B without ever testing it in the new
environment. The people who concentrate on Ada/Exception/Whatever features
as the "cause" of the disaster are the types who would look at a failed bolt
under an electron microscope and conclude that the "cause" of the accident
was these micro-stress-cracks originating from uneven case-hardening, yada
yada yada.... They'd never notice that the bolt should have been three times
as big for the application it was expected to handle.

MDC


"Robert I. Eachus" <eachus@SPECTRE.MITRE.ORG> writes:
>In rticle <19980928.184428.604@yktvmv.watson.ibm.com>
>jbs@yktvmv.watson.ibm.com writes:
>
>   > It appears to me that this implicates Ada in at least two respects...
>
>    If you read a little more, you will find that it doesn't implicate
>Ada or any other programming language.  They followed this particular
>fault tree all the way down because it occurred, not because the
>rocket would have survived if it hadn't.  Note later in the report
>where it says that the stack was destroyed when the engine deflection
>exceeded the physical stress limits of the stack (booster and
>payload).  Because the software was used WITHOUT CHANGE from the
>Arianne 4, it contained the wrong physical parameters for the dynamic
>deflection limits.  This launch was a disaster waiting to happen, and
>no programming language is going to save you from putting in the wrong
>numbers.  The particular error that occurred was just the first case
>where differences between the Arianne 4 and Arianne 5 became
>significant.
>
>    One last note which bears repeating.  There were no programmers or
>other non-management personnel at fault, because management ELIMINATED
>all such positions.  The inertial management unit was being reused
>without change on the Arianne 5, so no developers were ever hired.
>Given a choice of test methods, they chose to demonstrate that the IMU
>worked.  But the "full-up" simulation testing was cancelled--as a cost
>saving--before the development work on the non-flight parts was
>complete.  No non-manager ever had both the Ariane 5 technical specs
>and the flight guidance software in hand, with or without authority to
>evaluate or test one against the other.
>
>

Marin D. Condic
Real Time & Embedded Systems
Pratt & Whitney,
Government Engines & Space Propulsion
M/S 731-95, P.O.B. 109600,
West Palm Beach, FL, 33410-9600
Ph: 561.796.8997         Fx: 561.796.4669

"The speed with which people can change a courtesy into an entitlement is
awe-inspiring."
        --  Miss Manners, February 8, 1994