comp.lang.ada
 help / color / mirror / Atom feed
From: bobduff@dsd.camb.inmet.com (Bob Duff)
Subject: Re: Magnavox consultant trashes Ada tools in IEEE Computer
Date: Wed, 19 Oct 1994 02:07:38 GMT
Date: 1994-10-19T02:07:38+00:00	[thread overview]
Message-ID: <CxwDws.3C5@inmet.camb.inmet.com> (raw)
In-Reply-To: 1994Oct17.164852.1@delphi.dasd.honeywell.com

In article <1994Oct17.164852.1@delphi.dasd.honeywell.com>,
TOM <tsorense@delphi.dasd.honeywell.com> wrote:
>In article <CxJ0G3.B9x@world.std.com>, srctran@world.std.com (Gregory Aharonian) writes:
>>     The October 1994 issue of IEEE COMPUTER has an article from Magnavox AFATDS
>> which does a pretty good job of effectively trashing Ada in a public forum.
>>     "The creation of multiple child libraries from the parent library
>>     was necessary because of type and procedural dependencies among Ada
>>     packages.
>
>This sounds like a poor design, and a poor design will cause lots of
>recompilation due to type and data dependencies.   If the principles of
>data abstraction are done correctly, this shouldn't have been a problem.
>Doesn't any body do software engineering anymore?  I guess it's just easier
>to blame the tool rather than developing a good architecture.

It doesn't seem fair to blame the user for poor tools.

It's really hard to design large systems in Ada that take advantage of
all the fancy software engineering features and also yield reasonable
compile times.  I think child packages and the Distributed Systems annex
of Ada 9X will solve these problems, though.

>>     This structure created very long compile times when a
>>     package library was modified and all dependent packages had to be
>>     recompiled.  The compilation of all Ada and C source files took
>>     nearly 4 days on the HP9000, less than a day on the RISC machines,
>>     and close to a week on the Intel486 machines. (The equivalent
>>     amount of C or C++ would take considerably less time; for example,
>>     the GNU C++ compiler completed about 30,000 lines of code in about
>>     12 minutes on an Intel 486 SCO machine)."

This seems strange.  I find it hard to believe that any Ada compiler
would take days to compile 30,000 lines of code.  That's about 5 lines
per minute!

The above doesn't exactly say that.  It says it took 4 days to compile
the whole Ada program (we don't know how big), and 12 minutes to compile
30,000 lines of C++.  It does *not* say that the whole Ada program was
30,000 lines.  So we have no information on how long it would have taken
the C++ compiler to compile an equivalent program.  Surely the Ada code
was more than 30,000 lines.

>It compiled - yes, were the data abstractions correctly implemented?  The
>strong compile time type checking and unit consistency checking take more
>time, but buy orders of magnitude of time when working under the gun in the
>integration lab.  Experience shows me that I would rather have a computer
>detecting bugs (via type checking and unit consistency checking) early
>rather than having to find them the hard way in the lab.

4 days of compile time is ludicrous.  I don't care how many consistency
checks are done -- if it takes 4 days, productivity is going to be
abysmal.

>>     "Ada tool problems constituted the most significant hurdle in the
>>     porting effort.  For example, the Alsys compiler running under SCO
>>     UNIX would crash if an executable's file name contained more than
>>     eight characters and would not display an error message to that
>>     effect.
>
>Hmmmm  Does SCO Unix run on top of DOS - I think a sixth grader could have
>figured that one out.  I move files from the VAX to the PC every day - it's
>not the tool's fault - they all use the DOS file system.  I think
>Mr.Skazinski missed the mark by saying that it was the Alsys compiler's
>fault, he should point the finger at himself or whoever decided on the
>platform.

No, SCO Unix does not run on top of DOS.  It's a Unix OS for PC's, and I
believe it has long file names, and it's a valid complaint if the
compiler crashed when it saw them.

GA, again:

>> Fifteen years and hundreds of millions of dollars of Ada pork, and insiders
>> are still complaining about the poor quality of Ada tools.  Debuggers crashing,
>> linkers not linking, Ada features not being used because they are unreliable,
>> and my favorite, comparing a 12 minute compile time for some C code that is
>> equivalent to some Ada code that took a week to compile.

I find it hard to believe that the Ada compiler actually ran at 5 lines
per minute.  So I think GA is incorrectly comparing apples and oranges
here.

>Compile times are irrevelant if the code doesn't work. Ada's concept of
>unit consistency prevents me from hurting myself in that area.

You could check the consistency *by hand* in 4 days!  Sheesh.  You're
not going to get any Ada converts by claiming that 4-day compile times
are worth it because of some additional consistency checking.  We need
Ada compilers that are at least *close* to the speed of C and C++
compilers.

- Bob
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)



  reply	other threads:[~1994-10-19  2:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1994-10-11 20:48 Magnavox consultant trashes Ada tools in IEEE Computer Gregory Aharonian
1994-10-13 14:52 ` Paul Slonaker
1994-10-13 20:35   ` Ariel Lieberman
1994-10-17 23:48 ` TOM
1994-10-19  2:07   ` Bob Duff [this message]
1994-10-19 11:17     ` Robert I. Eachus
1994-10-20 19:00       ` Magnavox consultant trashes Ada tools Richard L. Conn
1994-10-21 20:28       ` Magnavox consultant trashes Ada tools in IEEE Computer Ed Falis
1994-10-23 15:41         ` Norman H. Cohen
     [not found]         ` <leschkes.783014077@ferret>
1994-10-25 17:03           ` Bob Kitzberger
1994-10-25 18:06           ` Robert Dewar (was: Magnavox etc.) Michael Feldman
1994-10-19 13:31     ` Magnavox consultant trashes Ada tools in IEEE Computer Robert Dewar
1994-10-24 22:26   ` Robert Monical
1994-10-25 14:53     ` Esther Lumsdon
  -- strict thread matches above, loose matches on Subject: below --
1994-10-18 23:30 Douglas Rupp
1994-10-20  9:35 Bob Wells #402
1994-10-24 21:52 CONDIC
1994-10-25 17:06 Nick Sizemore
1994-10-27 20:48 CONDIC
1994-10-28 15:12 ` Mitch Gart
1994-11-01 10:18   ` David Emery
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox