Magnavox consultant trashes Ada tools in IEEE Computer

[srctran@world.std.com (Gregory Aharonian)]

    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