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.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 29 Sep 92 21:47:28 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: The trouble with Ada... (60 lines)
Message-ID: <EACHUS.92Sep29164728@Dr_No.mitre.org>
List-Id: <comp.lang.ada>

In article <1992Sep24.150801.20492@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com 
(fred j mccall 575-3539) writes:

   Anyway, I don't think the 'superhacker' mentality is any less
   prevalent in Ada -- it is just justified differently.  After all,
   how many people have you heard assert that SIMPLY BECAUSE THEY ARE
   USING ADA they will not have this or that error?  Sounds like an
   unreaasonable faith in a 'magic bullet' to me; just another way to
   justify the 'superhacker' syndrome.

   Yes, language will somewhat impact your approach to a problem, but
   this should happen only insofar as taking into account SHORTCOMINGS of
   the language is an impact.  This is another one of those
   mythology-breaking things...

   Sorry Fred, but anyone who has done much Ada development knows
that developing in Ada IS different.  Back in 1983-1985 the Greek
chorus at AdaTEC (later SIGAda) meetings was that "Ada is not just
another programming language."  Learning to program in Ada meant
learning software engineering.

   A few years later, many people had discovered that development in
Ada meant something like 60% design, 20% code, 10% integration and test.
Much different from the old 40% design, 50% code, 90% integration and
test.  It is now becoming apparent WHY this is, which is why I started
preaching to the converted.  (Anyone who has seen the magic of the
integration phase of a large Ada project knows that things are
different.  Anyone who hasn't doesn't believe it.)

   My experience has been that in over a million lines of Ada code,
ALL of the problems I have encountered in system integration involved
script files and pathnames.  All of the parameter mismatches and name
conflicts were long gone by then, as well as most of the bugs.  One
system had one bug report in the first six months after it was
released--an error message was misspelled, most others had none.
(This of course does not include internal and beta testing.)

   Why does it work out this way?  Because it is very easy to express
ANY workable system design in Ada.  So if you can't express the
design, you know you are in trouble.  And you find out early.  Of
course, many times the design is expressable in Ada but won't work.  I
have always found it fairly easy to reconfigure the design in these
cases, with even major reorganizations requiring only a couple of
days.  Minor fixes like add another parameter to an interface or
another field to a record usually takes less than an hour, including
recompiles.
--

					Robert I. Eachus

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