[
Lists Home |
Date Index |
Thread Index
]
On Tue, 4 Jan 2005 17:29:27 -0800
"Dare Obasanjo" <dareo@microsoft.com> wrote:
> > -----Original Message-----
> > From: Amelia A Lewis [mailto:amyzing@talsever.com]
> > Sent: Tuesday, January 04, 2005 5:17 PM
> > To: Daniela Florescu
> > Cc: xml-dev@lists.xml.org
> > Subject: Re: [xml-dev] The Airplane Example (was Re:
> > [xml-dev] StreamingXML)
> >
> > Actually, according to the full report:
> >
> > http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
> >
> >
> > In other words, because of strong typing and exception
> > handling in Ada, Ariane 5 crashed.
>
> That's not the conclusion I came to from that report. Can you explain
> how weak typing [or dynamic typing which was the original point of the
> thread] would have made this problem any better?
Sure. Dynamically typed languages aren't going to have the overflow
error in the first place. Now, the overflow error was in a function
which was redundant to flight operation, but because it occurred and was
not handled, the software was designed to shut down the processor. When
the second processor tried to shut down, it couldn't, because of another
function requiring that its backup (which had already failed) be on
line. So it dumped core (sent diagnostic data to the main computer),
which was interpreted as altitude information, which in turn caused a
major course-correction burn to be initiated (in error, since the
diagnostic data wasn't altitude data), causing the vehicle to begin to
disintegrate, causing the range safety to trigger the self-destruct.
What it *wasn't* was a type casting error. Not in bloody Ada; it's
*not* a weakly typed language that would *permit* a typecasting error of
that magnitude. Among the bondage and discipline languages, Ada stands
out as a laughing sadist. A dynamically typed language would have
determined that the integer was bigger than sixteen bits (not that it
mattered much, since the function that went gronk was part of the
alignment reset function, inapplicable to Ariane 5).
The key is that it was the throwing of the error that caused the
processor to shut down. If the processor had ignored the error (because
the language didn't have exception handling, for instance, or because an
error wasn't thrown) the flight would have continued. That the error
had nothing to do with flight is merely ironic, at that point.
> I think the report vindicates Dana's position.
I'll just disagree, then. The authors of the report also tend in that
direction, since their solution is to increase the rigor of typing,
exception handling, and testing, but they *also* specify that the
processor should not shut down (should provide "best available" data) in
the face of an error.
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
"Oh, fuck! You did it just like I told you to!" (The manager's lament)
|
