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,eb35be86b1c0bdcb X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-12-15 09:16:20 PST Path: supernews.google.com!sn-xit-02!supernews.com!216.227.56.88.MISMATCH!telocity-west!TELOCITY!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!xfer13.netnews.com!netnews.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: Marin David Condic Newsgroups: comp.lang.ada Subject: Re: THAAD Study on Ada Viability Date: Fri, 15 Dec 2000 12:14:48 -0500 Organization: Quadrus Corporation Message-ID: <3A3A5188.C1541447@acm.org> References: <90lj4s$8h7$1@nnrp1.deja.com> <918u24$8ms$1@neptunium.btinternet.com> <91aejd$jgr$1@nnrp1.deja.com> <91cqd6$siu6@news.kvaerner.com> <3A3A1B96.208E7FF2@acm.org> <8Mp_5.8561$bw.810426@news.flash.net> NNTP-Posting-Host: d1.56.bd.c8 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 15 Dec 2000 17:14:25 GMT X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en Xref: supernews.google.com comp.lang.ada:3175 Date: 2000-12-15T17:14:25+00:00 List-Id: Maybe those are the "external realities" I alluded to? :-) Here's the way I see it: The importance of freezing of the environment is in direct proportion to the cost of verification. If you cobble something together that computes loan amortization on a Windows platform and basically all you do is "smoke testing" then hand it off to your customers, there isn't much to worry about. If you spend millions (billions?) of dollars going through various stages of testing for an embedded product that *must* work without error, changing the environment means going back and spending that same millions of $$$ to re-validate the system if, for example, you change compilers, processors, communications hardware, etc. Wellllll..... *maybe* you can eliminate *some* of the testing, reducing it to just demonstrating the same functionality you had before and lack of errors in the software. But it could still cost *a lot* to do. Now sometimes, the economics of it become ridiculus. If your chip maker decides to shut down production due to lack of interest, what are you going to do? Open up your own silicon foundry? Guess you're going to have to buy a different processor and start revalidating your software. :-) Of course you might freeze versions of a compiler even on fairly short-lived and non-critical projects just because it is working "good enough" and you don't want to take the chance of introducing new bugs. MDC Ken Garlington wrote: > Yeah, we thought we were going to do that with our VAXen. After all, that's > the approach we had used on every previous program. However, there's some > ugly consequences: (a) it runs at cross-purposes with another popular > corporate trend - standardizing on a single (yet evolving) platform to > reduce cost; (b) it makes it even more difficult to attract quality software > engineers to the project; and (c) it assumes that you're also going to be > able to freeze your target architecture (e.g. MIL-STD-1750, MIL-STD-1553...) > which is also no longer realistic. > : -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Giving money and power to Government is like giving whiskey and car keys to teenage boys." -- P. J. O'Rourke ======================================================================