Re: DoD dumps mainframe for PC network using C software

[world!srctran@uunet.uu.net (Gregory Aharonian)]

>  >    Here we see why Ada is in so much trouble, when an office deep in the
>  > Pentagon can develop two large, heavily used systems using C-based COTS
>  > software and C-based application development.  This system could have been
>  > done in Ada, had they cared and respected the Ada Mandate...

>  Greg, read the policies carefully before making statements like
>this.  While I would have preferred that Ada had been used, the
>policies are designed to enourage use of, existing software, COTS
>software and SQL.  All of the various Ada policies have exceptions
>designed to avoid conflicts with these other policies.  This looks to
>me like an example of complying with government mandates, not of
>ignoring them.

   To me, this looks like a case of conflicting mandates.  What happens
when all DoD software needs can be met cost-effectively by COTS software,
none of which is done in Ada?  Then one mandate, COTS, effectively renders
useless another mandate, Ada.
   Think of the following domains: communications, networking, databases,
GUI, parallel processing, expert systems, natural language analysis,
multimedia, CALS, VHDL, SGML, EDI, etc.  Such software applications make
up a large fraction of DoD programming that cannot be done more cost
effectively in Ada - the COTS stuff is just too good too well priced.
When such a large percentage of DoD needs can be met with non-Ada costs
products, the all encompassing nature of the Ada Mandate (which does say
ALL DOD PROGRAMMING) becomes irrevelant.
   So sure, I want DoD officials to be cost effective.  It's just that the
assumptions made about Ada's cost effectiveness vis-a-vis other languages
made many years ago are no longer true, and thus the rationale for the
all encompassing Ada mandate.
   The problems is not COTS, nor the Ada language, but unrealistic
assumptions underlying the Mandate.  Either redefine it or drop it, but
as it is, it is only followed when it is convenient.

Greg



-- 
**************************************************************************
 Greg Aharonian                                      srctran@world.std.com
 Source Translation & Optimization                            617-489-3727
 P.O. Box 404, Belmont, MA 02178