From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=3.0 tests=BAYES_50 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 8 Aug 91 21:32:04 GMT
From: netcomsv!jls@apple.com  (Jim Showalter)
Subject: Re: Ada vs. C Comparison Data ?
Message-ID: <1991Aug08.213204.22727@netcom.COM>
List-Id: <comp.lang.ada>

wicklund@intellistor.com (Tom Wicklund) writes:

>Other reasons are
>based on C++ being younger, unstandardized, and not currently under
>DOD control.  This says nothing about the capabilities of the
>language, just that Ada is already in the DOD process.  A good reason
>for DOD, maybe not for somebody else.

Immaturity and lack of standardization seem like good reasons to stay
away from a language whether one is DoD or not. As for capabilities,
I find the two languages much more similar to one another than different:
both offer strong typing, data encapsulation, separation of specification
from implementation, etc. Each is missing one major feature the other has:
Ada lacks inheritance/polymorphism and C++ lacks concurrency.

>Funny -- Software quality experts will tell you that all the formal
>reviews, QA, etc. improve productivity and reduce costs.  Informal
>requirements with frequent user interaction are especially expensive
>compared to a fixed set of requirements up front.  So if the C++
>projects were done more formally they should cost less, right?

I'd _like_ to believe this, but yars of experience with DoD sites
leads me to the opposite conclusion. At least in DoD land, most of
the formal stuff is a gigantic time and resource sink with little
or no benefit.

>Again, this study points out the relative maturity of Ada, the tight
>standardization, and DOD's single language strategy.  Important for
>some users, not for others.

Again, I cannot think of a compelling argument for using a language that
is immature and weakly (if at all) standardized. Can you?

>This report does skirt around an interesting issue -- The use of CASE
>tools which directly generate code or languages such as Ada versions
>of LEX, YACC, and state machine generators are technically violations
>of the Ada mandate.  If I write a scanner in ALEX I'm not writing
>strict Ada code.  Taking the Ada mandate literally one can't use any
>of these tools since your source code isn't Ada.

Semantics. The resulting language of implementation is Ada, so why
is this a violation of the mandate? There is almost always some
front-end "language" used that is not Ada, be it bubbles-and-arcs
or some formal specification language, or whatever. The Ada mandate
never says that such design approaches cannot be used--only that
the language used to implement the design (however the design was
arrived at) must be Ada.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *