From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 14 Dec 92 17:21:00 GMT From: agate!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc .ti.com!tilde.csc.ti.com!mksol!mccall@ucbvax.Berkeley.EDU (fred j mccall 575-3 539) Subject: Re: Open Systems closed to Ada? Message-ID: <1992Dec14.172100.19250@mksol.dseg.ti.com> List-Id: In eachus@oddjob.mitre.org (Robert I. E achus) writes: > I'm not going to quote any of Fred McCall's broken record, >especially since most of it just ain't so. Disproof by assertion. Lovely. >The DoD mandate says use >a validated Ada compiler. The validation rules go on to say what >validation of an Ada compiler means. It has never meant, and never >will mean strict conformance to a particular standard. (Godel proved >that impossible quite a while ago.) Validation sets a standard of >quality, and provides a process for determining whether a particular >deviation from the ACVC tests can be justified. No, what it means is that you have to pass the validation suite. This means, in essence, no significant extensions to the language. > In particular if a compiler vendor has an Ada compiler which >includes some Ada 9X features, or adds support for rate-monotonic >scheduling or what have you, it is not automatically rejected. >Instead, any deviations are evaluated to determine if the vendor's >justification is in fact acceptable. Then it's rejected. ;-) Seriously, do you honestly believe that if someone had come up with an Ada compiler that allowed multiple inheritance, etc., in 1986, that it would have been validate? *I* don't. > In practice the ARG acts as a court of last resort in such cases. >If the fast reaction team (FRT) or the ARG feels that an issue needs >further discussion, the validation certificate in question is issued, >and the test in question is withdrawn if necessary until the issue is >resolved. Starting with ACVC 2.0, this process will be further >streamlined to encourage vendors to offer such (legitimate) >extensions, and also to allow vendors to release new technology >sooner. And just what constitutes an 'illegitimate' extension and how do you decide? What about a compiler whose default behaviour matches the standard (and passes the validation suite) but which has switches that turn on and off various features. Would you validate it or not? > There have been cases where some members felt this was used by one >vendor or another as a sort of sneaky loophole, but others didn't. In >this case the rule is effectively innocent unless unanimously found >guilty. In other cases--even though the test was correct and the >compiler was wrong--a test was withdrawn because the ARG felt it was >counterproductive. We even have a class of AI called pathology, >informally defined as "we'll tell the vendors what they should do, but >no user, and especially no ACVC test, should expect it to work that >way." > So validation and the Ada mandate are NOT intended to stiffle >innovation or limit creativity. Of course they're not INTENDED to do that. Hell, nobody sets out to DELIBERATELY prevent progress. >They are intended to insure that long >lived source code is still useable ten years from now, without a lot >of support costs. It is one thing to say what the language should do and test for that insofar as comiling working code. The problem is that in a lot of cases extensions to the compiler that permit it to accept certain constructs that are 'not Ada' is enough to prevent validation (unless they've changed the rules considerably). That's hardly necessary to keep working code working, now is it? After all, if the code wasn't 'broken' originally, it won't be broken in the future. Of course, USING one of those extensions can lead to code that breaks on a compiler that doesn't support them (presumably the reason why getting compilers with extensions through validation is tough), but what about pragmas? One compiler could offer a pragma that another doesn't support, and when you change compilers code is going to break. So just what have you accomplished, other than discouraging innovation? >You don't like that, play in another sandbox. I don't like it. I think it's a bad idea. I will continue to say that I think it's a bad idea. If you don't like that, go to a country where the government is allowed to prevent people from saying what they think. >I >can find you companies which mandate FORTRAN, C, C++, COBOL, and LISP, >but you probably wouldn't be happy with any of them. Well, goody goody for you. I certainly hope those companies are working in a field for which that mandated language is well suited; otherwise they're doing the same silly thing that the govenrment does. >The company >policy is there for the same reason as the DoD policy, and your >difficulty seems to involve having rules to enforce software >engineering standards. Well, I don't feel particularly responsible for how things "SEEM" to you. The problem would appear to be with your perceptions. -- "Insisting on perfect safety is for people who don't have the balls to live in the real world." -- Mary Shafer, NASA Ames Dryden ------------------------------------------------------------------------------ Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.