From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,bbba36730ac96f9a
X-Google-Attributes: gid103376,public
From: demer@cdfsun03 (David Emery)
Subject: Re: Gov't, non-DoD use of Ada (C-based COTS no excuse...)
Date: 1996/09/17
Message-ID: <DEMER.96Sep16212222@cdfsun03>#1/1
X-Deja-AN: 181068168
references: <4vnlgn$mko@uuneo.neosoft.com> <JSA.96Sep10141151@alexandria>
organization: Hughes Aircraft Company
newsgroups: comp.lang.ada
Date: 1996-09-17T00:00:00+00:00
List-Id: <comp.lang.ada>


>COTS, modified or not, pretty much pushes you into use of C, as the vast
>bulk of existing NDI/COTS code available and suitable for ATC is written
>in C.  I think many systems will end up with mixtures of C and Ada, as
>it's almost never cost effective to rewrite working fielded code just
>because it isn't in the language of choice, whatever that might be. 
>Adding support for an additional language is orders of magnitude cheaper
>and less risky than rewriting a few hundred thousand lines of code.

I agree with the second point, but I think that the excuse that "the
COTS is written in C, so we have to write the application in C" is a
technical and managerial red herring.  

In 12 years of implementing Ada bindings to COTS written in C (I
started doing this with Vads/Ultrix 4.0.6 in 1984...), I've found that
there were very few situations where I couldn't construct an effective
Ada binding to the C-based COTS.  And, more importantly, the Ada
binding development costs more than paid for itself in reducing
debugging time.  

In one example, the MITRE prototype binding to XVT, the team estimated
that the Ada binding prevented or trapped most of the interface bugs
with XVT.  For instance, where the C implementation used a union, we
used a variant record.  We caught several 'type mismatches' via a
constraint_error on the use of a discriminant value that did not match
the expected discriminant (e.g. trying to pass a field when a button
was expected.)  In C, these would have been much harder to discover.
And, we found several bugs in the COTS product by trying capture and
'project' the COTS C-based semantics into Ada.

My guesstimate was that we recovered the 4 staff-weeks it took us to
do the Ada binding in 2 months of using the binding, and this on a
5-person project producing only 20ksloc of code as a subset/prototype.
For 'real development' (the system we subsetted was about 150ksloc
with full functionality), the Ada binding probably had at least a 5-1
return on investment, mostly in reduced debugging time, but also in
increased understanding of the underlying COTS product.

Where I'm working now, we have developed (or had the vendor develop)
several Ada bindings to COTS products for GUI, digital mapping, etc.  
Although some of the bindings were not done the way I would have done
them, in all cases they have been "in the noise" with respect to the
overall product costs.  And I've been the benificiary of a lot of bugs
that were prevented via strong-typing/compiler errors, or that were
caught early with an appropriate error message, by our Ada bindings.  

And I -am- working in the ATC domain!

				dave
--
<.sig is away on vacation>