Re: Current status of Ada?

[<adaworks@sbcglobal.net>]

"Ed Falis" <falis@verizon.net> wrote in message 
news:PM000438DC8E87815A@tilopa.unknown.dom...
>
> Which does not contradict my statement in the context of the times.
> Despite the superficially "fair" wording of the memo, it was almost
> universally interpreted as DoD walking away from Ada.  One of my
> colleagues was at a meeting recently where some yoyo got up and said
> "Thank God we got rid of Ada"!  Probably because that was the "cool"
> view among those who felt oppressed by the mandate (largely in terms of
> their short-term profit margins).
>
> - Ed
>
I published an article in Crosstalk several years ago that attempted to clarify
Mr. Paige's intent.   I even sent him a draft of the article for his approval 
before
publishing it.   He agreed with my assessment and the content of the article.

His original hope was that, having been proven successful in a lot of DoD
projects, Ada would stand on its own and be chosen without the coercion
of a DoD mandate.   It has been suggested by some that there was a lot
of "behind the scenes" influence from DoD contractor executives to get
rid of the Ada mandate.  There may have been some of this, but there
was also a lot of controversy generated in other quarters.

Some people in this forum may recall the flurry of email and forum postings
from some pipsqueak (I cannot recall his name) who constantly bombarded
Mr. Paige and other DoD executives with diatribes about both Ada and their
management of Ada.   It did not help at all that some former AJPO officials,
in particular Don Reifer, became turncoats and used their visibility in the
software industry to publicly denigrate and discourage the use of Ada in
DoD publications such as Crosstalk.

I used to do a lot of training and consulting for Lockheed and CSC related
to the Aegis project.   Soon after the Paige memo, Lockheed dictated that
the software for Aegis would be written in C++ instead of Ada.  Almost all
training in Ada stopped, and the programmers were given intensive training
in C++.   I told everyone that it was a big mistake, but my advice was of
little interest to those who were already biased toward C++.   The answer
was, "We can find C++ programmers right out of university CS programs,
but no one teaches Ada in CS."

A lot of the early frustration with Ada 83 was justified.   There were things
one could not do easily with it.   Some of the work-arounds required on
some projects were horrible.   There was no language defined data type for
unsigned integers and I recall a project where that took a lot of time away
from the programming effort just to invent a work-around.    Hobbyists,
many of whom were more influential than anyone realized, found they could
not easily format a simple MS-DOS screen with most compilers.   The
compiler vendors resorted to ANSI.SYS, which was simply another
work-around.    Alsys did have a special package that supported an unsigned
integer, and I recall a USMC project where we were able to access B800(Hex)
area of memory to directly access the video display mapping.

With Ada 95, a lot of things got better.  We no longer had to make excuses
for, nor invent work-arounds for, that lack of inheritance.   It does not matter
who made the mistake of excluding inheritance from the language in the first
place.   I remember many discussions where I was defending Ada 83
because it did not support extensible inheritance.  As it turns out, we still 
don't
use inheritance that much for safety-critical software anyway.  And we
certainly don't use dynamic binding.

In spite of the good efforts of people like Ed Falis and Ben Brosgol at Alsys,
commercial adoption was a failure.   In fact, it was due to the efforts of those
two people that Ada 95 did become hospitable to commercial and business
data processing applications.   Unfortunately, the compiler publishers ensured
that no one in the commercial world would use Ada by:  1) pricing the compilers
so no one could afford them, and 2) separating Ada from the rest of their 
product
line by relegating it to a sales option for their Federal division.   At IBM and
Rational, very few people on the commercial side of the sales force had any
knowledge of Ada.

The consortiums (ARA, etc.) found a way to waste money on some of the most
absurd ad campaigns ever launched.    Does anyone remember those ridiculous
ads in the late 1990's.   That was money down the drain.

Ada continues to be the best option for safety-critical and military weapon
systems.  I work in a DoD organization and try to promote it whenever I
can.  My reasons for promoting Ada for DoD software have little to do with
Ada, per se, but with my concern about the dependability of software that
must work right everytime it is used.   With Ada we have a better chance
of achieving that goal than we do with C or C++, or even Java.   I have even
been called an "Ada bigot," and sometimes described as a "throwback" for
my views on programming language choice.

As nearly as I can tell, my continued advocacy of Ada for DoD software puts
me in a very small minority of the "quaint but tolerated" software community.
Most of my Ada-knowledgeable colleagues have given up the fight and gone
on to other things.  They have concluded that C++ is good enough; Java is
good enough;   Python is good enough.    One of my students told me recently
of a flight-control system on one of our military aircraft where the software
is written in VisualBasic.  I hope he is wrong.

When the Paige memo came out, I commented in a public article (in JOOP) that,
if the DoD cannot manage a single language policy, how do they expect to manage
a multiple-language policy.  They can't.   They have decided to let the 
contractors
make the choice.  The long-term consequences of this abrogation of 
responsibility
will be dire, but no one seems to care.

I realize that many in this forum are not concerned with warfighting software. 
Perhaps
the commercial software you are developing will make enough difference that some
of those in the DoD who need to understand the issues of software 
decision-making
will come to their senses when they see the results of your work.    However, it 
is
too late for influencing the DoD contractors.  They are now free to use any 
language
they wish, including some proprietary language they might invent or extensions 
to
some existing language that no one else knows about.

The Paige memo did its damage.  Now we need to find some way to repair that
damage.   It might be too late.   On the bright side, SPARK is "sparking" 
renewed
interest in Ada -- as long as we don't call it Ada.

Richard Riehle