Re: Govern.Comp.News editorial says "Drop Ada Mandate"

Re: Govern.Comp.News editorial says "Drop Ada Mandate"

[munck]

>From the August 2, 1993 issue of Informationweek, page 6.

>The technical arguments can go on forever.  But economical,
>commercial alternatives to Ada exist for building secure,
>reusable, well-documented code and doing the development in
>a measurable, disciplined environment.  Ada isn't a bad
>language, but events have simply passed it by.

Any thoughts on what these alternatives might be?  Although I
do believe that it's _possible_ to write "secure, reusable,
well-documented code" in _any_ language including FORTH, CMS-2,
and APL, it's clearly harder in some languages than others; C
and C++ make it harder in each category to the point that it is
unreasonable to expect the typical DoD contractor programmer to
do so.

Therefore C and C++ are NOT possible alternatives.  What is?
Modula-2?  Pascal?  TURBO-Pascal?  Of these I can only make a
case for M2, which is currently much less widely used than Ada.
So what's the argument against Ada?


>There's a message in the fact that Ada has never developed a
>commercial following.  Why should DoD be saddled with it,
>especially when the military is trying to get rid of many
>other military specifications?

At CASE'93, the wrap-up panel was titled something like "Is
CASE a Failure?"  The use of CASE tools and environments may be
about as wide-spread as the use of Ada (and may be 50% or more
the same users).  Clearly, however, the lack of popularity of
CASE is not caused by the unpopularity of Ada; they may both
have the same cause.

It is my opinion that this cause is the short-sightedness that
is increasingly built into American commercial management.  Ada
and CASE are not used because of a (real or perceived) upfront
cost that is not balanced against the long-term benefits.  In
fact, the world of PC software is so volatile that most of the
long-term benefits may actually never be realized; a company
will either fail or grow so quickly that it can afford to
devote inordinate resources to maintenance and enhancement. 
(Of course, nothing lasts forever.)

Although they sometimes do, the US Government and the DoD in
particular cannot work this way.  The success of a DoD software
project is not based on the ratio of sales to development cost,
but rather on usability and life-cycle cost.  "Usability" often
includes not causing loss of human life.  Given this huge
difference, I don't see how a case can be made for the DoD
using C just because commercial companies writing things like
computer games do.  It's the equivalent of saying that the Air
Force shouldn't have supersonic airplanes because no commercial
American airline does.

(BTW, I personally put much of the blame for industry's lousy
long-term management on Ronald Reagan and the Harvard Business
School.  Some may argue with that, but please not in Info-Ada
or c.l.a).

Bob Munck

Re: Govern.Comp.News editorial says "Drop Ada Mandate"

[agate!howland.reston.ans.net!europa.eng.gtefsd.com!darwin.sura.net!seas.g]

In article <22430.744913371@blackbird> munck@STARS.Reston.Paramax.COM writes:
>
[good stuff deleted]

>Although they sometimes do, the US Government and the DoD in
>particular cannot work this way.  The success of a DoD software
>project is not based on the ratio of sales to development cost,
>but rather on usability and life-cycle cost.  "Usability" often
>includes not causing loss of human life.  Given this huge
>difference, I don't see how a case can be made for the DoD
>using C just because commercial companies writing things like
>computer games do.  It's the equivalent of saying that the Air
>Force shouldn't have supersonic airplanes because no commercial
>American airline does.

Hear, hear!
>
>(BTW, I personally put much of the blame for industry's lousy
>long-term management on Ronald Reagan and the Harvard Business
>School.  Some may argue with that, but please not in Info-Ada
>or c.l.a).

Oh, I second that. Flames by e-mail, or better to /dev/null.

Mike Feldman

Re: Govern.Comp.News editorial says "Drop Ada Mandate"

[Mike Bates]

Bob Munck (munck@Stars.Reston.Paramax.Com) said:

>It is my opinion that this cause is the short-sightedness that
>is increasingly built into American commercial management.  Ada
>and CASE are not used because of a (real or perceived) upfront
>cost that is not balanced against the long-term benefits.  In

At my old job, I used CASE tools on a DOD/Ada/2167A software
subcontract.  The company paid for a week of training by the vendor
(Cadre).  Although the training was helpful for understanding the
methods behind the tools, I found that Teamwork did not fit very well
into the process of 2167A development and Ada design.  In particular,
Teamwork provided no assistance in reusing the data developed in
requirements analysis in the detailed design phase.  We ended up using
DEC's Language-Sensitive Editor and Source Code Analyzer for detailed
design and report generation.  The Ada compiler turned out to be a far
better check on design consistency and completeness than Teamwork's
Ada diagramming tool, and the Source Code Analyzer' report generator
was fully customizable.  Text seemed to be a more natural means than
diagrams to express the state of our design.

Were I to have the opportunity to specify a software environment on
another 2167A program, I'd encourage management to skip on the
CASE tools and spend money on a good document publishing package and a
language-sensitive editor.  When CASE vendors demonstrate that they
understand the requirements of Ada/2167A development, I'll be happy to
take another look.  There is a place for automation, but companies
have good reason to be skeptical of CASE at its current level of
(im)maturity.  

(I should mention that we didn't get to make full use of IDE's
Software through Pictures on the earlier project.  Their environment
seemed to allow for much more tailoring, the user interface was, in my
opinion, easier to use than Teamwork's, and the training course was a
good summary of both concepts and mechanics.)

>(BTW, I personally put much of the blame for industry's lousy
>long-term management on Ronald Reagan and the Harvard Business
>School.  Some may argue with that, but please not in Info-Ada

I personally put much of the blame for the midwestern floods, Teapot
Dome, the assassination of Archduke Franz Ferdinand, the fall of
Constantinople in 1453, and eruption of Vesuvius on Ronald Reagan.
Why not?  Everything else seems to be his fault....

>School.  Some may argue with that, but please not in Info-Ada
>or c.l.a).

If you don't want people arguing politics in c.l.a, don't go making
irrelevant political statements.  This group is political enough as it
is.  


--
------------------------------------------------------------------------------
Mike Bates               FlightSafety International, Simulation Systems Div.
Principal Engineer       2700 North Hemlock Circle
Computer Systems Group   Broken Arrow, Oklahoma 74012
mikeb@ssd.fsi.com        918-251-0500 ext. 581
------------------------------------------------------------------------------
-- 
------------------------------------------------------------------------------
Mike Bates               FlightSafety International, Simulation Systems Div.
Principal Engineer       2700 North Hemlock Circle
Computer Systems Group   Broken Arrow, Oklahoma 74012
mikeb@ssd.fsi.com        918-251-0500 ext. 581