Re: Magnavox consultant trashes Ada tools in IEEE Computer

[tsorense@delphi.dasd.honeywell.com (TOM)]

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.
> 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 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.

>     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)."

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.

> 
>     "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."
>

Did they evaluate the tools that they were going to use?  Some tools work
better on some platforms than on other ones, but responsible engineers
should make sure that the tools work as advertised before using them.

>     "[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.

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.

>     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."

( Laughter! )

> 
>     "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."
> 

I agree here. 

>                               ====================
> 
> 
> 
> 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.

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

> 
> 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.

I have to agree with Greg - I personally would rather program in Ada all of
the time, but the lack of built-ins to due the low level bit twiddling
makes for ugly code (I like C in that regard), and the high price of
compilers means that I'll program in C or Pascal at home.

> 
> 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).

A senior engineer could also mean that he is 20 years behind in technology.
I am not saying that about Mr. Skazinski since I don't know all of the
facts, but I work for a senior engineer that is in management that is at
least 10 years behind the current technology and I know tenured professors
that teach C the same way now as they did 20 years ago.  Does this mean
that they are right?  I see part of my job now as educating by boss on
current technology and bringing him into the 90's.  My experience with Ada
on real-time embedded systems has lead me as a software lead to recommend
it to my customers (DOD and Non DOD alike).   I program in C and will do so
if my customers demand it, but I don't recommend it.  I prefer Ada since
(if I have a good comiler and toolset - Vendors are you listening?) it will
be inherently a more reliable and maintainable system than I could put
together in C (or in C++).   I really have no biases against any language
since they are just tools to get the job done.  I try to use what works
best for each particular job - and in embedded systems, Ada is what works
best for me.

> 
> 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
-- 
*******************************************************************************
   /   /   /\     ----      Todd A Sorensen    (505) 828-5611
  /   /   /  \   /          tsorense@dasd.honeywell.com
 /   /   /   /   ---        tas@dasd.honeywell.com
/   /   /   /      /
----   ----     ---         [Now a "dronie"]
********************************************************************************