Re: Open Systems closed to Ada?

[agate!spool.mu.edu!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mkso l!mccall@ucbvax.Berkeley.EDU (fred j mccall 575-3539)]

In <1992Dec9.052624.23020@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman)
 writes:

>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.

Facts are always good, but I'm not sure what your point is.

>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.

Yes, but no one is 'mandating' that I must freeze technology and use
ANSI C if I have something that will do the job better.

>  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.

Yes, and FORTRAN 90 (originally intended to be FORTRAN 88) was a
pretty contentious thing.  Once again, so what?  No one is 'mandating'
that I must freeze technology and use FORTRAN 90 if I have something
that will do the job better.

>  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.

I'm aware.  However, once again, no one is 'mandating' that I must
freeze technology and use ANSI-standard Pascal if I have something
that will do the job better.

>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.)

Yes, but there is an 'Ada Mandate' that basically forces people to
freeze technology in between standard revisions.  Where are the 'C
Mandate', the 'FORTRAN Mandate', or the 'Pascal Mandate' which would
force me to freeze technology?

>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?

It's bad if there's a 'mandate' requiring the freezing of technology
for eleven years.

>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. 

Yes, but you can't USE the results of that 'experimenation' for
anything.  'Ada Mandate', you know.

>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. 

Yes, but why would they?  The biggest market was and is for Defense
stuff.  Why expend the effort to make something that most people using
the language simply couldn't use?

>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.

Well I knew that.  Yes, people could have done that, but why?  You
couldn't use such a compiler for anything.  First there has to be a
market for it.

>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.

This may actually be the first real step for Ada.  Most babies walk
when they're a bit younger, but it's never too late.  

>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.

The problem isn't "having a standard"; the problem is "having a
Mandate".  It's the Mandate that puts the incentive to stagnate in
(because it closes the main market for improvements).

>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, there's also the problem that the hardware and operating systems
are radically different, but hey, let's ignore that.  The problem is
that people are writing non-portable code, not that the language
allows you to do it.

>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.

No, the nice thing about standards is that you can pick the ones you
like; there are so many of them, and all conflicting.  :-)

Anyway, the problem isn't with standards -- the problem is with
Mandates. 

>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.

Can we actually document any savings, or are we still working on
guesswork and theory in this area?  Anyway, wouldn't it make more
sense to freeze on a per-contract basis rather than to Mandate frozen
technology for a dozen years at a time?

-- 
"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.