Re: Ada 9X objectives

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

  In an earlier comp.lang.ada article I included a copy of a recent 
  article from Stephen Crawley in comp.sw.components.  I'd like to 
  comment here on some of the points raised. 

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

  That depends strongly on your definition of "largely irrelevant";
  there is a large and growing number of non-defense projects and 
  companies using Ada.  The new generation of highly optimizing 
  Ada compilers deserves at least some of the credit for this 
  substantial and accelerating growth.

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

  In fact, this is not correct.  Ada 83 explicitly provides for garbage
  collection as an optional compiler service.  The rule that functions
  must not modify their parameters was probably a direct result of
  functional programming ideas.  Finally, formal verification is a
  major goal of the software engineering community, and Ada was designed
  to support it to as great an extent as possible.  For example, the
  use of the termination model of exception handling was (at least in
  part) motivated by formal verification considerations. 

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

  This is too frequent; five years might be reasonable, but not two.
  I don't think the compiler validation suites, etc., would be able to
  respond meaningfully to a revision cycle which was THAT frequent.
 
> 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.

  The US Government is actively planning to maximize the use of
  automatic translation technology during the transition from Ada
  83 to Ada 9X.  

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

  On this I agree.  But another good reason to only revise no more 
  quickly than five years at a time is to give new ideas a chance to 
  mature.  Once a new idea has proven itself, and has become reasonably
  agreed upon to be a good thing that production languages should have,
  there should be a process by which production languages incorporate
  new developments in software engineering technology, and this is what
  should be accomplished by the Ada 9X scheduled revision process.


  Bill Wolfe, wtwolfe@hubcap.clemson.edu