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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e5015e00941d1492 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-21 08:01:54 PST Newsgroups: comp.lang.ada Path: bga.com!news.sprintlink.net!howland.reston.ans.net!news.moneng.mei.com!hookup!yeshua.marcam.com!news.mathworks.com!noc.near.net!inmet!dsd!bobduff From: bobduff@dsd.camb.inmet.com (Bob Duff) Subject: Re: Magnavox consultant trashes Ada tools in IEEE Computer Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: <1994Oct17.164852.1@delphi.dasd.honeywell.com> Date: Wed, 19 Oct 1994 02:07:38 GMT Date: 1994-10-19T02:07:38+00:00 List-Id: In article <1994Oct17.164852.1@delphi.dasd.honeywell.com>, TOM wrote: >In article , 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.)