On Fri, 8 Nov 1996, Tucker Taft wrote:
> 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.
There are a number of ex-COBOL programmers who based on their experience
implementing an ARMY accounting system STANFIN's in Ada who came to
believe that Ada was superior in this financial application.
Ada features like:
- grouping data and its associated subprograms into packages
- separation of interface specification from implementation
- strict control over the representation of data without loosing
the ability to work with it at an application level
make Ada well suited for any domain where a solution has to be
robust and maintainable.
> > 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.
One can argue that commercial tools will never integrate well with Ada if
DoD (it's originator & specifier by "policy") does not insist that ALL
commercial tools that they purchase support Ada. Even if the DoD had to
pay for developing an Ada interface the first time a commercial product
was used that required it, the life-cycle costs of the resulting system
would likely still favor Ada as a cost effective solution. In addition,
the next time the government bought the product, an Ada interface would be
Yes, there are cases where Ada may not be the "right" choice, but
it was my understanding, that was the reason DoD had a waiver policy.
The real difference between the current Ada policy (at least on paper) and
that proposed by the NRC study is that before Ada was designated the
language of choice until the project proved otherwise.
> 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]
Do you really expect the NRC's recommendation for performing a technology
trade-off analysis will result in the choice based on scientific or
Sr. Software Engineer
W (301) 640-3632 (in person M-F: 9am-5pm EST, voicemail any time)
Fax -4750 or -4940