TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Proportional Font
Show HTML Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
AdaWorks <[log in to unmask]>
Mon, 11 Nov 1996 16:17:45 -0800
text/plain (118 lines)
On Mon, 11 Nov 1996, Tucker Taft wrote:

> >   ... Nevertheless, I still believe the recommendation to
> >   abandon the Ada policy is just plain wrong.
>
> I'm surprised you equate "narrow the mandate to focus on
> warfighting systems, and fix the waiver process" with "abandon the
> Ada policy."  The bulk of the Ada code in the DoD is in the warfighting
> domain.  The compliance with the Ada mandate outside the warfighting
> domain has been rather poor.  The compliance within has been quite
> good, with the bulk of the new code being written in Ada, and with
> 50M SLOC already written.

  Tucker.  Thanks for this well-considered reply.  I agree that the
  bulk of the Ada code is for embedded weapons systems, if that is how
  we intend to define warfighting.  Further, I understand that the
  compliance outside that definition of warfighting has been "rather poor."

  My view on this subject can be summed up in the old poem that ends
  with, "For the lack of a nail, the war was lost."  Ralph Crafts,
  in his thoughtful critique of the report  noted the importance of
  "support" activities in warfighting.  The importance of a reliable
  logistics  system cannot be underestimated.  Unlike a commercial
  inventory system, a military inventory system can mean life or
  death.  The same is true for a lot of our "support " software.

  So, it might be important for us to define exactly what we mean
  by "warfighting."  My interpretation may be broader than what I
  suspect was intended by the authors of the NRC report.  However,
  if the authors meant to convey a meaning that went beyond my
  interpretation, so be it.


>
> If anything, taking an over-pessimistic view of the NRC recommendations
> might produce a self-fulfilling prophecy, namely that it will help
> those who chose to interpret them as recommending that the DoD
> abandon Ada completely.

  Well-said.  We would not want to give aid and comfort to those who
  would derive support for a non-Ada solution using the language of
  the report or the opinions expressed regarding it.  Sadly, though,
  there are already those in the software community (and the press)
  who are reacting to this report as if it is a recommendation to
  kill off Ada for anything except weapons systems.

  I would have preferred different language from "warfighting." OK,
  perhaps additional language. If the report had defined "warfighting,"
  and then added "... and safety-critical and mission-critical software
  applications,"  I would have been somewhat more tolerant of it. When
  I used the word "sloppy" in an earlier communication, it was not a
  slur on the scholarship of the authors.  Rather, it was a comment on
  the use of language that could be, and has been, interpreted in
  unfortunate ways.

> In fact, the NRC recommendations are an attempt to balance the
> realities of the modern software world with the DoD's special
> requirements in certain domains.  In these domains, DoD should
> be expected to lead; in other domains, where the DoD requirements more
> nearly match those of multinational corporations, the DoD should be prepared
> to learn what they can from the best commercial practices of such
> corporations, without necessarily creating an arbitrary impediment to
> technology sharing.  Ada might still be the best choice for a particular
> project in these other domains, but a mandate to use Ada for all 3GL
> development in these domains is not justified, given the overriding
> requirement that the DoD capitalize on commercial technology in
> these domains of commonality.

  First, I am glad to see acknowledegment of the need for the DoD to
  provide leadership in certain software areas.  In particular, the
  work of NRC panelist Dr. Boehm has made substantial contributions
  to this leadership.  In addition, other panelist have invented tools
  and techniques that put the DoD squarely out ahead of many commercial
  sofware organizations  -- especially in the the emerging discipline
  of software engineering for quality.

  Your own contribution, Tucker, with the design of Ada 95 should earn
  you far wider acclaim in the software community at-large than you
  have been accorded thus far.

  It is clear that the panelists are endowed with greater confidence
  in the commerical software community than I would have. If I were
  to once again apply the word "sloppy" to an enterprise, it would be
  to much of what I see in commercial software practice.  Once again,
  the leadership and vision of people such as Dr. Wasserman and Dr.
  Boehm puts the DoD ahead of many commercial organizations.

  It is with regard to management of the language policy that the DoD
  has faltered.  And the faltering has not been because of the language
  policy but because it failed to manage that policy effectively. The
  policy has been correct.  I restate my earlier point that, if we
  abandon the "Ada is the default for all software development" policy,
  (my tacit acknowledgement of the importance of COTS), we will
  dramatically increase the complexity of the total software process.

  A move from Ada at this point in its history, given the outstanding
  design of the Ada 95 standard, would be exactly the wrong move. Ada
  95 is an excellent software backplane for supporting all phases of
  the software construction process, from requirements definition
  through deployment and maintenance. The Ada software backplane provides
  a linguistic continuity for integrating COTS, building wrappers for
  legacy code, re-engineering existing systems, and creating entirely
  new applications.

  Joni Mitchell sings, "You don't know what you've got till its gone."
  What we have now is an Ada, thanks largely to your work, Tucker, that
  can support a broader range of applications than we have previously
  imagined.  I am working with Ada 95 daily and the more I see the more
  I realize just what a fine piece of work it is.  As we sit here in this
  leaky software boat, wondering what to do, we do not want to throw
  overboard the tool we have found useful to bail out the boat. If we
  do, we won't know what we've got till its gone.

  So I stand by my position that the DoD should continue to abide by its
  single-language policy and the single lanuage should still be Ada.

  Richard Riehle

ATOM RSS1 RSS2