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!uunet!wuarchive!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!unmvax!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 objectives
Message-ID: <6699@hubcap.clemson.edu>
Date: 8 Oct 89 17:07:34 GMT
References: <72799@linus.UUCP>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>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