>   The Zeigler report at
> http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html
> looks like good data.  Why was it not 'adequate'?  Was conflicting data
> presented?  Is it analogous to smoking and lung cancer in that some folks
> will never consider it adequate in their lifetimes?

The Zeigler report is very good, but it describes systems software (pieces
of an Ada compilation system) running generally on Unix-like systems,
written pretty much from scratch, and integrated only with other systems
software written by the same company.  For this kind of environment,
Ada is an excellent choice, especially compared with writing in some
other less reliability-oriented 3GL.  However, this does not make a compelling
argument for (or against) Ada in other kinds of environments, such
as building an accounts payable system.  Whether Ada is the right
technology base for building an accounts payable system depends a great
deal on who is doing the building, what parts they are starting with,
what tools they have available in the domain, etc.

>   Or perhaps 'cheaper and less buggy' isn't really important?  Is part
> of the argument for COTS that 1/N of the cost of a system that's very
> expensive is still less than 1/n of a cheaper system if N >> n?  What
> about the cost to each customer (as opposed to the cost to the vendor)
> of more bugs?  Are we Ada-philes simply mistaken in our implicit
> belief that quality is cost-effective?

Quality is a great thing.  However, if by using some other technology
(e.g. YACC) one can build, e.g., a more reliable parser, then writing a
parser by hand in Ada may end up losing out, because more code needs to
be written by hand.  Even though each line is less likely to be wrong, the
number of lines written is sufficiently greater as to defeat the per-line
advantage.  Of course, there are ways to integrate YACC and Ada, and that
might be the best choice for a parser.  Or writing the parser from scratch
in Ada might be the best choice, because you end up with more flexibility,
presuming you have the knowledge and time to create a good parser this way.

In any case, there may be other commercial tools which do not
integrate well with Ada, or for which the time to create, maintain, and
enhance the Ada-supportive glue would outweigh the advantages.
The point is not that Ada might not be the right choice,
but rather that there are a sufficient number of other considerations,
that one should consciously choose Ada in such domains, not have it
mandated from above.  The inherent heterogeneity of a system in such
a domain has already reduced the other indirect benefits of a mandate,
such as homogeneity of tools and methods and maintenance approach.

If requiring the use of a particular 3GL interferes with the ability
to use the best available tools, it is important for the advantages
of that 3GL to be weighed against the size of that interference, as
estimated over the lifecycle of the project.  Mandates can end up
short-circuiting that kind of analysis, potentially resulting in a
product that does not meet its quality goals within the resource
constraints, or that is too costly to maintain and enhance.

-Tucker Taft  [log in to unmask]