Ada 9X objectives

Ada 9X objectives

[Bill Wolfe]

   Ada is now entering the revision process, and much has transpired
   over the last ten years.  Many ideas have emerged, both from inside
   the Ada community (e.g., Hilfinger's ideas to the effect that literal 
   recognition should not be limited to the predefined types, but should
   in fact be definable for user-defined abstract data types as well),
   and from outside the Ada community (notably multiple inheritance).  

   When Ada was first designed, the objective was to provide the maximum
   possible support for good software engineering practices, given what
   was then known about programming language technology.  Unfortunately,
   compiler maturity is just now reaching levels which make the language
   attractive as a production tool, and in the meantime the continuing
   advancement in the theory and practice of programming language design
   have made the delay very costly to Ada's prospects for widespread
   acceptance.  

   Moreover, some persons who have been in a position to observe the
   Ada community seem to be of the opinion that for a significant
   number of members of the Ada community, Ada 83 has become an end
   rather than a means; in their estimation, Ada will fall victim to
   the resistance to change which seems to plague virtually all human
   endeavors.  They cite the recently expressed view that inheritance
   would result in too great a setback for Ada compiler maturity as
   an example, saying that inheritance has already been proven to be
   efficiently implementable and that this is merely a smoke screen
   for resistance to new concepts.  

   Therefore, I would like to pose this question to the Ada community:
   what are the basic objectives of Ada 9X?  Specifically, is Ada going
   to be something that is tied to the idea of maximum support for the
   practice of software engineering?  Is the DoD *really* committed to
   making Ada the primary vehicle of software engineering technology?
   If so, what is being done to close the gap between the dream of 
   widespread Ada use and the reality of the widespread use of COBOL,
   C, C++, and Eiffel instead?  

   I do not mean to imply that tremendous progress has not been made;
   as John Foreman (I believe) recently noted, Ada is much farther along
   than COBOL was at a similar point in its existence.  However, it is
   extremely frustrating to see people choosing C++ and Eiffel instead
   of Ada because of this ten-year revision cycle (and perhaps a bad bet
   that inheritance would not turn out to have a bright future).  It is
   extremely frustrating to see employment advertisements calling for
   knowledge of the likes of C or COBOL, with nary an Ada advertisement
   in sight.  But the worst of all is listening to people assert that
   Ada is obsolescent and will never be able to catch up. 

   As a software engineer, I strongly believe in the Ada dream.  But
   there have been big problems associated with realizing that dream.

   An explicit linkage of Ada 9X to maximum support for the software 
   engineering process, combined with a shortened five-year revision 
   cycle, would go a VERY long way toward making that dream a reality. 
    

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada 9X objectives

[ryer]

RE:
/* Written  9:59 pm  Sep 28, 1989 by wtwolfe@hubcap.UUCP in inmet:comp.lang.ada */
/* ---------- "Ada 9X objectives" ---------- */
>  ... (notably multiple inheritance).  
>  ... Unfortunately,
>  compiler maturity is just now reaching levels which make the language
>  attractive as a production tool, and in the meantime the continuing
>  advancement in the theory and practice of programming language design
>  have made the delay very costly to Ada's prospects for widespread
>  acceptance.  
>  ... They cite the recently expressed view that inheritance
>  would result in too great a setback for Ada compiler maturity as
>  an example, saying that inheritance has already been proven to be
>  efficiently implementable and that this is merely a smoke screen
>  for resistance to new concepts.  
>  Bill Wolfe, wtwolfe@hubcap.clemson.edu
/* End of text from inmet:comp.lang.ada */

If it costs $500k each to add a high quality multiple-inheritance type
system to Ada compilers, and there are 15 separate baselines (FE's),
then the cost of the feature (at high quality) is $7.5M.  Will enough
C++ and Eiffel users go out and buy one to cover the investment?  Should
the DOD:

   A.  Require a full class/inheritance/etc system in Ada 9X AND prohibit
       the use of Eiffel, C++, Simula, etc. in RESEARCH as well as
       in major production programs in order to force an adequate market to 
       be created?

or

   B.  Put in Ada 9X only what the current market is large enough to
       pay for?

or
  
   C.  Put in multiple inheritance and let the quality and availability
       of compilers settle wherever it may?

or

   D.  <fill in the blank>


Please don't take this note as a flame:  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.

I'm hoping the 9X Requirements Team will ask for "enough building blocks
so you can do object oriented programming reasonably well without
revising the entire type system".  

Mike Ryer
(working, but not speaking, for Intermetrics (an Ada, C, and other
language compiler vendor, applications developer, and contract
research company, which believes in using the best available software
engineering technology as much as anyone, but is also a for-profit business.))

Re: Ada 9X objectives

[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

Re: Ada 9X objectives

[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
 

Translating 83 => 9X (Was: Re: Ada 9X objectives)

[Ronald Guilmette]

In article <6661@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>
>  The US Government is actively planning to maximize the use of
>  automatic translation technology during the transition from Ada
>  83 to Ada 9X.  
>

Holy smokes!!!!  Is it just me folks, or does the statement above imply that 
(a) Ada 9X has already been designed, and (b) it *does not*  provide upward
compatibility for Ada 83 programs?

Obviously, just following this newsgroup is not enough to keep ones self
"in the know" regarding the current state of the Ada 9X deliberations!

Somebody please reduce my ignorance level and tell me what parts of Ada 83
have already been declared to be obsolete.  Tasking?  Fixed-point?
Could somebody maybe post a list?

// rfg

Re: Translating 83 => 9X (Was: Re: Ada 9X objectives)

[William Thomas Wolfe, 2847]

From rfg@ics.uci.edu (Ronald Guilmette):
>>  The US Government is actively planning to maximize the use of
>>  automatic translation technology during the transition from Ada
>>  83 to Ada 9X.  
> 
> Holy smokes!!!!  Is it just me folks, or does the statement above imply that 
> (a) Ada 9X has already been designed, and (b) it *does not*  provide upward
> compatibility for Ada 83 programs?

   It means only what it says: whatever 9X's final form, the use 
   of automatic translation technology will probably be maximized.
   This probably will take the form of an automatic translator being
   built to Government specs and placed in the Ada Software Repository.

   I would think that there would be enough similarity to make the
   use of automatic translation reasonable; this technology has
   proven not to be exceptionally useful where remarkably dissimilar
   languages are involved, such as in a Fortran-to-Ada conversion. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Translating 83 => 9X (Was: Re: Ada 9X objectives)

[Ronald Guilmette]

In article <6667@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>> 
>> Holy smokes!!!!  Is it just me folks, or does the statement above imply that 
>> (a) Ada 9X has already been designed, and (b) it *does not*  provide upward
>> compatibility for Ada 83 programs?
>
>   It means only what it says: whatever 9X's final form, the use 
>   of automatic translation technology will probably be maximized.
>   This probably will take the form of an automatic translator being
>   built to Government specs and placed in the Ada Software Repository.
>
>   I would think that there would be enough similarity to make the
>   use of automatic translation reasonable; ...

I think that you missed my point entirely.

I have to assume that there is a large base of Ada 83 users out there who
hope and pray that "the use of automatic translation" would *not* be
"reasonable", but would instead be TOTALLY UNNECESSARY when moving to Ada 9X.

I will ask one more time and hope for a more direct answer.  Has it already
been decided that Ada 83 and Ada 9X will be sufficiently incompatible so
as to *require* translation?  (Hint: this is a yes-or-no question.)

If the answer is no, then why is the government planning on building/using
a translator (or translators) when the need for such tools & processes is
not yet even established?  Has Samuel Pierce moved over to DoD from HUD, or
is this just the 1990's version of the $600 screwdriver?

If the answer is yes, then it *must* logically follow that *somebody*
knows what the incompatibilities are.  Otherwise, how could anyone know
that automatic translation will be required (or even useful).
If so, that person (or persons) are doing a disservice to the Ada
community by not comming forward to warn Ada 83 users about features to
avoid from now on.  Could it perhaps be the case that the individuals who
know what the incompatibilities are (ahem, I mean what they "will be") are
keeping it to themselves in the hope of later capitalizing on this "insider
information"?

Either way, something here smells like three-day-old fish.

// rfg

Re: Translating 83 => 9X (Was: Re: Ada 9X objectives)

[William Thomas Wolfe, 2847]

From rfg@ics.uci.edu (Ronald Guilmette):
> I will ask one more time and hope for a more direct answer.  Has it already
> been decided that Ada 83 and Ada 9X will be sufficiently incompatible so
> as to *require* translation?  (Hint: this is a yes-or-no question.)

   I do not know as a fact that this is the case, but I do recall
   reading about plans for automatic 83 => 9X translation.  Perhaps
   someone having more direct knowledge of the situation could comment
   in greater detail.

   I would expect that there *would* be sufficient incompatibility, 
   just on the basis of the experiences with Ada 83 which have been
   documented in Ada Letters, etc., which indicate that certain changes
   are necessary.  I would also expect that if a free 83 => 9X translator
   is provided via the Ada Software Repository, the conversion process
   would be dominated by the time required to upgrade programmers, rather 
   than the time required to automatically upgrade existing Ada 83 software. 

   If you want to get a good idea of what the likely changes will be:

      o ACM SIGADA Ada Letters for the last 5 years or so
      o Ada 9X revision requests 
      o proceedings of Tri-Ada and other conferences 
      o the last chapter of Paul Hilfinger's ACM Distinguished
          Dissertation, "Abstraction Mechanisms and Language Design"

   are all excellent sources.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Translating 83 => 9X (Was: Re: Ada 9X objectives)

[John Goodenough]

In article Re: Translating 83 => 9X (Was: Re: Ada 9X objectives) of 5 Oct 89
01:56:29 GMT billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:

>   If you want to get a good idea of what the likely changes will be:
                                               ^^^^^^
>      o ACM SIGADA Ada Letters for the last 5 years or so
>      o Ada 9X revision requests 
>      o proceedings of Tri-Ada and other conferences 
>      o the last chapter of Paul Hilfinger's ACM Distinguished
>          Dissertation, "Abstraction Mechanisms and Language Design"
>
>   are all excellent sources.

These sources BY NO MEANS specify the _likely_ changes in Ada 9X.  These are
sources of suggestions being made, but no one yet knows what the likely
changes might be, because the change requests have not yet been analyzed
against the stated goals of the 9X process, which are:

    "to revise ANSI/MIL-STD-1815A to reflect current essential requirements
    with minimum negative impact and maximum positive impact to the Ada
    community.  The Ada 9X process is a revision and not a redesign of the
    language and should be viewed as a natural part of the language maturation
    process."  [From the Ada 9X Project Plan, January 1989]

In my opinion, this means the goal is to improve the usability of Ada, and
this means fixing problems while not destabilizing the adoption process or the
quality of Ada implementations.  How this can be done will be the subject of
much discussion in the next few years, but major and widespread
incompatibilities certainly are not consistent with the stated goals.

It is certainly premature to suggest that some kind of automatic translator
will be required.  In fact, I think most people involved with the effort would
be appalled if something called an "automatic translator" from Ada 83 to Ada
9X was required.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

-- 
John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Ada 9X objectives

[William Thomas Wolfe, 2847]

From jbg@sei.cmu.edu (John Goodenough):
> no one yet knows what the likely changes might be, because the change 
> requests have not yet been analyzed against the stated goals of the 
> 9X process...

   I would tend to rather strongly doubt that any significant number 
   of the change requests appearing in the places I described will be 
   in conflict with the stated goals of 9X.

>     "to revise ANSI/MIL-STD-1815A to reflect current essential requirements
>     with minimum negative impact and maximum positive impact to the Ada
>     community.  The Ada 9X process is a revision and not a redesign of the
>     language and should be viewed as a natural part of the language maturation
>     process."  [From the Ada 9X Project Plan, January 1989]
> 
> In my opinion, this means the goal is to improve the usability of Ada, and
> this means fixing problems while not destabilizing the adoption process or the
> quality of Ada implementations.  How this can be done will be the subject of
> much discussion in the next few years, but major and widespread
> incompatibilities certainly are not consistent with the stated goals.

    Major and widespread incompatibilities which do not offer strong
    advantages would not be consistent, but where a strong advantage
    is to be gained (e.g., the ability to apply a high-powered multiple
    inheritance system), the magnitude of the positive impact would
    certainly overcome the possibility that an automatic translator
    might be required.  This is completely consistent with the 
    language maturation process, and corresponds directly to the 
    continuing maturation of the software engineering process. 

    My contention is that if 9X does not track the state of the art
    with respect to the software engineering process, then the adoption
    process will be "destabilized" completely, since more modern languages
    which provide better support for the software engineering process
    will be used instead.  THAT is inconsistent with Ada 9X objectives. 

> It is certainly premature to suggest that some kind of automatic 
> translator will be required.  In fact, I think most people involved 
> with the effort would be appalled if something called an "automatic 
> translator" from Ada 83 to Ada 9X was required.

    What I am suggesting is that it would be an extremely good idea to
    assume that this will be the case.  If not, fine; but given the amount
    of evolution which has occurred with respect to the language capabilities
    needed in order to provide support for the modern software engineering 
    process, I would certainly consider it a good idea to be prepared to use 
    an automatic 83 => 9X translator as part of the conversion. 
     

    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Translating 83 => 9X (Was: Re: Ada 9X objectives)

[Ronald Guilmette]

In article <6678@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>
>   I do not know as a fact that this is the case, but I do recall
>   reading about plans for automatic 83 => 9X translation.  Perhaps
>   someone having more direct knowledge of the situation could comment
>   in greater detail.

If you can find the reference, I'm sure that many here would be interested
to read that same publication.

// rfg

Re: Translating 83 => 9X

[William Thomas Wolfe, 2847]

From rfg@ics.uci.edu (Ronald Guilmette):
>>   I do not know as a fact that this is the case, but I do recall
>>   reading about plans for automatic 83 => 9X translation.  Perhaps
>>   someone having more direct knowledge of the situation could comment
>>   in greater detail.
> 
> If you can find the reference, I'm sure that many here would be interested
> to read that same publication.

   Unfortunately, at the time I considered it an interesting tidbit of
   information, but did not anticipate ever having to cite it.  At any
   rate, we must also realize that translation is only one of the two 
   major avenues of transition; the other is to exploit Ada's ability
   to call code written in other languages.  If the manufacturers of 
   Ada 83 compilers decided to sell an upgrade which would permit the
   use of pragma Interface to Ada 9X, and the 9X compilers also had the
   ability to interface to Ada 83, then the primary purpose of automatic
   translation would be to enable the use of the more powerful Ada 9X 
   by the system's maintainers.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Translating 83 => 9X (Was: Re:

[ryer]

RE:  Ada 83/9X Compatibility

Right now there is a "Requirements Team" working out of IDA including
some government and some industry people.  They are analyzing the
change requests that have been submitted, the results of various
public workshops, the history of waivers granted by DOD to not use
Ada, etc, and will come out with a set of *requirements* for new
Ada.  For example, they may and may not make the statement "Full
support for object-oriented programming, at least at the functionality
level of C++ must be added".  They are not expected to say do
(or do not) add "classes" as a new type, or change type derivation
as follows.

There is a contract to be competed this winter called the Mapping/Revision
contract.  The winner will take the 9X *requirements* and design a
language (set of language changes) to meet them.  As far as I know,
"upward compatibility" has not been established as a firm requirement
for that contract, but no competent language designer is going to
make incompatible changes without an excellent reason and a lot
of squirming around to avoid it.

It wouldn't surprise me if someone is already building an automatic
translator.  It is a time-honored custom to begin implementing
the solution before the requirements have been defined.  Is the
translator to be old Ada to new (perhaps it deduces and inserts
classes to make programs better), or new Ada to old (to take
advantage of un-upgraded compilers)?

Mike Ryer
Intermetrics

Re: Translating 83 => 9X (Was: Re:

[stt]

Here is the wording from the Ada9x project plan:

A revision requirement that does not meet the "upward compatibility"
criteria will only be considered if it affects a very large
portion of the Ada community and its absence in the
revised standard has a serious negative impact on application development.

-- Ada 9X Project Requirements Development Plan, August 89,
-- footnote on page 2 (and 3).

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: Modernizing Ada

[William Thomas Wolfe, 2847]

From article <20600009@inmet>, by stt@inmet:
> Here is the wording from the Ada9x project plan:
>  A revision requirement that does not meet the "upward compatibility"
>  criteria will only be considered if it affects a very large
>  portion of the Ada community and its absence in the
>  revised standard has a serious negative impact on application development.

  Multiple inheritance, for example, meets both criteria and therefore 
  should be considered regardless of whether or not upward compatibility 
  is affected.  Every effort must be made to minimize the difficulty of 
  the transition, but not at the expense of capabilities which are vital 
  to the modernization of our software engineering technology. 

  Saving money on software development is the fundamental motivation
  behind software engineering, and the fundamental motivation behind
  Ada itself.  If a situation arises in which commercial organizations
  can use a language which is up-to-date and thereby produce Government
  software systems at a lower cost than can be achieved by those using
  a hypothetical 9X which failed to track advancements in software 
  engineering technology, then Ada will have FAILED in its mission.

  The consequence of this would be that the entire Ada organization 
  would be scrapped.  Critics of government would gleefully claim that
  Ada was yet another example of how anything the government touches
  becomes inefficient, obsolescent, and doomed to failure.  

  Are they right? 


  Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re^2: Ada 9X objectives

[James E. Cardow]

I have to agree with Mr Wolfe, a two year update cycle would cause havoc
with the language and the organizations attempting to support the software
already developed or nearing the end of development.  The support organizations
for large, real-time software systems (the original target of Ada) would like 
nothing more than to have the latest and greatest improvements in their 
software and support tools.  The problem is, minor changes cause major problems.Consider the ten to twenty year development cycle for large projects.  Compiler vendors (not to mention) compilers enter and exit the market over that period.
The software and the compiler must then be supported by someone else.

The ten year span is most likely too long.  The additional time to effectively 
propagate the change and maneuver through the bureaucracy stretches the time to
closer to 15 years.  With that time frame, too many technically sound
improvements are ignored.  Those of us is support painfully realize the
difference 15 years of technology change make.

As far as what changes should be considered, the first step should be an 
evaluation of the features of "research" languages.  The very features that
make them attractive are probably the most desired in changes to other
languages. Inheritance as handled by C++ would certainly seem to be a prime
candidate.  There is usually a reason why those features make the language
 attractive, not considering and incorporating them is foolish.

Changes to Ada 83 are needed.  The change frequency should be reevaluated.
The healthy discussion over which change to include is outstanding.  Too bad
the support community is not making a greater input, they will live with the
results long after the developers move on to newer ideas.

Re: Re^2: Ada 9X objectives

[Ted Dunning]

In article <1373@blackbird.afit.af.mil> jcardow@blackbird.afit.af.mil (James E. Cardow) writes:

	...

   As far as what changes should be considered, the first step should be an 
   evaluation of the features of "research" languages.  The very features that
   make them attractive are probably the most desired in changes to other
   languages. Inheritance as handled by C++ would certainly seem to be a prime
   candidate.  There is usually a reason why those features make the language
    attractive, not considering and incorporating them is foolish.


how do you add the primary feature of scheme which is parsimony to ada
whose salient characteristic is obesity?

in the formal semantics of scheme, the abstract syntax of scheme is
_6_ lines long.  and yet this language has considerably _more_ power
than ada in many respects.

how do you ADD this to ada which doesn't even yet have a formal
semantics?

--
ted@nmsu.edu
			remember, when extensions and subsets are outlawed,
			only outlaws will have extensions or subsets

Re: Ada vs. Scheme

[William Thomas Wolfe, 2847]

From ted@nmsu.edu (Ted Dunning):
> in the formal semantics of scheme, the abstract syntax of scheme is
> _6_ lines long.  and yet this language has considerably _more_ power
> than ada in many respects.

   A Turing machine has an extremely simple set of commands, 
   but this does not make its command set a useful programming
   language.  The original Lisp was also quite powerful, but
   the lack of type-checking made it less than useful as a
   practical tool.  Ada is intended to be a superb *production*
   programming language; I seriously doubt that Scheme was 
   designed with that particular objective in mind.

   Followups to comp.lang.misc...
 

   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Re^2: Ada 9X objectives

[Norman Diamond]

In article <TED.89Oct4142437@aigyptos.nmsu.edu> ted@nmsu.edu (Ted Dunning) writes:

>			remember, when extensions and subsets are outlawed,
>			only outlaws will have extensions or subsets

Correction, only outlaws will BE extensions or subsets.

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.

Re: Re^2: Ada 9X objectives

[Robert Munck]

I think that many of the participants in this discussion thread are
missing an important point:  the Ada effort is NOT primarily concerned
with the state of the art in programming languages, but rather that
of large-scale software engineering.

These are two very different things, and it is to be expected that the
programming language chosen would be different.  For example, language
stability is an important characteristic of this kind of s/w engineering;
the 10-year language upgrade period is on the same order of magnitude
(or even a bit low) as the time required for a big software project,
either DOD or commercial.  Ada is intended to reduce life-cycle costs,
and changing the language every few years would have a large negative
effect on that.

What we have here is a failure of communication between research and
practicality.  Universities and commercial research centers have very
little chance for experience in software projects that require hundreds
of programmer-years with large geographic and temporal distributions.
It is quite irrelevant to proclaim the powers of brand-new languages
until they have been used successfully in such large projects.  Has
there been a C++ development of 500,000 lines or more that has become
a product in some sense and has been widely used?  One that has been
developed by a prime/sub-contractors arrangement of a half-dozen
companies and passed on to another such group for maintenance?  Well,
Ada can't claim many such either, but it was designed for that
kind of situation.

I'd suggest that language theorists commenting on Ada first consider
the extent of their own experience with "real-world," large-scale
programming projects.  Ada can certainly be discussed as a language
independent of such concerns, but the entire DoD Ada effort can not.
                 -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP
                 -- MS Z676, MITRE Corporation, McLean, VA 22120
                 -- 703/883-6688

Re: Ada 9X objectives

[William Thomas Wolfe, 2847]

From munck@chance.uucp (Robert Munck):
> I think that many of the participants in this discussion thread are
> missing an important point:  the Ada effort is NOT primarily concerned
> with the state of the art in programming languages, but rather that
> of large-scale software engineering.

   I think otherwise: the effort is not to link Ada with the state
   of the art in programming languages, but to link Ada with the
   state of the art in software engineering.
                       ^^^^^^^^^^^^^^^^^^^^ 
> These are two very different things, and it is to be expected that the
> programming language chosen would be different.  For example, language
> stability is an important characteristic of this kind of s/w engineering;
> the 10-year language upgrade period is on the same order of magnitude
> (or even a bit low) as the time required for a big software project,
> either DOD or commercial.  Ada is intended to reduce life-cycle costs,
> and changing the language every few years would have a large negative
> effect on that.

   I see no reason why lengthy projects have to switch languages in
   mid-stream UNLESS they think it will help them out.  Of course,
   given the existence of automatic translation facilities and the
   ability to exploit pragma Interface in both directions, this may
   in fact be the case. 
 
> What we have here is a failure of communication between research and
> practicality.  Universities and commercial research centers have very
> little chance for experience in software projects that require hundreds
> of programmer-years with large geographic and temporal distributions.
> It is quite irrelevant to proclaim the powers of brand-new languages
> until they have been used successfully in such large projects.  Has
> Has there been a C++ development of 500,000 lines or more that has 
> become a product in some sense and has been widely used?  One that 
> has been developed by a prime/sub-contractors arrangement of a half-dozen
> companies and passed on to another such group for maintenance?  Well,
> Ada can't claim many such either, but it was designed for that
> kind of situation.

   The prime/subcontractor arrangement exists only in the realm of
   government contracting, and hence it would be unrealistic to expect
   an exact parallel in the commercial realm.  However, there appears
   to be a substantial amount of C++ activity in industry, and some
   large products *have* been produced.  I'm not sure of the exact 
   line counts, but a quick query to comp.lang.c++ would undoubtedly 
   produce all the statistics you can eat.

   There are a lot of negative things in C++, and a lot of the good
   stuff in Ada is not available in that language.  The only two real
   advantages C++ can cite are: easy transition for C programmers, and
   multiple inheritance.  The first is not something we SHOULD worry
   about; we don't need to provide C programmers with the ability to
   do all their favorite hacks.  The second is a real problem, because
   the use of multiple inheritance is an important software engineering
   mechanism.  It reduces the amount of code that must be written, and
   increases the speed with which products can be produced.  

   By incorporating this mechanism into Ada, the sole argument for C++
   becomes the unwillingness of C/C++ programmers to give up their
   hacking ways, and this is a problem we can successfully address.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Ada 9X objectives

[Robert Munck]

In a previous article, I said:
> ...  the Ada effort is NOT primarily concerned
> with the state of the art in programming languages, but rather that
> of large-scale software engineering.
>
And in article <6699@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu replied:
>
>   I think otherwise: the effort is not to link Ada with the state
>   of the art in programming languages, but to link Ada with the
>   state of the art in software engineering.
>                       ^^^^^^^^^^^^^^^^^^^^ 



Does anyone else get the feeling that he's not LISTENING?  It must be wonderful
to have the leisure to reply at length to every posting, no matter what, but
the replies should be based on what was originally written.
                 -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP
                 -- MS Z676, MITRE Corporation, McLean, VA 22120
                 -- 703/883-6688

Re: Ada 9X objectives

[William Thomas Wolfe, 2847]

From article <73079@linus.UUCP>, by munck@chance.uucp (Robert Munck):
> In a previous article, I said:
>> ...  the Ada effort is NOT primarily concerned
>> with the state of the art in programming languages, but rather that
>> of large-scale software engineering.
>>
% And in article <6699@hubcap.clemson.edu> wtwolfe@hubcap.clemson.edu replied:
%>
%>   I think otherwise: the effort is not to link Ada with the state
%>   of the art in programming languages, but to link Ada with the
%>   state of the art in software engineering.
%>                       ^^^^^^^^^^^^^^^^^^^^ 
> 
> Does anyone else get the feeling that he's not LISTENING?  
> It must be wonderful to have the leisure to reply at length 
> to every posting, no matter what, but
> the replies should be based on what was originally written.

    It was.  What you originally wrote (prior to the included material)
    was words to the effect that an effort is being made to link Ada with 
    the state of the art in programming languages RATHER THAN the state of
    the art in software engineering, and this contention is what I took
    issue with.  

    I submitted instead that the idea was to determine (as was the
    case with Ada 83) what language capabilities would best support
    software engineering practice, and move from there to specific
    language constructions.  I see no basis for your contention that
    the state of the art in programming languages is being considered
    as the driving factor; what has changed is the state of the art
    in software engineering practice.  This in turn requires new
    programming language support facilities. 

    Example from Ada 83: Support shall be provided for data abstraction.

    Resulting constructs: generic packages, limited private types.

    Example for Ada 9X: Support shall be provided for object-oriented
                          software development.

    Resulting constructs: classes, a multiple inheritance mechanism  

    In each case we have a software engineering practice (data abstraction,
    object-oriented development) for which language support is required.
    Hence, it seems that the assertion that proposed changes are not 
    being driven by software engineering requirements is not correct. 
         
    Perhaps you know of a counterexample -- some proposal which is not
    related to support for software engineering practices.  If so, please
    point it out directly.  


    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada 9X objectives

[Dick Dunn]

William Wolfe writes about Ada 9X and C++

>    There are a lot of negative things in C++, and a lot of the good
>    stuff in Ada is not available in that language.  The only two real
>    advantages C++ can cite are: easy transition for C programmers, and
>    multiple inheritance...

This is a parochial view--something which is a perennial problem in the Ada
community, and which has done a lot to inhibit interest in Ada, let alone
acceptance of it.  If you want folks to move to Ada, you can't get it to
happen by just proclaiming the obvious, innate superiority of Ada and
waiting for them to arrive in droves.  You're going to have to try to
understand why they're using C (or C++ or whatever they're using).  There
are many reasons; there are reasons not to convert to Ada; there is
inertia.  The harder you try to dismiss their reasons by working from your
own viewpoints, the less credibility you have.  (The reasons may not even
be good ones!  They still have to be addressed.)

The credibility problems only get worse as you deal with more experienced
software people.  The longer people have watched and worked in software,
the more alleged panaceas they've seen, and the more sure they are that
there aren't any panaceas.  Also, it's likely that they've worked in some
truly awful languages and have produced decent software in spite of it, so
they'll doubt that the choice of programming language is as important as
you say.  Finally, they'll have been watching the progress of Ada over the
years and will have concluded that with the enormous amount of money thrown
at it, if it were truly wonderful it would have really caught on by now.

Part of what I'm saying is that you've got a marketing problem.  Even if
you have a wonderful product, you still have to sell it--you'll go broke if
you just wait for customers to find you.  And a lot of us aren't convinced
that the product is all that wonderful anyway.

[Wolfe finishing up on importance of multiple inheritance]
>    By incorporating this mechanism into Ada, the sole argument for C++
>    becomes the unwillingness of C/C++ programmers to give up their
>    hacking ways, and this is a problem we can successfully address.

This is flawed in several ways.  The first is the attitude that C/C++
programmers have "hacking ways" somehow tied to the language, and that they
can be corrected by setting them on the One True Path to Ada.  Look, this
is arrogant on the part of Ada folks and demeaning toward the C/C++ folks.
You should be able to see that this sort of attitude won't cut it, *regard-
less* of how much you like Ada or dislike C++!  The arrogant and insular
attitudes of Ada's adherents have done far more damage to the language than
the lack of any feature could do.

Also, the argument that you can just add multiple inheritance and win the
battle is based on the assumption that C++ is now static, that it's not
going to acquire any more useful features.  I suspect strongly that this is
a mistaken assumption.  You had better assume that you are aiming at a
moving target.  If you want anything approaching a contemporary programming
language, you're not going to get it by taking five years to get to where
C++ is now, and then proclaiming you're done.  The activity and adaptability
of C++ is something you're going to have to address somehow if you're going
to "compete" with it.

Beyond that, if you just add a feature to Ada, it doesn't immediately
become as useful as a feature that's existed in C++ for a while.  There's a
maturing period, during which people find the gotchas and evolve the
paradigms.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.

Question about Ada expressions

[Perry Schmidt]

In Ada, when building boolean expressions you must put ANDs and ORs (and
OR ELSES, etc) in parents IF you use them in mixed combination.

Ex.  (A and B or C) -- is not legal.  You must write it as...
     (A and (B or C))

So the question is -- WHY?

Does this remove some semantic ambiguity?  Or is it just the "Ada style!"

Thanks for any responses...

Perry Schmidt
(schmidt@green.cs.wisc.edu)

Re: Question about Ada expressions

[STEPHEN D. STRADER]

In article <8834@spool.cs.wisc.edu> schmidt@green.cs.wisc.edu (Perry Schmidt) writes:
>In Ada, when building boolean expressions you must put ANDs and ORs (and
>OR ELSES, etc) in parents IF you use them in mixed combination.
>Ex.  (A and B or C) -- is not legal.  You must write it as...
>     (A and (B or C))
>So the question is -- WHY?

BECAUSE!

No, actually it is to remove ANY ambiguity as to how the expression
should be evaluated.  

Saright?

S

Re: Question about Ada expressions

[Robert Firth]

In article <8834@spool.cs.wisc.edu> schmidt@green.cs.wisc.edu (Perry Schmidt) writes:

>In Ada, when building boolean expressions you must put ANDs and ORs (and
>OR ELSES, etc) in parents IF you use them in mixed combination.

>So the question is -- WHY?

There is no problem of semantic ambiguity, any more than with, say,
A + B*C.  The reason for the restriction is that one of the language
designers believed the relative priorities of the Boolean operators
were sufficiently unfamiliar to the general run of programmers that
expressions such as

	A and B or C

could cause confusion or, worse, be misinterpeted.

Re: Question about Ada expressions

[stt]

Ada tried to use the "conventional" precedence
rules when defining operators.  However, it has
never been entirely clear where XOR belongs relative
to AND and OR, nor how regular AND
and short-circuit AND THEN should
fare relative to one another.  The net result
was that they "punted" in this area and said
use parentheses when using two logical operators
in sequence.  

It might have been ideal in some
people's mind if at least AND had clearly higher precedence 
than OR so that your example could be coded without
parentheses, but Ada has always tried to err
on the side of readability over writability.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA

Re: Question about Ada expressions

[horst]

In article <8834@spool.cs.wisc.edu> schmidt@green.cs.wisc.edu (Perry Schmidt) writes:
>
>In Ada, when building boolean expressions you must put ANDs and ORs (and
>OR ELSES, etc) in parents IF you use them in mixed combination.
>...
>Does this remove some semantic ambiguity?  Or is it just the "Ada style!"

Yes, there is an ambiguity. The precedence of 'and' and 'or'
is not so commonly agreed as that of '*' and '+'. So the
designers chose to require parenthesis.
Regards,
 horst

Re: Ada 9X objectives

[William Thomas Wolfe, 2847]

From rcd@ico.ISC.COM (Dick Dunn):
> Part of what I'm saying is that you've got a marketing problem.  Even if
> you have a wonderful product, you still have to sell it--you'll go broke if
> you just wait for customers to find you.  

    Many of the people who are being introduced to Ada (software 
    engineering students) won't be in a position to change their 
    organizations for a few years; in some cases, it simply takes time.  

    Despite that, there are some major successes.  For example, GTE is
    doing its future telephone network system (WINS) in what is expected
    to be over 20 million lines of Ada.  We expect more.  The primary 
    limitation now (beyond inertia) is getting the bindings to things 
    like SQL, and this is the subject of a lot of activity.

    The advanced second-generation optimizing compilers, along with
    the CASE environments (e.g., TeleArcs), are also coming on line
    just recently, and their impact is just beginning to be felt.
 
> If you want anything approaching a contemporary programming language, 
> you're not going to get it by taking five years to get to where
> C++ is now, and then proclaiming you're done.  

    Of course not.  We will take five years to get to everything C++
    can do, plus many things (like multitasking and generics) it can't. 
    
> The activity and adaptability of C++ is something you're going to 
> have to address somehow if you're going to "compete" with it.

    Precisely why I advocate a shortened five-year revision cycle.

> Beyond that, if you just add a feature to Ada, it doesn't immediately
> become as useful as a feature that's existed in C++ for a while.  There's a
> maturing period, during which people find the gotchas and evolve the
> paradigms.

    There are a lot of object-oriented languages and systems, many of
    which (e.g., Trellis/Owl) are more powerful than C++.  The intent
    is to fully exploit the proof-of-concept work which has been done
    by the research languages rather than doing it ourselves.  Once the
    concept is proven and debugged (and assuming that it's an important
    advance in software engineering technology), then it's time to move 
    it into production.

   
    Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Ada 9X objectives

[Markku Sakkinen]

In article <16192@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>William Wolfe writes about Ada 9X and C++
>
>>    There are a lot of negative things in C++, [...]
>[...]
>[Wolfe finishing up on importance of multiple inheritance]
>>    By incorporating this mechanism into Ada, the sole argument for C++
>>    becomes the unwillingness of C/C++ programmers to give up their
>>    hacking ways, and this is a problem we can successfully address.
>
>This is flawed in several ways.  The first is the attitude that C/C++
>programmers have "hacking ways" somehow tied to the language, and that they
>can be corrected by setting them on the One True Path to Ada.  Look, this
>is arrogant on the part of Ada folks and demeaning toward the C/C++ folks.
>[...]
>Also, the argument that you can just add multiple inheritance and win the
>battle is based on the assumption that C++ is now static, that it's not
>going to acquire any more useful features.  I suspect strongly that this is
>a mistaken assumption.[...]

The main problem of C++ is not that it would not have lots of good features
(especially the newest release, 2.0). The problem is that it has such
fundamental _bad_ features that will have no chance ever to go away:
they should have been pruned in the first step from C to C++.
Things like the pointer arithmetic certainly invite if not oblige
C and C++ programmers to "hacking ways", or perhaps they invite
hacker-style programmers to use these languages instead of more
disciplined ones.

Several other comments in Mr. Dunn's posting made sense, though.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland

Re: Re^2: Ada 9X objectives

[Dick Dunn]

jcardow@blackbird.afit.af.mil (James E. Cardow) writes about the problems
in shortening the Ada language update cycle.  His points were good, yet I
was left with the feeling that there was something wrong underneath.  I
finally decided that it's this:

> ...Consider the ten to twenty year development cycle for large projects...

If you have a ten-year development cycle for a software project, you're
going to be producing obsolete software!  You can't help it.  Ten years is
just too long for anything tied to computers--the technology moves too
fast.

You've got to get software up and working, and performing at least some of
the needed functions *soon*.  You also need it to be adaptable, so that it
can evolve as needs and technology change.

What I'm getting at is that I think we're trying to address the wrong
problem.  Rather than trying to solve "How do we deal with long development
cycles?" we should be solving "How do we shorten the development cycles?"
-- 
+---------+     Dick Dunn    rcd@ico.isc.com    ico!rcd      (303)449-2870
| In this |         4th annual MadHatterDay [10/6/89]:
|  style  |               Madness takes its toll
|__10/6___|

Re: Ada 9X objectives

[James E. Cardow]

rcd@ico.ISC.COM (Dick Dunn) writes:

>> ...Consider the ten to twenty year development cycle for large projects...

>If you have a ten-year development cycle for a software project, you're
>going to be producing obsolete software!  You can't help it.  Ten years is
>just too long for anything tied to computers--the technology moves too
>fast.

>You've got to get software up and working, and performing at least some of
>the needed functions *soon*.  You also need it to be adaptable, so that it
>can evolve as needs and technology change.

I must admit that my comments were made with only my own experience in mine, 
that being large DOD sponsored projects that had developments spanning two
to three computer generations.  However, that is the primary Ada environment.
In the military software support world we are for the most part just entering
the support for JOVIAL systems.  Having been responsible for "selling" Ada
to the people attempting to prepare for "new" software, I'm convinced that 
injecting new technology especially evolving technology may very well be 
a cure more painful than the disease.  

Consider the problem in a real context.  System software in the +100,000 
lines of code, with supporting software at a 4:1 ratio.  Add to that 
simulator software that must function exactly like the real thing.  Now 
add unique hardware, especially processors.  If the system were 
stagnant and the budget available the conversion to a new language would
be simple (simpler?).  But reality says the money for change is small, and
the user demand for improvements is large.  The changes come in modification
of 10 percent of a unit here, 5 percent there.  The only real opportunity
is when major systems are effected, but that is rare.

>What I'm getting at is that I think we're trying to address the wrong
>problem.  Rather than trying to solve "How do we deal with long development
>cycles?" we should be solving "How do we shorten the development cycles?"
>-- 
In the years I have spent chasing DoD software I have always worried about
how to get it delivered closer to the expected date, the idea of shorter 
never occured to me.  But, I'm changing roles now to teach software 
engineering and would greatly love to discuss ways to shorten the 
development cycle, or ways to inject new technology into old systems.  If you
have ideas on the subject within the context of large, complex systems or 
know of any work in these areas let me know.

As a side note, Ada can be added to older systems.  It takes convincing 
people that the benefits over the long run are worth the effort.

Ada 9X objectives and long development cycles

[Dick Dunn]

jcardow@blackbird.afit.af.mil (James E. Cardow) writes:

James Cardow wrote:
> >> ...Consider the ten to twenty year development cycle for large projects...

I squawked:
> >If you have a ten-year development cycle for a software project, you're
> >going to be producing obsolete software!  You can't help it...

I realize that my comment was just an objection--not a suggestion for how
to fix the problem I perceived.  However, Cardow seems interested in the
subject; I'm vitally interested; I'd like to bounce some ideas around...
so perhaps it's worth pursuing.  (Would this be better moved to
comp.software-eng?  I don't know how much Ada relevance it will retain.)

> I must admit that my comments were made with only my own experience in mine, 
> that being large DOD sponsored projects that had developments spanning two
> to three computer generations.  However, that is the primary Ada environment.

Perhaps, then, there's a fundamental question of whether Ada can remain
suitably stable for these very-long-schedule projects, yet acquire some
ability to adapt more quickly.  At first blush, that seems like it might
be difficult.  However, it's important to consider it, because if Ada can't
adapt faster and be more responsive than it has, there is a chance that
large DoD projects will be its *only* real domain, denying it success in
the commercial world where you've got to move faster.

(I spend my time in the commercial world and have done so for quite a
while; my only real encounter with the DoD world was a brief but horrible
skirmish with a Minuteman-related project many years ago.)

> Consider the problem in a real context.  System software in the +100,000 
> lines of code, with supporting software at a 4:1 ratio...

Yes, ouch, although commercial operating systems are in that range.  Once
you've got such a system, you've got all the problems that go along with
it.  But can you aim to avoid producing systems of that size in future
projects?  How big do the systems *really* need to be?

One thing I've noted again and again as I look at complex software and
large software projects is that predictions that "this is gonna be a big
un!" are self-fulfilling.  Let me see if I can illustrate.

There's a tendency for the perceived amount of effort required for a
project to be "bimodal" in a funny way.  That is, if you look at the number
of people on a project versus the perception of the project staff of
whether it's under-staffed or over-staffed, you are very likely to see
something like the following:
	- very few people: perception is "we need more"
	- just about right: perceptions are mixed as short-term needs vary
	- too many (past first node): "too many people; they're getting in
	  the way and getting bored"
	- a whole bunch too many past first node: "not enough people"!
	  This is the interesting point--it's where you get so many people
	  that you need to ADD people to manage, coordinate, communicate,
	  etc.  You're so overstaffed that you've got to add people to
	  cope with the excess staff so that work can get done.  Excess
	  staff is a particularly severe problem in early project phases.
	- just about right again (at second node):  "ok, but this is sure
	  a big project"  You've got enough people to handle the project
	  AND all the extra people.

Projects could be multi-modal (more than two nodes) but it's hard to
imagine covering that much range in staffing without getting a reality
check.  Two examples of where I believe I've seen this bimodal-staffing
phenomenon were something like 4 or 5 people versus about 30, and perhaps
10-15 versus 600-800!  The differences are radical--they have to be to get
a qualitative difference between the nodes.

The first point about this is that if you get really wound up for a big
project, instead of making every serious attempt to simplify it to the
bone, you'll staff up for a big project.  You'll pass the first node at a
full gallop and enter the region where you're (seemingly) understaffed.

Now think about what happens if you get to the larger size:  You *must*
produce a large piece of software.  There *will* be more difficulties in
communication among people (and therefore among modules).  So you have to
impose a lot more structure.  It's harder to assess the effects of changes,
so it's harder to make them.  If one function (or ADT implementation or
whatever) isn't quite what you'd like, it may involve too many people and
too much hassle to change it, so the code that uses it gets a little more
complicated and bigger to work around the mismatch.  If it's obviously
wrong, it'll get changed...I'm talking about subtler problems.  But the
phenomenon feeds on itself:  As one piece of code grows to adapt to a
mismatch, it itself becomes harder to change.  The software "sets up" too
soon.  You try to avoid this, of course, because you can see some of it
coming.  So you spend more work on the front-end phases--detailed design,
massive specification, all conceivable attempts to pull things together.
It helps a little, but it also speeds the ossification process.  What
you're doing is making sure that when things set up, they end up about
where they're supposed to be.  But what you really need is to keep them
from setting up so soon.

Some of you will no doubt think I'm crazy, or hopelessly pessimistic (or
both!:-)  You probably have trouble grasping it until you've worked on a
project whose printed specifications comprise a stack of paper taller than
you are.

If you can keep the software fluid and able to change throughout the
development process, you have the side benefit that the software has been
going through changes.  Adaptability is already an idea for the software.
It's in people's minds.  Some of the un-adaptability will get fixed before
the software goes out the door the first time.  (You're sanding off the
rough edges that occur in *any* new product.)

Another problem of the overstaffing/overestimating explained above is that
it becomes harder for any one person to get a comprehensive view, or even a
substantial view.  This feeds into both the difficulty of change and the
difficulty of perceiving the need for change.

Following from that to a different observation - The best software is
constructed by the smallest possible number of best possible individuals.
Each person has greater responsibility and more global view of the project.
Instead of having, perhaps, NObody who can see the whole picture, you might
have two or three who can see it, and who can act as cross-checks on one
another.

There are still projects which are large enough that they need a small army
to implement them...and honestly, I don't have a lot of ideas there.  But I
do know that the number of such massive projects is much smaller than is
commonly believed.  I also know that once a project gets away from you and
starts to grow, you have real trouble taming it again.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.

Re: Re^2: Ada 9X objectives

[Robert Eachus]

In article <16176@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes:
>jcardow@blackbird.afit.af.mil (James E. Cardow) writes:
>> ...Consider the ten to twenty year development cycle for large projects...

>If you have a ten-year development cycle for a software project, you're
>going to be producing obsolete software!  You can't help it.  Ten years is
>just too long for anything tied to computers--the technology moves too
>fast.

    In many cases the schedule is determined by something other than
the software, such as the Space Shuttle.  (And the only reason that
software wasn't on the critical path was the problems with the tiles,
but I digress.)  Or any new commercial jet aircraft like the 7J7, or
military projects like the Advanced Tactical Fighter...

    Software schedules for such large, long duration projects will
include many builds and tests before the actual aircraft is flown.
Again, to use the Space Shuttle as an example, the filght software was
extensively tested (and frequently crashed) in various simulators
before the Shuttle was ever flown, and the Shuttle was flown as a
glider several years before it was ever launched from the cape.

    Each software build may have a short schedule, but you need the
software from build 1 to still mean the same thing when build 27 (or
build 103) gets tested for the first time in the air, and when build
34 goes into the first production aircraft.

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Ada 9X objectives

[William Thomas Wolfe, 2847]

From ryer@inmet.inmet.com:
> If it costs $500k each to add a high quality multiple-inheritance type
> system to Ada compilers, and there are 15 separate baselines (FE's),
> then the cost of the feature (at high quality) is $7.5M.  Will enough
> C++ and Eiffel users go out and buy one to cover the investment?  

   Look at it this way: if Ada 83 is not upgraded to reflect recent
   advances in software engineering technology, then your investment
   in Ada in general will go down the tubes along with the language.

   We already know from a number of articles (e.g., "Comprehensive 
   Scheduling Controls for Ada Tasking", Tzilla Elrad, Ada Letters, 
   Fall 1988, and "Programming Atomic Actions in Ada", A. Burns and 
   A. J. Wellings, Ada Letters, September/October 1989) that the 
   entire Ada tasking system is going to have to be overhauled.  

   A good inheritance/class system in Ada 9X should be introduced now
   along with this overhaul of the tasking system; I personally think
   that if this is done, the resulting growth of Ada will provide rich 
   rewards to the compiler vendors who followed.  

   Comments were made at Tri-Ada '88 to the effect that while there are
   real risks associated with changing (to Ada), there are even larger 
   risks (competitive risks) associated with NOT changing, and this is 
   what must be brought home to those organizations which are still using
   the older languages.  Perhaps we would do well to heed our own advice.
 

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Modernizing Ada

[Erland Sommarskog]

Bill Wolfe writes:
>Tucker Taft (stt@inmet) writes:
>> Here is the wording from the Ada9x project plan:
>>  A revision requirement that does not meet the "upward compatibility"
>>  criteria will only be considered if it affects a very large
>>  portion of the Ada community and its absence in the
>>  revised standard has a serious negative impact on application development.
>
>  Multiple inheritance, for example, meets both criteria and therefore
>  should be considered regardless of whether or not upward compatibility
>  is affected.  Every effort must be made to minimize the difficulty of
>  the transition, but not at the expense of capabilities which are vital
>  to the modernization of our software engineering technology.

It's not that I have anything against multiple inheritance, rather
the opposite, but I'm not 100% sure that it should be included in
Ada 9X. It would like throwing the yeast into the oven while the
bread is baking.
  It's easy to say "multiple inheritance" but it should be
implemented too. And I'm not talking compiler technology here.
My issue is the langauge definition. The inheritance mechanism
should integrated with existing constructs in Ada. Say that you add
classes a new compilation unit to Ada. Easy? Yes, but why then
keep packages? OK, make the classes package types, but somehow
I feel that we will ending up having something in the langauge
that will be obsolete once we have a inheritance mechanism, multiple
or not.
  And, by the way, isn't there a very simple reason why Ada don't
have inhertiance and dynamic binding today? Wasn't that explicitly
forbidden in the requirements? Have the requirements changed?
(Well, that's not unlikely, because it was not a sound requirement.)

Getting inheritance into Ada would give us an Ada++ with the
same advantages and disadvantages as C++. Compatible, but at the
cost of keeping constructs that shouldn't be there.

It is possible that the refusal to accept inheritance in Ada
way back in 1980 will mean that Ada never becomes the star
as intened. But that might as will be the case if we exclude
inheritance from 9X or if we include it. In the latter case 
because the language gets too large with redundant features.

All this said with the following reservation: I haven't seen
any concrete proposal on how an inheritance mechanism in Ada
should be look like. Therefore is my discussion on the consequences
on such a construct somewhat hypothetical, but so is everybody
else's too.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
"My baby's a 26. On a scale from one to ten, my baby's a 26." - Chic

Re: Modernizing Ada

[William Thomas Wolfe, 2847]

From sommar@enea.se (Erland Sommarskog):
> My issue is the langauge definition. The inheritance mechanism
> should integrated with existing constructs in Ada. Say that you add
> classes a new compilation unit to Ada. Easy? Yes, but why then
> keep packages? OK, make the classes package types, but somehow
> I feel that we will ending up having something in the langauge
> that will be obsolete once we have a inheritance mechanism, multiple
> or not.

    Actually, there are a lot of things which seem "scattered"
    when one starts thinking about expressing even user-defined
    types in Ada, regardless of whether inheritance is present
    or not.

    For example, currently the language defines attributes for
    predefined types, and implementations may also define attributes,
    but a user-defined type can't define its own attributes.  The 
    result is that one has to use operations over the type to do
    "synthetic" attributes.  But now we have an inconsistency: for
    the predefined types we can use the attribute notation (which is
    actually rather common in object-oriented languages), and all is
    well.  But for the "synthetic" attributes, we must use the subprogram
    call notation.  Why is there this scattering of the attribute concept
    across the syntax for attributes and the syntax for subprograms?

    For its time, Ada was an outstanding design, but it seems that the
    object-oriented concepts were still a little fuzzy and not completely
    integrated.  Properly integrating the various constructs would result
    in a clean, crisp 9X which will not be subject to the great criticisms
    of excessive complexity which have plagued Ada 83; if this is done, 
    9X will be a heck of a lot easier to learn (and adopt) than 83 was. 

    Jean Ichbiah, in "Ada: Past, Present, Future" (CACM, October 1984)
    commented on the criticism of excessive complexity that regardless
    of the number of details, complexity depends upon "whether or not
    it is easy to infer the details from major structural lines"; quite
    true, but there is some simplification and integration that could
    be done with these structural lines to make a cleaner product.
 
    IMHO, it is probably possible to add multiple inheritance to Ada
    without cleaning up what in certain areas is a fragmented design,
    just as it is possible to let that original fragmentation persist.

    However, the results won't be pretty, and we have an opportunity 
    before us to correct errors of commission as well as of omission.
    More importantly, though, it will demonstrate Ada's will to survive.
    COBOL, had it been willing to update itself properly, would over time
    have turned into what Ada is today (more or less);  believe it or not,
    COBOL started out (Ichbiah, CACM, Oct. 84) with "exactly the same" 
    motives that Ada started with!!  Because of COBOL's demonstrated 
    inability to change with the times, the DoD decided to just scrap 
    COBOL completely and start over. 

    I would hope that this fate is not in store for Ada as well.  We
    already are going to have to solve substantial problems with the
    tasking model, handle the impact of asynchronous exceptions, etc.,
    and there is enough change needed already to ensure that we have
    every incentive to act now.  

    As long as progress continues to be made in software engineering 
    technology, we cannot stand still.  Our inertia must always be a 
    *forward* inertia -- the tendency to keep advancing.
 

    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Modernizing Ada

[Richard O'Keefe]

In article <6780@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
>     COBOL started out (Ichbiah, CACM, Oct. 84) with "exactly the same" 
>     motives that Ada started with!!  Because of COBOL's demonstrated 
>     inability to change with the times, the DoD decided to just scrap 
>     COBOL completely and start over. 

COBOL has changed *dramatically* with time.  Successive COBOL standards
have not merely added new things (like nested programs, terminators on
compound statements, new statements) but have also discarded old things
(like the ALTER statement).  The main complaint that I have heard from
COBOL users is that new standards change too much too fast; adapting to
a new standard is not just a matter of recompling.  In fact there is no
shortage of companies that make a living converting other people's old
COBOL programs to new standards.

COBOL is guilty of a lot of things, but not of standing still.