Newsgroups: comp.risks
X-issue: 6.37
Date: Sun, 6 Mar 88 00:11:03 EST
From: mnetor!utzoo!henry@uunet.UU.NET
Subject: Re: Ada-caused bugs?    [RISKS-6.36]

> [Ada's] complexity makes it ripe for misuse.  It is nominally mandated for 
> all military embedded systems, except that various limitations have resulted 
> in its being eschewed in some security-community applications...       [PGN]

Considering Ada's application domain (and my personal dislike for Ada), I
laughed long and hard when I noticed the following quote in the first issue of
the new journal "Computing Systems" (Marc H. Donner and David H.  Jameson,
"Language and Operating System Features for Real-time Programming", Computing
Systems vol 1 number 1, winter 1988, pp 33-62):

     Ill-chosen abstraction is particularly evident in the design of
     the Ada runtime system.  The interface to the Ada runtime system 
     is so opaque that it is impossible to model or predict its 
     performance, making it effectively useless for real-time systems.

(Donner and Jameson are with the IBM Thomas J. Watson Research Center;
the paper is very interesting.  Computing Systems is being published by
U of California Press for the Usenix Association.)

Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Date: Wed, 10 Oct 90 12:59:53 EDT
From: henry@zoo.toronto.edu
Subject: Re: Ada and multitasking

> The author does not seem to realize the contradiction between the
> *reliability* and *portability* quoted as features of Ada on one hand, and
> the lack of definition of crucial features on the other.

There is no inherent contradiction here, unless "reliability" and "portability"
are taken to include the phrase "guaranteed or your money back".  (Mind you,
some of the Ada enthusiasts essentially do claim this.)  "Reliability" and
"portability" are not absolutes, especially in a language constrained to be
implemented efficiently on current machines.  If such constraints mean that a
particular feature is not completely defined, this just means that
reliable/portable programs must avoid depending on it.  This does require
competent programmers, however, and one gets the impression that some of Ada's
big backers hoped that their wonderful language would do away with the need for
competence.  After all, it's much easier to run a test suite through a compiler
than to decide whether a programmer is competent.

The C community regularly sees broadsides on the subject, with ignorant people
claiming that the large number of "implementation defined" or even "undefined"
items in ANSI C implies that C programs cannot possibly be portable or
reliable.  Not so; these are just indications of where the programmer must
avoid depending on implementation-dependent behavior.  (There is room for
legitimate debate about whether C expects too much from its programmers, but
that is a different issue.  Portable, reliable C code is verifiably possible.)
C gets more of this than Ada, because C is a rather unforgiving language meant
for people who know what they are doing, but almost any efficient language will
run into similar issues.

To draw an analogy from more traditional engineering, the basic art of
designing circuits with transistors is organizing things so that the
characteristics of individual transistors do not affect the outputs much.
Transistor characteristics are quite variable, especially if you want the
transistors to be cheap.  This does not make it impossible to design transistor
circuits with predictable properties.  It merely requires that designers take
care to use circuits that allow for the variability and cancel it out.

     Henry Spencer at U of Toronto Zoology  henry@zoo.toronto.edu  utzoo!henry