Brian Wichmann on "High Integrity" C++ vs Ada

Brian Wichmann on "High Integrity" C++ vs Ada

[Mike Berens]

Terry Bollinger wrote:

> Hi folks,
>
> Interesting dialog.  My own background in languages includes using pre-Ada
> at McDonnell-Douglas Astronautics back in 1981.  I created the very first
> version of their Ada Design Language, or ADL, for whatever that's worth,
> and later I worked for Chris Braun while she, Bob Mathis, and Ishbiah's
> (sp?) group competed against Biggerstaff group for Ada 9X.  (Bob Mathis
> advocated a more conservative, fewer-changes approach than Ada 95 used.)

I was keen to see Ada 95 smaller, but I assure you the result is amazingly
good!

> (1) I personally applaud NIST for taking on ugly, unpopular C and C++
>     issues, because improvement in this area is so desparately needed
>     in the industry.

This makes the assumption that C or C++ can be improved!

>                      I would at the same time agree that the idea of
>     using a language such as C++ for nuclear reactor control doesn't
>     seem like a very good idea.  It's too complex and very difficult to
>     validate meaningfully, especially when designers make heavy use of
>     features such as includes that can bring in whole worlds of unknowns.

Agreed!

>     On the other hand, I rather suspect has happened in many critical
>     software applications in the past has been not a choice between C
>     and Ada, but between assembly languages and C.  While C is not too
>     much farther from the machinery than assembly language, it has the
>     distinct advantage of being decently readable -- which in turn makes
>     it significantly easier to verify during the crucial human-examination
>     phases of the overall validation process.  Given a choice of the local
>     reactor being worked up in C versus assembly, I'll take C any day --
>     but with a strong preference noted for the box marked "other".

The trouble is that some people think C is a high-level language rather than
a machine-independent assembler.

> (2) Ada caused many of its own acceptance problems by making it harder,
>     rather than easier, to validate time-critical processing software.
>
>     It is truly a shame that the selection of the Green (vs, say, the
>     Red) language in the original Ada language selection pretty much
>     tossed out the idea of time-slice design at the language level in
>     favor of the frightenly unverifiable rendevous mechanism.  When
>     they did that they made the original Ada into a language that was
>     rather fundamentally unsuited for the very class of time-critical
>     operations that was one of the original goals of the language.

Shame! As a member of the Green team I can hardly agree. I do agree that
the rendevous mechanism was untried, but it got very little criticism at the
time. Moreover, it is always open to developers to use another mechanism
for concurrency, and in Ada 95 there is a choice within the language...

>     If you want to assign blame for why the original Ada never got used
>     as much as it might have for real-time, embedded, and mission
>     critical software applications, I think some very real blame must
>     be laid on the Ada selection process itself for in effect setting
>     back the ability of designers to validate the temporal performance
>     of their software.  Since C never did that, I don't find it too
>     surprising to hear that it was selected for some applications in
>     which the ability to respond in a timely fashion was the key issue.
>     (I don't necessarily agree with it; I simply understand why it could
>     have happened, and why it could very well continue to happen.)

People who make that decision are clearly wrong, since concurrency usually
only affects 5% of the code. The other 95% is the important bit, provided
the 5% can work within the time constraints.

>     Hopefully Ada 95 will resolve some of these issues after its quite
>     significant number of differences become better understood.  That
>     shouldn't take more than 3-5 years for the community as a whole,
>     with pockets of deeper understanding developing within a year or so.

Yes. GNAT is helping a lot...


> (5) I agree that Ada (both old and 95) is too big for safe validation.  The
>     complexity of the language is too large for many programmers to fully
>     hold in their mind at one time, and it provides too many ways to do
>     exactly the same thing.  Both of those are quite scary when it comes to
>     the absolutely critical human-based validation phases, since somebody
>     somewhere _is_ going to overlook or misunderstand some point of syntax
>     or semantics that will later prove to be critical to software behavior.

The solution to the size of Ada is not to use the entire language. There are
lots of Ada 83 highly critical systems being used today. All use a subset of
the language that is designed for IV&V.

>     Ditto several times over for C++, which is so large, syntactially ugly,
>     and muddled between funnctional and object styles of design that I
>     cringe whenever I hear of a project that is trying C++ for the "first
>     time".  You can bet that some interesting schedule disasters will soon
>     follow -- and I don't even want to think of validation in such cases.

I agree. IV&V for C++ is not credible.

> (6) If my life depended on it (which in the case of nuclear reactors it
>     might), I would much prefer to see a small language with strictly
>     rigorous dependence on _one_ programming paradigm (such as object-
>     oriented), versus the mix-and-match approach that both Ada and C++
>     have used.  I would also keeping the interface to real-time environment
>     as transparent and automated as possible, since more errors come from
>     programmers trying to "use things" such as memory allocation than from
>     the applications per se.  (Yes, the rendevous is exactly that sort of
>     a mechanism, and performance is still an issue.  But computer power
>     is up a couple of magnitudes since the early 80s, so maybe its time
>     has come.)

This is exactly how current systems are written in Ada. Using a small subset
and sticking to one style.

>     Could that language be a formally (machine) enforced subset of Ada 95?
>     Maybe.  But I don't think its the whole language.

The HRG is the Ada group looking after Annex H which handles high integrity
systems. A formally defined subset is technically feasible, but a practical
impossibility to agree (it seems). Hence we (the HRG) are working on guidance
which ranks features in terms of how appropriate they are for critical systems.
It is not easy, but I hope we will have a clear vision of the guidance that
we can and should produce at our next meeting in October. We do have access
to a detailed study of Ada 95 undertaken in Canada.

Brian, Convenor of the HRG.


-------------------------------------------------------------
Brian Wichmann                Tele: +44 181 943 6976 (direct)
National Physical Laboratory   FAX: +44 181 977 7091
Teddington Middlesex           e-mail: baw@cise.npl.co.uk
TW11 0LW
UK

WWW: http://www.npl.co.uk/npl/search/staff?Dr+Brian+Wichmann
-------------------------------------------------------------