LISTSERV mailing list manager LISTSERV 16.0

Help for TEAM-ADA Archives


TEAM-ADA Archives

TEAM-ADA Archives


TEAM-ADA@LISTSERV.ACM.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEAM-ADA Home

TEAM-ADA Home

TEAM-ADA  November 1996

TEAM-ADA November 1996

Subject:

Re: FW: OSD C4I Commissioned Ada Study Complete by NCR (fwd)

From:

James Squire <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Sun, 3 Nov 1996 22:24:26 -0600

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (181 lines)

AdaWorks wrote:
>
> Some of you teamers have not seen the report. I am forwarding what
> I received from OTG

Thank you for posting this.

> What should the Department of Defense do about the Ada
> programming language?  Despite the languages technical
> capabilities, it has not been widely used outside of
> military and other safety-critical applications, as was
> hoped when the language was developed in the 1970s.  The
> Defense Departments policy on programming languages, which
> requires the use of Ada for all new software development,
> has resulted in many conflicts and has not been implemented
> evenly.

I still don't understand the reasons why this happened, and why it is
continuing to happen.  I see the future of Ada within my company falling
by the wayside, and the inconsistency in enforcement (not to mention
outright rejection in some quarters of the military) only makes it
tougher to keep that from happening.  When your customer of all people
asks YOU to seek a waiver, a company like mine has no problem shrugging
its shoulders and going along with it.  It is like a drug habit that is
aided and abetted by well meaning but destructive friends who cover.

> The committee concluded the vigorous support of Ada would
> benefit warfighting systems, and recommends that the
> Department of Defense should continue to use and promote Ada
> in such systems.  However, the committee found significant
> problems with the two primary components of the Defense
> Departments current strategy for Ada.  First, the current
> programming language policy requires the use of Ada for all
> new defense software, which the committee finds to be overly

I take it then that the committee feels that if they just narrow the
scope, then such a more focused policy will naturally be consistently
enforced?

I am suspicious of this, because I sense that there is a fundamental
aversion not just to the Ada policy, but to the Ada language itself.  Of
course, one would think that within the military arena the chain of
command would take care of this, but apparently it doesn't.

> broad in scope.  Second, the Defense Departments plan to
> discontinue investments in both Ada technology and user-
> community support will weaken the Ada infrastructure, and
> will work against any requirement to use Ada in the future.

Now this is interesting.  Is that what this whole debate is about,
making sure the DoD continues to invest in Ada?  By the way, I need some
clarification.  At WAdaS'96, I thought everyone who represented the
interests of Ada was *happy* to have AJPO out of the picture.  Perhaps I
am missing a piece of the puzzle or a couple of distinctions here and
there.  I distinctly remember Oliver Cole was quite pleased that AJPO
was disbanding.  If I am confused (and I have a vague sense that I am),
please enlighten me.  I am doing the best I can to understand.

Meanwhile, on a perpendicular slant, if the DoD is to become a follower
instead of a leader where Ada in the commercial market is concerned, to
me this means that we are going to see if Ada can survive in the free
market place.  This again sounds very much like what I heard at WAdaS
this year.

If that is the case, then IMHO the DoD has no business subsidizing a
language that it no longer has a vested interest in (other than as a
user).  When the government funds research, it should get direct benefit
from it, and I assume this is what was happening (however haphazardly)
during the Ada Mandate years (violins playing in the background).  If
the Ada movers and shakers want the DoD to abandon Ada as the overall
standard answer to the software crisis, then I as a taxpayer have a
problem with those same people turning around and expecting said
customer to invest in a language (apart from buying related products for
its own use) that it no longer exclusively prefers.

> In summary, Ada and Beyond:  Software Policies for the
> Department of Defense concludes that the Defense Department
> should  take the following steps regarding Ada:
>
> 1. Continue to require Ada for its warfighting software and
> drop the Ada requirement for its other software.  In

Continue?  That is the question.  Define "warfighting software".  I see
stuff which to the "uninitiated" sure looks like warfighting (not to
mention safety critical) software being granted waivers (or well on
their way to), and I have trouble attaching any meaning to this.

> commercially dominated areas, using Ada is generally less
> cost-effective than using other languages.  Requiring the

So what good is Ada then, in the general marketplace?  Why do I feel (as
an Ada-knowledgeable person for going on 10 years) like the victim of a
bait-and-switch?  I have come to believe Ada to be the best language,
period, and surely in part based on the selling job done by Ada
advocates over that period of time.  Best for maintainability, best for
readability, etc., and all of this should translate to the bottom line.
The one example I saw where someone actually tried to back up the notion
that C/C++ is more cost-effective than Ada, produced a report that
didn't thoroughly examine all the implications of its own data.  Namely,
it ignored the potential cost savings due to fewer bugs found in the
field, by setting (intentionally or otherwise) its breakpoint for
cost-effectiveness at the time of release TO the field.

It would be different if Ada were considered to be less cost-effective
in certain areas, but if "Ada is *generally* less cost-effective than
using other languages", then either this statement is without foundation
or else the whole premise behind the Ada language has been a failure at
best and a fraud at worst.  That this conclusion comes from a committee
that includes several Ada advocates makes me feel even more confused and
disoriented.  I feel like a disciple whose messiah has just said, "April
Fool!"

> 2. Provide roughly $15 million per year for Ada
> infrastructure support, or drop the requirement to use Ada
> entirely.  The commercial marketplace will not sustain a
> robust Ada infrastructure.  However, a relatively modest
> ($15 million per year) investment at the margin by the
> Defense Department would be sufficient to sustain a robust
> Ada infrastructure for warfighting applications.  The
> Defense Departments inventory of more than 50 million lines
> of warfighting software must either be maintained in Ada or
> converted to another programming language.  The recommended
> investment is modest with this maintenance burden.

Let me try to put the best construction on this.  Do I take it that the
investment in Ada that the committee wants the DoD to continue with is
one which will benefit the DoD by ensuring that they continue to have
support from the Ada vendors for their Ada software, while at the same
time allowing those Ada vendors to get a needed boost to compete in the
commercial marketplace?

Well, ok maybe........  I don't know.  Eh.

On the one hand, this sounds a little like artificial price support
which means that Ada cannot survive on its own in the commercial
marketplace, which it probably can't from what I can tell.  But is Ada a
basic necessity of life?  Will the USA go into the crapper if the Ada
language falls into disuse and Ada vendors are forced to go into some
other line of work?  I think not.

On the other hand, it probably is unfair to single out Ada for this
critique.  Our whole country practically runs on this co-dependency
model.  Maybe there's little we can do to change it.

> In the course of this study, the committee also concluded
> that the currently available data are insufficient, on their
> own, to accurately determine the impact of programming
> language choice on the outcome of defense programs.
> Committee briefings also highlighted the difficulty that
> program managers have in finding data on which they can make
> informed decisions.  Based on the limitations of
> availability data, the committee has made an additional
> recommendation that the Defense Department institute a
> corporate effort to collect software metrics to guide future
> policy and management decisions.

Applause.  In fact, I would say that the big problem with the mandate
(hinted at in Tucker Taft's response to Richard Riehle's original
message that started this thread) is that it has functioned as a
legalistic solution to the problem.  The mere act of legislating Ada is
thereby thought to convince everyone that Ada is in fact the best
language.  The reality has been quite the opposite, I would say.

The committee recognized a hole which has been used as a convenient
excuse to draw negative conclusions about Ada in other studies like
this, and is recommending that the hole be filled.  I hope such efforts
produce success.

Meanwhile, I don't know quite what to make of all this, career-wise.
Maybe following the lemmings over the cliff and into the C is not such a
bad idea after all....
--
James Squire                             mailto:[log in to unmask]
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com/
Opinions expressed here are my own and NOT my company's
"I have a destiny to fulfill. One which will take our people back to a
 golden age. We are Centauri, Urza. We are meant to conquer, to rule, to
 build empires."
        -- Londo, "Knives"

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

December 2017
November 2017
October 2017
September 2017
June 2017
May 2017
April 2017
January 2017
December 2016
November 2016
October 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
December 2010
November 2010
October 2010
September 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
June 2007
May 2007
March 2007
February 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997
December 1996
November 1996
October 1996

ATOM RSS1 RSS2



LISTSERV.ACM.ORG

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager