Re: Open Systems closed to Ada?

[seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman)]

In article <1992Dec7.215946.18972@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (
fred j mccall 575-3539) writes:
>
[stuff deleted all over the place]

>>No, I'd rather they form a higher order language group full of people from
>>the technical community, review the languages in use to see if there's one
>>good enough for what they want, and go on from there.
>
>>Sure I've heard that somewhere before...
>
>Ah, but there's a bit of difference between doing that periodically
>and selecting the best tool for the job and going off to design your
>own and then 'freezing' the state of the art and never looking again
>(or only looking every dozen years or so).
>
Let's set out a few facts. The Ada standard was adopted in 1983 as an
ANSI standard. Following ANSI rules, the standard revisiting process
was begun in 1988, five years after adoption. That the revision seems to
be taking so long is a commentary on the social process of creating a
standard in the usual way, i.e. by a committee of many people - users,
vendors, Uncle Sam - each with their own agenda.

Consider the following other standards:

  ANSI C was adopted in (I think) 1990; the language was first published
  in 1975. It took 15 years to agree on a standard.

  Fortran 90 (!) was adopted only in 1992. The previous standard was
  Fortran 77, so the process started in 1982. So it took ten years.
  The standard prior to Fortran 77 was Fortran 66, 11 years before.

  ANSI Pascal was adopted in 1983; Pascal was first published in 1971,
  12 years before. Moreover, ANSI Pascal and ISO Pascal are slightly
  different (conformant array parameters are the only difference -
  ISO has 'em; the US faction didn't want 'em). So after laboring
  mightily, the Pascal work brought forth TWO mice. Ever look at the
  Pascal standard? Not worth the effort, if you ask me. MUCH too minimal,
  which only perpetuated the Pascal "feature wars." Ever try porting a
  Turbo Pascal program to Microsoft Pascal? They are DIFFERENT
  languages.

What's the point? The Ada9X project is doing NOTHING but following the
traditional ANSI process. If X=3 or X=4, as is likely, the revision
will set a new record for expeditiousness. Building a standard
after the fact, when everyone has vested interests ranging from
serious desire for change to strong desire for no change, is simply
not easy. C, Fortran, and Pascal are ample evidence of the social 
problems. (Cobol's even better, but I've lost track of that process.)

Ada83 was frozen, and 1815-A enforced with a mighty hand, because DoD was
simply not about to keep working with constantly moving targets. And,
by the way, the ISO standard is the same as the ANSI one. So there is a
single worldwide standard. This is bad?

The copyright and trademark lapsed in 1988. People who complained about
DoD not allowing experimentation could EASILY have done as they wished
from 1988 on. Validation is required ONLY for DoD contract compilers;
there is no reason why Ada-like supersets could not have been built
and marketed after 1988, to the rest of the world. I am constantly
amazed at the number of people who don't even know that Ada has not
been a trademark for 4 years. People who beef about features they'd
like in Ada could simply have gotten together and produced a compiler
that implemented their wish list.

Ada9X will not even be a MIL standard, if I understand correctly. It
will simply be an ANSI standard like all the others. Presumably DoD
will freeze it for their own work - why shouldn't they? For the rest
of us, the sky is the limit, just as it is for all the other languages.
Grab GNAT when it comes out, add features to your heart's delight,
experiment, run it up the flagpole and see who salutes.

C++ is reasonably common across compilers, but not as much so as Ada,
although I am told it's catching up. When will we see a C++ standard?
If your answer is "over my dead body - who wants it to stagnate?"
then you are precisely missing the point about why DoD wants a 
language standard. One man's stagnation is another man's stability.

I hear lots of sob stories from teachers and students of C++ whose
code will compile under g++ but not under Turbo, and vice versa.
And NOT because the class libraries are different (which they are),
but because the languages differ just enough to cause madness.
This is good? It's 1992, folks. How long will we fight the feature wars?

Well, it's deja vu again. This is another round of the ancient debate
between free choice and predestination. The nice thing about standards
is that they achieve stability. The rotten thing about standards is
that they achieve stability. Take your choice.

IMHO, DoD is doing the right thing by opting for a strong and enforceable
standard. Shooting at a moving target is no fun. I don't often defend
Defense, but dammit, I think they are right on target here. Contractors
who want to experiment with a moving state of the art with MY tax money
are just outta luck.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans want the fruits of patience -- and they want them now."
------------------------------------------------------------------------