Re: Current status of Ada?

[<adaworks@sbcglobal.net>]

"Gary Scott" <garylscott@sbcglobal.net> wrote in message 
news:yWgCi.852$4J3.839@newssvr22.news.prodigy.net...
>
> But part of the issue has been unhappiness of the programmers themselves. 
> When told that they would have to program in Ada, the C programmers were 
> turning down job offers.  Not because they couldn't pick up Ada, but because 
> they wanted to keep their C skills polished in case they found a better 
> position elsewhere.  You do get rusty from non-use, and you fall behind the 
> latest standards over time.
>
I have heard this argument from the so-called managers who were using
it as an excuse for not using Ada.    When the interviewing manager says
something such as, "Of course, in our shop you will be programming in
Ada instead of C.   I know this is a little bit out of the mainstream, but
the government programming we do requires us to use Ada."  Or some
similar line of apologetic interviewing, what can we expect.   Yes.  Too
often, the managers would apologize for using Ada instead of focusing
on the benefits of using it.   And there are a lot of benefits.  Adam mentioned
the software engineering benefits, and those benefits are substantial.

When I was just a programmer, even a programming manager, before discovering
Ada, I did not really understand software engineering very well.   Most of what
passed for (and still passes for) software engineering was the adoption of 
Industrial
Engineering protocols on the software process.   There was very little of what
any real engineer would call engineering.    I have Ada to thank for helping me
rise above the programming model that I had been stuck with for so many years.

Hardly anyone engineers software in C.   Very few really use C++ to engineer
software solutions.   As long as we remain tied to the notion that programmers
are the driving force in the software process, we are doomed to a long nightmare
of horrible applications where debugging is the norm and design is the 
exception.
If C++ is the answer, someone is asking the wrong question.

Where C is often called a "universal assembler,"  C++ is an object-oriented
assembler, and not as universal as C.    If software engineering is, in part, 
about
levels of abstraction, C++ is at a very low level of abstraction.   As long as 
we
continue to think of software in terms of computers instead of in terms of the
required solutions, we will be stuck with a model of software that continues
to focus on the low-level issues.

When I first began to learn Ada, coming to it as an old-fashioned programmer,
it was a strange and difficult transition.   My first inclination was to look 
for ways
I could leverage Chapter 13 for my code.    It took a while to understand the
finer points of the language.  Once I was able to understand those, it seemed
strange to me that I used to write programs in a different way.

Sadly, those LMCO managers on Aegis who made the decision for C++ instead
of Ada simply don't understand Ada.   They are still thinking in terms of 
programming
languages, not in terms of engineered software.   This is true of most of the 
DoD
contractors I have known over the past twenty+ years.   They have no idea of the
benefits of software engineering, something they can do with Ada better than 
with
most other options.   It is a matter of ignorance, nothing more.    If they did 
understand
the difference, there would never have been abandonment of Ada in favor of C++.

So, instead of learning how to apply good software engineering principles, most 
of
them have behaved like human lemmings, blindly following the idiotic choices 
made
by those in the software industry who also know little about engineering, but a 
lot
about programming.

Until the DoD, and industry in general, begins to take more of an engineering 
approach
to the development of software, we will continue to wrestle in our bedclothes 
with
the software nightmares that continue to haunt us, only to wake in the morning 
and
discover that our best efforts to control those nightmares have consummated 
themselves
in nothing more than a simple wet-dream.

Richard Riehle