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,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-12 21:12:41 PST Newsgroups: comp.lang.ada Path: bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!uunet!world!srctran From: srctran@world.std.com (Gregory Aharonian) Subject: Magnavox consultant trashes Ada tools in IEEE Computer Message-ID: Organization: The World Public Access UNIX, Brookline, MA Date: Tue, 11 Oct 1994 20:48:03 GMT Date: 1994-10-11T20:48:03+00:00 List-Id: 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. Written by Joseph Skazinski (who obviously must have gotten burned by Ada tools while working on AFATDS), the report illustrates the protectionist weaknesses of the Ada Mandate vis-a-vis Ada vendors. Titled "Porting Ada: A Report From the Field", the article talks about AFATDS development across Intel 486 running SCO, HP9000 running HP UNIX and moving code back and forth. I quote partly in context, partly out of context, not that it makes much difference. "The lack of stable and easy-to-use Ada libraries necessitated the writing of many Ada procedures whose sole purpose was to interface with C/Unix routines." "(Unfortunately, the Alsys Ada environment and the Ada tools limited the size and number of files that could be compiled into a library.)" "The creation of multiple child libraries from the parent library was necessary because of type and procedural dependencies among Ada packages. 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)." "Further the immaturity of the Ada tools was evident when the library manager tool would corrupt a library during the compilation of an Ada source file. This corruption meant that the entire library and all dependent child libraries had to be rebuilt." "[data alignment problems]. If an unaligned chunk of memory was used for a variable, program execution halted. Attempting to use the Ada debugger to view the variable resulted in the debugger's crashing, a time-consuming annoyance." "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. Given that most of our executable file names were based on Unix conventions, it took quite a while to solve this problem. Alsys did not have a solution, and we discovered the eight character limitation only by chance." "Because the project's executables were very large, some over 20 megabytes, we attempted to compile them with full or limited optimization to reduce their size. Unfortunately, our attempt at optimization failed to produce reliable executables and we abandoned it. When the debugger crashed, we often had to wait to minutes to reach the same breakpoint." "We also found declaration elaboration to be a very time-consuming process that Ada debuggers did not handle well. An error occuring during this process would terminate execution. The elaboration process greatly complicates debugging and may result in erroneous programs, because elaboration is determined at execution time and may vary based on timing issues. The best solution to this problem is to minimize elaboration." "Needless to say, it is not easy to localize a problem in an application with dependencies on hundreds of Ada files. This process took considerable time, and solutions were not always found. When we couldn't find a tool solution, we had to research another method to accomplish the task and modify the software accordingly." "The effort to port AFATDS to an Intel/SCO platform is still incomplete and is awaiting an Ada compiler upgrade that can pass the AFATDS messaging schema's large arrays to generic procedures." "If the DoD's dual-use strategy is to succeed, the DoD must also foster the development of reliable and affordable Ada tools." ==================== Makes me want to rush out and drop my current language and adopt Ada. And this from an article written by someone who will be as favorable to Ada as anyone, being a contractor to the Army. And yet the article pretty much erases any gains that the ASA's advertising campaign much have achieved (while at the same time contradicting the main point of the ASA's ads). Many of the insults made by Ada people against C/C++ being said about Ada by an Ada person. 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. If such sentiments are common INSIDE the Mandated world, and reflect the reality of current Ada tool technology, then Ada dual-use efforts are guaranteed to fail outside the Mandated world. For ten years open and honest debate about Ada policies and problems in the Ada industry has been suppressed, ignored and ridiculed. There should be entire sessions at Tri-Ada devoted to this topic, instead of the sweeping-under-the-rug that the SIGAda organizers every year seem to do. More than ever, this year's Tri-Ada needs a debate on the Ada dual-use. You can't dismiss this article by saying the author is a crackpot, inaccurate, unprofessional, or whatever, as Skazinski is an independent consultant who worked as a senior engineer with Magnavox (though like many others, he had to wait until the project was over to speak the truth). Nothing in the current dual-use plan addresses these issues, even assuming that the DoD cared enough about Ada to give the tens and hundreds of millions of dollars needed to help commercialize Ada. The plan was prepared by people unwilling to break out of the rut of having the same old people using the same old techniques to promote Ada while ignoring tons of disturbing trends. This article is a disaster for Ada (which is even more ironic since the editor of IEEE Computer is at the Naval Postgraduate School - hint of a Army/Navy conspiracy to help undermine the Ada Mandate? Inquiring minds want to know). IEEE Computer goes out to tens of thousands of software professionals who now are going to have a stack of reasons to ignore considering and adopting Ada, thanks apparently to an Ada insider. But hey, have fun singing songs and passing out medals at Tri-Ada. Greg Aharonian