TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Mon, 20 Sep 1999 11:44:59 -0400
Tucker Taft <[log in to unmask]>
Tucker Taft <[log in to unmask]>
text/plain; charset=us-ascii
AverStar (formerly Intermetrics) Burlington, MA USA
text/plain (48 lines)
[log in to unmask] wrote:
> ...
> Before everyone jumps on it, yes, I know in the long run the Ada tools are
> more productive and cost effective. The problem is that it's difficult to
> find any data that proves that point. Most reports and studies don't have
> enough hard data on the benefits. ...

The presentation with the most "hard" data I have seen is:

There are a number of slides with hard data about productivity,
with references to the original information.

Probably the most compelling story on the C/C++ side is the following
paper from the Bell Labs Technical Journal:

This paper identifies the most common faults in the huge 5ESS switch
developed by Bell Labs/Lucent.  It also details the huge effort they
have gone into to work around the fact that the basic material (the "C"
language) they are working with is fundamentally flawed.  The most bizarre
thing is that if they were building just a piece of hardware, they
would totally reject a basic material with as many inherent flaws as C.
But somehow, when it comes to software, they are blind to the amazing
inefficiency of putting large numbers of complicated processes and
cross-checks into place, just to deal with the fact that the C language
and C compilers lack the rich compile-time and run-time checking that
is available in alternative materials (e.g. the Ada language and Ada

And of course, if you want to put these improved processes into place
anyway, with Ada these efforts can be devoted to focusing on deeper
architectural issues, rather than being devoted to making up for the
inherent syntactic and semantic flaws of C/C++.

> John T Apa                              [log in to unmask]
> L-3 CSW                                 (801) 594-3382
> PO Box 16850                            Fax: (801) 594-2195
> 640 North 2200 West                     Salt Lake City, UT. 84116-0850
-Tucker Taft   [log in to unmask]
Technical Director, Distributed IT Solutions  (
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA