From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.lang.ada
Subject: Re: Ada 9X
Message-ID: <6754@hubcap.clemson.edu>
Date: 12 Oct 89 15:22:49 GMT
References: <8910111843.AA11007@chance.mitre.org>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>From munck@COMMUNITY-CHEST.MITRE.ORG (Bob Munck):
> I hate to keep harping on this, but the emphasis of the Ada effort is (IMO)
> 
>        software engineering        NOT       programming languages

   This has already been addressed; the object-oriented software
   engineering paradigm is not currently being properly supported,
   although Ada was largely designed around object-*based* concepts.

   Continued evolution in object-oriented thinking has produced an
   important new concept (multiple inheritance) which must now be
   incorporated in support of current software engineering technology.

>          life-cycle costs          NOT         development costs

   Okay, let's consider life-cycle costs.  In particular, let's consider
   adaptability.  The use of inheritance not only speeds up development,
   but also dramatically increases the speed with which a system can be
   modified.  Where's the argument?
 
>     large, many-person projects    NOT        utilities and "toys"

   An inheritance hierarchy provides the conceptual infrastructure
   which permits large, many-person projects (actually, entire software
   organizations) to organize more effectively.  It is fundamentally a
   programming-in-the-large concept.  Again: where's the argument?

> The life-cycle of a large system is longer, perhaps much longer, than
> the 10-year revision period of Ada.  I have a hope that the life-cycle
> of large systems will become essentially infinite when coded in Ada;
> that they will no longer "die" and be entirely replaced by a major
> project, but rather "evolve" through many small improvement projects. 
> ("WIS: never again!")  Also, if we ever solve the managerial problems of
> software reuse, the contents of repositories will essentially be systems
> with very long life-cycles.

   Wow.  Now consider the fact that the evolution of an inheritance
   hierarchy is precisely the way that such evolution can be done in
   an organized manner, and that similar benefits can be brought to
   the problem of repository organization.
 
> It is important to note that "a language that doesn't change" is not 
> the same as freezing the current revision of the compiler.  

   But now for an incredibly simple question: if you are dead-set
   on using Ada 83 forever, what prevents you from doing it?  As
   long as the validation suites continue, the compilers will 
   continue to revalidate, converging upon a bug-free condition. 

   Thus, why deny yourself the option of using a more modern 9X 
   software engineering technology?  Keep 83 around as long as it 
   remains useful, and use pragma Interface and/or automatic translation
   when you decide that 83 is no longer locally useful for a specific
   part of your system.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu