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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c617ae447ca32f2f X-Google-Attributes: gid103376,public X-Google-Thread: ff121,3ae3fa74ecb04ab8 X-Google-Attributes: gidff121,public X-Google-ArrivalTime: 2002-04-01 18:16:42 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!deine.net!amsnews01.chello.com!news-hub.cableinet.net!blueyonder!psiuk-p2!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.software.extreme-programming,comp.lang.ada Subject: Re: Ariane Failure Date: Mon, 1 Apr 2002 10:22:54 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CA4B8E5.72909C9B@adaworks.com> <3CA50E9A.CBF24F1B@lanl.gov> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1017674574 7147 136.170.200.133 (1 Apr 2002 15:22:54 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 1 Apr 2002 15:22:54 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.software.extreme-programming:12826 comp.lang.ada:21967 Date: 2002-04-01T15:22:54+00:00 List-Id: Given infinite processor speed and infinite memory, they might have done a whole lot with the software to make it more flexible and safe. But that sort of sounds like doing engineering in Heaven. :-) These sorts of compromises are made all the time in real world engineering and you have to ask if they were reasonable for the conditions at hand. In my mind, the decisions made by the Ariane 4 engineers in designing their software were very similar to the decisions made by data processing programmers years ago in using only two digits to store a year - thus creating The Great Y2K Disaster. Back in the 70's & 80's, they were confronted with smaller storage devices and saving those extra couple of bytes in every date was important. The thinking at the time was "Its a known limitation and the useful life of this software ought to be something less than twenty years, so when they build the next system they can accommodate 4-digit years..." I thought that was a reasonable compromise in order to deal with the constraints of technology at the time. Even though hardware and resources get more abundant in the future, we'll still be making compromises - just different ones. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Michael Feathers" wrote in message news:a84f5p$nlm$1@slb5.atl.mindspring.net... > > Yes. It seems like the error prone part is going back to integers at all. > Since it is a safety consideration it seems like it would be great to > revisit that as processing and communications speeds increase. >