Re: Required Metrics

["Ken Garlington" <Ken.Garlington@computer.org>]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:8es5fv$4ov$1@nnrp1.deja.com...
> In article <yLUP4.4522$wb7.450636@news.flash.net>,
>   "Ken Garlington" <Ken.Garlington@computer.org> 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.