Re: Personality Conflict was: why Ada is so unpopular ?

["Randy Brukardt" <randy@rrsoftware.com>]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.20.1075131072.2270.comp.lang.ada@ada-france.org...
> Mike Brenner <mikeb@mitre.org> writes:
> > B. There is no central email address where we can submit suggestions
> > for language changes.
>
> Yes there is: ada-comment@ada-auth.org

And the Ada comment list has existed since the beginning of time (that is,
Ada 83). It's address has changed a couple of times, but it has always
existed.

The current version is completely open to the public; see
http://www.adaic.com/standards/articles/comment.html
for details about signing up.

> > C. There is not central email address where we can submit Bug
> > reports. Therefore bug reports are only selectively accepted by the
> > manufacturer of "supported versions", making it impossible to know
> > the scope and impact of the bugs, or to measure the improvement of
> > the language over the years.
>
> Hmm. If you mean "bug reports about the language", as opposed to "bug
> reports about a compiler", there is a central email address (as
> above).
>
> Certainly bug reports about compilers should go to the compiler
> vendors?

Right. The OP seems to be assuming that Ada = GNAT, which certainly is not
true. (The folks at Rational, Aonix, ICC, DDCI, Green Hills, and RRS would
certainly object to such a characterization. [Apologies to anyone I left
out.]) And sending bugs in Aonix's compiler to DDCI won't be very useful.

And certainly, complaining about bugs in a "free" product is
counter-productive. You get what you pay for, and if you want bugs fixed in
a timely manner, you need to pay (someone) for that service. Otherwise, you
are hoping that some paying customer runs into the same problem - and there
is no guarentee of that.

> > D-2. The lack of ability of the people at the top to counter their
> > prevailing belief that "semantics" has nothing to do with
> > "efficiency". As a result of this false belief their decisions,
> > their manuals, and their features are implemented in inefficient
> > ways. The 3 most egregious examples of this inefficiency are:
> >
> >         (a) Static variables don't remain static
> >         when generically instantiated.
>
> I'll need an example to understand this issue. I have not encountered
> a problem like this.

I think he's referring to the fact that static actual parameters aren't
static inside a generic unit. He, of course, is making the fundamental
assumption that generics are just an include file -- which is certainly not
true in Ada. The "contract model" of generics (which insures that you can
reason about the code in a generic without knowing anything other than the
declaration of the generic) is considered an important part of the model.
Moreover, it allows sharing of generic implementations, which can greatly
reduce the size of programs.

Such static actual parameters are actually static if referenced from the
instantiation. That was true in Ada 83, and it is true in Ada 95. But lots
of compilers have bugs in this area. So perhaps the OP is blaming the
language for buggy compilers? (The standard wording itself also has bugs in
this area; it doesn't match the ACATS, and it is agreed that the ACATS is
correct, since the current wording is incompatible with Ada 83. There are no
compilers tested under the ACATS that have requested a variance on these
tests, so I can safely assume that compilers implement the Ada 83 rule.)

> >         (b) Constraint_error is raised by assuming
> >         a fictitious overflow when a signed number
> >         is moved into an unsigned number and vice
> >         versa, instead of just putting the bits
> >         into the other field without checking anything.
>
> That's what Unchecked_Conversion is for. If you don't want the checks,
> say so. Ada gives you the power to say exactly what you want, unlike
> other languages.

Ada 200Y will have the 'Mod attribute to deal with this problem. See AI-340,
which was approved at the last meeting. The fact that Ada 95 didn't deal
with this is simply a mistake; there are going to be some in 500+ pages of
Standard.

Note again that the OPs contention that "people at the highest levels"
(whatever that means) don't understand these issues is obviously false --
otherwise, there wouldn't already be a solution in place.

Also note that implementers are encouraged to add these features to their
compilers as soon as they want to; several implementers (based on public
statements) are actively adding Ada 200Y features right now. You won't have
to wait many years to get some of them.

...
> > It's now happening yet, but it could still happen,
> > because Ada is still the best design language,
> > the least buggy way to code, and the easiest language
> > in which to conceive bug free implementations
> > out of all strongly-typed languages.
>
> Ah, good. We get to end with an agreement :).

Yes. :-)

The OP seems to be another person who would rather complain rather than
help. There is some much activity - the ARG (and Ada-Comment), SIGAda,
various free software efforts, etc. Get involved! If the OP did, he'd find
that the people there aren't really any different than himself. And, Ada can
always use more help.

                 Randy Brukardt