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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,66752102482bbdca X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Required Metrics Date: 2000/05/04 Message-ID: <_HnQ4.7884$wb7.550012@news.flash.net>#1/1 X-Deja-AN: 619360250 References: <5DDO4.2237$wb7.194854@news.flash.net> <8ek4ea$5ta$1@nnrp1.deja.com> <390DC8AD.59B5EBEE@averstar.com> <8ep0k3$jlr$1@nnrp1.deja.com> <8es5fv$4ov$1@nnrp1.deja.com> X-Priority: 3 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 957482874 216.215.79.68 (Thu, 04 May 2000 18:27:54 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Thu, 04 May 2000 18:27:54 CDT Newsgroups: comp.lang.ada Date: 2000-05-04T00:00:00+00:00 List-Id: "Robert Dewar" wrote in message news:8es5fv$4ov$1@nnrp1.deja.com... > In article , > "Ken Garlington" wrote: > > > I get a queasy feeling when it seems that the Ada vendor > > community may not be addressing requirements they don't like. > > I think that's the wrong take entirely. In the case of metrics > (see Bob Duff's post), there is a broad feeling that these are > completely bogus requirements for modern compilers. Here's the first problem I have with this statement. Either (a) it's not true, and so this is a real issue, or (b) it is true, and has been true for some time, in which case how did it manage to get into the standard? or (c) something changed between 1994-ish and now (really well before now, since apparently no one has ever met this part of the standard), and if so, what changed? Here's the second (and larger) problem, as I've mentioned before. Why should "feelings" be related to requirements? Why go through the motions to formally establish the requirement and get a consensus documented and approved, if there's not an equal intent to do something formal (an AI, at least) to remove such a "bogus" requirement? It appears like the classic case of people writing down a requirements document just because the customer says you have to do one, but promptly ignoring it through the rest of the life cycle. Regardless of the facts of the matter, should the Ada community give such an appearance? > If they > ever had any meaning it would only be for bare-board compilers > for very specific architectures. However, I'd claim that there are still a significant number of real-time systems that do, in fact, get implemented on bare-board systems. I don't know which are the "specific architectures," but certainly real-time systems use a variety of them. Since we're talking about the real-time annex, then surely the environments in which real-time systems operate should be a strong consideration for the appropriateness of such a requirement. For example, is there a GNORT target for which the metrics are meaningful? > It is not that the vendor "does not like" this particular > requirement in our case, it is simply that > > a) it is meaningless, but we do meet the requirement anyway, > perhaps not in the most useful way, but since it is pretty > much useless, there is not much point in trying to do useless > things in a useful manner! Again, the issue of whether it's an appropriate requirement is interesting, but it's not the real issue. I'm still not convinced that you meet the requirement in the current release, for that matter. More importantly, since this is not about a specific compiler, I'm not convinced _anyone_ has bothered to meet the requirement. I don't have proof that this is the case, but it concerns me. Most importantly, it seems this argument can be used to justify all sorts of mischief. > b) our customers have zero interest in us doing any more > than we do now. > > As we often find, CLA readers and contributors seem to have > rather different priorities from actual Ada users when we get > to discussing various theoretical issues surrounding the RM :-) Again, I find the argument of user priorities a very slippery slope, which can be used to invisibly drop any number of requirements. It's useful for discussing the options for implementing a requirement (e.g. a fancy calculator for computing the metric vs. "here's the sources, have at it"), but good software engineering would say that failing to meet a requirement due to perceived user desire, particularly when the discrepancy is not explicitly documented, is definitely not a Good Thing.