Re: Bye-bye Ada ?

[Richard Riehle <richard@adaworks.com>]

Hyman Rosen wrote:

> Richard Riehle wrote:
> > I realize the Mr. H. Rosen will disagree with this viewpoint.
>
> On this day, I find it hard to summon much energy for a language war.
> I know *I* can write reasonably good software in C++. When we have
> errors, it's due to problems in logic, not problems in the language.
> But anyway, fine. Don't program in C++, do what you want.

Ah, and there's the issue.   It is not that I want do program in Ada
instead
of something else.   If I had my druthers, I'd probably use Smalltalk.
The
issue is not my preference, it is about choosing the correct tool for the

job to be done.

It is also not about whether someone who is an expert using a particular
set of tools can do the job better than someone who is not an expert.
During
a trip to Japan, I watched an expert in Japanese Joinery create the
components
for a Temple using only hand tools, his keen eye, and his many years of
experience.   Each component fit together with a perfection few others
could achieve, even with more years of experience.   This is an example
of craftsmanship that few could match.

In my view, C++ is too prone to errors, even when used by experienced
craftspersons.   Those with the skill of the Japanese Joinery expert
cited
in the above paragraph are likely to produce defect-free code.   We
cannot
depend on that level of expertise.  It is rare.  It is unpredictable. It
is
not easily confirmed.   The more C++ code I see, and the more programmers

I see trying to use it, in particular, for weapon-systems, the more
concerned
I have become about the potential for failure due to unpredictable
behavior
in the resulting code.   It is so easy to compile a C++ program that
behaves
strangely after executing for some unspecified period of time.

My preference for Ada is not made out of ignorance of the other options.
It is made because I have discovered that defect-free software is best
created when the creational tools assist in preventing defects.   At
present, it is not a matter of _can_ we create defect-free software in
C++.  We certainly can.   It is, rather, what is the probability of the
code being defect-free in C++ and in Ada.   In my view, there is
a greater likelihood of producing defect-free software in Ada than
in C++.

It is not only a matter of reducing defects.   When I look at Ada and
then at C++, I realize that Ada provides other substantial benefits. In
Ada, used well, I achieve a greater level of traceability than I can
achieve in C++.   Without resorting to embedded comments, I can
code in Ada so the meaning of each construct is intuitive, unambiguous,
and absolutely explicit, and do it more effectively than I can with
C++.

As I compare the two languages in terms of long-term maintenance,
it becomes clear, to me, that Ada supports this important goal far
better than C++.   It is more readable long after being created. There
are far  fewer little gotchas than I might expect in corresponding C++
code.

From where I sit, when making a decision about software that needs
to live a long time, must be maintained over a long time, must work
as predicted for a long time, it is clear that I must choose Ada over
C++.  It is the responsible thing to do.

I don't know how well you know Ada.   I do know C++ well enough
to realize that one can do some interesting and powerful designs
with it.  We, you and I, do agree on the merits of the Alexandrescu
approach to using C++.   However, even when choosing the valuable
design counsel from people such as Alexandrescu, Koenig, and Myers,
I still find the reliability gap, early in the development process, too
large to trust C++ for weapon systems -- systems that mean the
difference between life and death.

I don't care what language someone uses for run-of-the-mill software.
I might even choose C++ for that myself.  In fact, I sometimes use
Visual C++ in my day-to-day programming.   But I do care about
which language we choose when human safety is an issue.  So far,
Ada seems to come closest to being the correct choice.

Richard Riehle