[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The Airplane Example (was Re: StreamingXML)


airplane processor
On Tue, 4 Jan 2005 17:29:27 -0800
"Dare Obasanjo" <dareo@m...> wrote:

> > -----Original Message-----
> > From: Amelia A Lewis [mailto:amyzing@t...] 
> > Sent: Tuesday, January 04, 2005 5:17 PM
> > To: Daniela Florescu
> > Cc: xml-dev@l...
> > Subject: Re:  The Airplane Example (was Re: 
> >  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, [expletive deleted]!  You did it just like I told you to!"  (The manager's lament)

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.