From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e6a2e4a4c0d7d8a6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-20 13:22:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!firewall.mdc-dayton.COM!not-for-mail From: Vinzent Hoefler Newsgroups: comp.lang.ada Subject: Re: status of PL/I as a viable language Date: Thu, 20 Feb 2003 16:20:55 -0500 Organization: JeLlyFish software Message-ID: References: <3E51908E.9CCA3412@adaworks.com> <8Gh4a.7455$_c6.743959@newsread2.prod.itd.earthlink.net> <3E51ABCE.5491B9A2@adaworks.com> <3E5273DE.2050206@cox.net> <3E531E6F.BDFB2599@adaworks.com> <3E546C45.4010406@cox.net> <3E54F926.441D5BB5@adaworks.com> <1045763933.848350@master.nyc.kbcfp.com> <42EA55F4BE83950E.F1DA277C2FDC157B.C804C1C52FE95D65@lp.airnews.net> <1045769690.126389@master.nyc.kbcfp.com> <2lb33b.7d6.ln@jellix.jlfencey.com> <1045772065.590669@master.nyc.kbcfp.com> NNTP-Posting-Host: firewall.mdc-dayton.com (12.161.103.180) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1045776149 52847297 12.161.103.180 (16 [175126]) X-Orig-Path: jellix.jlfencey.com!nobody X-Newsreader: KCNews v0.19b (CAOS 4.1) X-Phone: +1-937-271-7158 X-Homepage: http://jlfencey.com Xref: archiver1.google.com comp.lang.ada:34304 Date: 2003-02-20T16:20:55-05:00 List-Id: 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