TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: AdaWorks <[log in to unmask]>
Date: Sun, 3 Nov 1996 18:01:35 -0800
In-Reply-To: <[log in to unmask]>
X-To: Tucker Taft <[log in to unmask]>
Reply-To: AdaWorks <[log in to unmask]>
Parts/Attachments: text/plain (119 lines)
On Sun, 3 Nov 1996, Tucker Taft wrote:

> If you read the (full) report carefully, it is not a question of DoD turning
> it's back on Ada in the logistics (when non-critical) and financial systems
> market.  It is a question of the DoD recognizing that in these fields, it may
> be better for the DoD to follow rather than lead, for they are a relatively
> small part of the market.  The report encourages projects to consider
> Ada for custom 3GL development in these domains, and requires
> that projects go through a Software Engineering review process as
> part of making such a decision, but it drops the assertion that
> doing custom 3GL development exclusively in Ada in these domains is a
> "no-brainer." If Ada is going to be chosen for development in these domains,
> it needs to be actively chosen, rather than being used by default.

  Encouraging projects to consider Ada is an interesting notion. It isn't
  likely to work given all the bad press Ada has had over the past ten
  or more years.  You, Tucker, have done a fine piece of work in bringing
  Ada up-to-date, and I think the Ada policy should be extended so the
  minsconceptions regarding the language can be rectified through its use
  on a wider range of successful projects.  A lot of DoD managers are
  breathing a sigh of relief knowing they can now go about their software
  development process doing any damn thing they want. Certainly, that is
  what they have done for years, but rather than say, "We don't know how
  to manage a software policy, so let's throw it to the wolves," it would
  have been better to develop a program for improving management.

>
> Furthermore, in these domains, the development problem is often dominated
> by the challenges of using Commercial Off The Shelf (COTS) solutions
> wisely.  Custom 3GL development should be minimized where satisfactory
> cost-effective solutions can be built by integrating COTS products.

  I have no problem with using COTS.  However, COTS, when building
  software is not well-understood.  I see DoD sites which use
  so-called COTS development tools that result in so much procedural
  code (dBASE, FOXPRO, CLIPPER stuff) that no reasonable person could
  still consider it COTS. But it is determined to be COTS because the
  product used for the development is "off-the-shelf."

> On the other hand, in the DoD-dominated, high-assurance, real-time,
> "warfighting" domain, using Ada has compelling advantages, the DoD is
> the leader and should be more than willing to blaze a trail if
> necessary.

  Guess what?  This new policy will be followed more for its loopholes
  than for its recommendations.  What will be "warfighting?"  And this
  opens the door for people who are attempting to abandon Ada to even
  further erode its influence in DoD systems.

> This all seems to presume that if Ada has to be chosen rather than being
> mandated in these domains, that it won't be chosen.  Given your experience
> with your readers, that seems unnecessarily pessimistic, and a bit
> hypocritical.

  I respond first to your use of the emotionally-charged pejorative,
  "hypocritical."  I realize you may feel some investment in the report
  I am criticizing, but I am not attacking you or the other authors. I
  am questioning the report.  I respect you and all the other people
  who were on this committee, but I do disagree with the conclusions
  in the fragment I have read.

  The readers to who you refer are reacting favorably to the things
  written by me and others regarding the new Ada standard.  However,
  Ada does not have the dollars behind it that an overhyped newcomer
  such as Java has.  To abandon the Ada policy now is premature. In
  the next couple of years, it would make sense to revisit the policy,
  but Ada 95 is not gain the foothold it needs in the commercial sector
  if it is perceived as having been abandoned by the DoD. And that is
  exactly how it will be perceived in the press at large.

  Also, I have always felt the word "mandate" was inappropriate. It was
  used so heavily by Greg that everyone assumed it was a mandate. Rather,
  from my point-of-view, it has been a DoD policy, much like any other
  DoD policy.  The main difference between DoD software policy and other
  DoD policies is that this one was badly managed from the very start.

  So now, instead of managing better, we simply abandon what was a
  correct policy.  I see that as the wrong direction to proceed,
  especially given the quality of the new Ada 95 standard.

> Many people, including Greg et al, have been calling on the DoD to drop
> a mandate that isn't consistenly enforced, and let Ada stand or fall on
> its own merits.  The committee felt that the mandate was not being
> enforced consistently in these domains, and furthermore, there were
> enough other considerations in building systems in these domains that
> mandating Ada was being overly simplistic.  More important is to push
> people toward a "product-line", component-oriented mentality, and push
> them away from building DoD-unique, "stove-pipe," stand-alone solutions.
> It seems a misdirection of energy to mandate a particular 3GL in a domain
> where you believe that doing custom DoD-unique development in a 3GL is often
> the wrong solution, and that figuring out how to build on commercial
> investments is more important.

  It was not overly simplistic to have a single-language software policy.
  I repeat my earlier comment.  If the DoD could not manage its Ada
  policy, a single-language policy, how in the world will it manage a
  multi-language policy?  I disagree with the conclusions of the report.
  What I see on the horizon is a software mess of gigantic proportions
  as we let local managers, contractors, commanders, and programmers
  go any direction they want.  We will sacrifice portability.  We will
  sacrifice longevity of the code. We will sacrifice manageability
  of the process. Most of all, we will sacrifice quality.

  When speaking of Hamlet's madness, we hear the phrase, "T'is pity,
  t'is true. T'is true, t'is pity."  I fear for the result of this
  change in policy. T'is pity.


 Richard

 Richard Riehle
 [log in to unmask]
 AdaWorks Software Engineering
 Suite 30
 2555 Park Boulevard
 Palo Alto, CA 94306
 (415) 328-1815
  FAX  328-1112

ATOM RSS1 RSS2