Re: Ada 9X objectives

[billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )]

From ryer@inmet.inmet.com:
> [Cost of an Ada class/inheritance system: $500K/compiler]
> [...] I see the Ada 9X contents issue
> as being primarily one of economics, not cultural inertia.  I would be
> quite interested in comments about how the "won't-use-it-unless-its-
> good-and-it-won't-get-good-unless-you-use-it" stalemate can be broken.

   My article was not necessarily about inheritance in particular, but
   rather about the need to make Ada a function of software engineering
   technology as of each revision point.  Beyond that, I'd just like to 
   note that in general, the longer a necessary change is delayed, the 
   more painful it becomes.  Furthermore, if Ada ever becomes decoupled
   from major advances in software engineering technology, then Ada will 
   have no future.  IMHO, Ada must either grow now or die in the nursery. 

   To further stimulate this discussion, I'm reposting below a recent
   article from comp.sw.components, where a similar discussion has been
   recently taking place.  I believe Mr. Crawley's views are shared by 
   a large number of people outside of the Ada community.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

-------------------------------------------------------------------------
From scc@cl.cam.ac.uk (Stephen Crawley)
Newsgroups: comp.sw.components
Subject: Are "production" programming languages dinosaurs?

Bill Wolfe writes:
> Ada is the result of a language ENGINEERING process.  There was
> a deliberate decision that the definition of the language would
> be held stable for ten years at a time.  This permits certain
> economic assumptions to be made, which was judged to be more
> important than satisfying those who think that new versions of
> a language should be generated every six months.  This is a
> PRODUCTION language, not a RESEARCH language.  It offers a lot
> of advantages (portability, compiler validation, infrastructure)
> not present with other languages, in addition to a very high level
> of support for good software engineering practices. 

Well how come ADA seems to be largely irrelevant outside of the defense
sector?  

ADA 83 was 5 - 10 years out of date even before it was finalised.  Unless 
it gets a RADICAL overhaul, ADA 9x will be 10 - 15 years out of date.
Doubtless, the reasctionaries and religious zealots from the software 
engineering industry will make sure that much of the important work done 
by researchers over the last 15 years (like GC technology, functional
programming, designing languages to make formal verification possible) 
will be ignored ... just like they did for ADA 83.

> We are nearing the end of the ten-year period of definitional
> stability, and obviously this is when the number of new ideas
> which have not yet been incorporated is at its largest.  

Sadly ADA 83 isn't anywhere nearing the end of its life ... even for
writing new software.  It would be very optimistic to expect ADA 9x 
software development environments to be available before 1995, which  
puts ADA 83 only 1/2 way through its life.  And even that is ignoring 
the inertia inherent in the software development process.  I can't see
many project managers leaping to ADA 9x half way through a large project.

--

Production language design should be an on-going evolutionary process.
The language design should reviewed regularly to incorporate new proven
ideas from research languages and the results of experience from the
production language itself.  A new language version every 2 years sounds
about right to me. 

Production language designers should also avoid the pitfall of excessively
compromising the language design for backwards compatibility.  Outdated 
ideas and language constructs should be phased out as quickly as possible.

What about all the software in old versions of the language?  Who does 
the job of converting it I hear you ask?  It should be the task of the 
people who build programming support environments to write conversion 
tools to largely automate the task of converting code from one version 
of the PL to the next one.

Maybe these ideas are not workable right now ... production programming
support environments aren't really up to the task yet.  But this is the 
direction the Software Engineering industry should be aiming.  The process
of change in computing is inevitable; we should be going with the flow
not trying to hold back the tide.

-- Steve