Re: Ada policy enforcement

Re: Ada policy enforcement

[Richard Pitre]

In article <4iir4c$koa$1@mhadg.production.compuserve.com> N. L. Sizemore  
<102673.224@CompuServe.COM> writes:
> 	As a (non-C) programmer looking for work in a C/C++ 
> dominated and largely DOD oriented programming community, and as 
> a former soldier, a question has occurred to me which those with 
> closer ties to the DOD plocy community might be able to answer.
> 
> Qualification:  I realize that large organizations make policy 
> mistakes, and dedicated and energetic middle mamangers often try 
> to correct them at a working level.  I also realize that a 'do it 
> my way or else' attitude can be anathema to a group of technical 
> professionals.  Nonetheless, we work in an arena where DOD has 
> undertaken extensive and widely publicised efforts to 'do the 
> right thing'.  Moreover, the Ada policy is now, and has been for 
> some time, both public law and DOD and service regulation.
> 
> The question:  Given the legal status of the Ada mandate as both 
> public law and regulation, why has DOD not only been lax in 
> enforcement, but allowed wodespread use of a language not even on 
> the list of DOD approved alternate languages?
> 
> Technical and programmatic issues aside it appears poor 
> leadership to allow senior personnel to flout law and regulation 
> with impunity.  While I have seen this issue discussed here I 
> have not seen an answer to the question
> 
> 			N. L. Sizemore

I don't really know whats going on but DOD seems to be sitting back as though
the problem that they perceived initially is now solved and that all they have 
to do is mandate the use of Ada in government contracts. People working for 
govenment contractors  have had quite a bit to say about this in this group.
Maybe DOD should pick one person from each of the contracting companies that 
has done work on Ada mandated projects, pay them to make a joint report, then
use the report as a basis to go to stage 2. Its going to cost more to fix the  
problem than they thought; no surprise. I don't believe that the problem will 
go  away without something like Ada. On the other hand, no one seems to believe  
that the avialablity of Ada  and contract specifications alone are going to  
tame the beast. Some might say that the beast has going from belching and  
farting out loud to breathing fire. 

It sounds like maybe DOD inadvertently tried to make private companies  eat
cost of education, conversion and interfacing.
Maybe a better approach to "enforcing Ada" would be for DOD to say what their 
verifiable performance specs are and then tell people how much extra they will
pay if they do it partially in Ada and how much more for doing it all in Ada. 
I'm sure that this would have all sorts of problems too but the point is that
there needs to be a way of covering the cost of conversion that accounts for 
real world contracting and bussiness practices. Maybe the cost looks to big?
If so then DOD has to think about it from the perspective of what the  
cost/benefit looks like 20 to 50 years from now. We don't want it to read like 
"oh shit we almost thought about it enough".

richard
(my opinons only)

Re: Ada policy enforcement

[Ken Garlington]

N. L. Sizemore wrote:
> 
> The question:  Given the legal status of the Ada mandate as both
> public law and regulation, why has DOD not only been lax in
> enforcement, but allowed wodespread use of a language not even on
> the list of DOD approved alternate languages?

I can't answer the core of your question (and agree it's a good question),
but I can pass on one item: There are apparently conflicting legal
opinions as to whether the Congressional part of the mandate expired with
the appropriations act to which it was attached. So, it's a matter of
opinion as to whether Ada is still public law.

As for regulation, there is also some ambiguity about the extent of
the Ada mandate, given the revised wording of DoDI 500.2. Hopefully,
this ambiguity will be better explained with the release of some of
the follow-on regulations (which will be out Real Soon Now).

Re: Ada policy enforcement

[Richard Pitre]

In article <31515445.28DB@lfwc.lockheed.com> Ken Garlington  
<garlingtonke@lfwc.lockheed.com> writes:
> N. L. Sizemore wrote:
> > 
> > The question:  Given the legal status of the Ada mandate as both
> > public law and regulation, why has DOD not only been lax in
> > enforcement, but allowed wodespread use of a language not even on
> > the list of DOD approved alternate languages?
> 
> I can't answer the core of your question (and agree it's a good question),
> but I can pass on one item: There are apparently conflicting legal
> opinions as to whether the Congressional part of the mandate expired with
> the appropriations act to which it was attached. So, it's a matter of
> opinion as to whether Ada is still public law.
> 
> As for regulation, there is also some ambiguity about the extent of
> the Ada mandate, given the revised wording of DoDI 500.2. Hopefully,
> this ambiguity will be better explained with the release of some of
> the follow-on regulations (which will be out Real Soon Now).

If Ada were *manifestly* better then there would be no need to enforce it.
Enforcment is the last refuge of the terminaly confused and soon to be
extinct. (Contract specification is a different matter, and yes you
can spank me for the unattributed misquote.)  
 

I would assume that the original designers of Ada were acting 
based on rational consideration of positive *real world* experiences with 
languages of similar ilk.  Perhaps experienced Ada programmers confuse or 
forget the distinction between their positive programming experience 
with Ada and  their intellectual appreciation of it. Perhaps this 
results in debates like the ones that occur here. 

Here, people with actual Ada experience attempt to convey their
intellectual appreciation of and rewarding experiences with Ada. This 
systematically instigates a defensive response which is usually, in some
sense, logically correct but effectively irrelevant or it is intellectual
excrement and misdirection based primarily on a need to rationalize 
emotional attachments and large personal investments. The worst responses 
are from professional programmers of presumably vast experience
who give intellectual obeisance with 
a side order of denigration. Read some of this shit carefully and think about 
your future with automated equipment in general and transportation systems 
in particular. Count the times you see something like "all this
compiler checking  stuff is nice but in the *real world* ..."
If you are one of the  people who really really 
believe that kind of stuff, then please go away.  
You are in the wrong place. If you are a professional programmer then
I hope you write nice database applications with your favorite 
tools. That way I can sleep secure in the knowledge that all 
references to me and my kin  will  eventually be 
irretreivably and mercifully lost from your company's systems. 
The net effect of these great language debates is 
affirmation of satisfying but dangerous and illfounded beliefs.

Almost any programmer with a little experience  understands the important
issues underlying the design of Ada. You get your candle burned from
a few ends a few times and all of a sudden some previously insipid
text book chapters become gospel. Of course, this elightenment
doesn't automatically come wrapped in the
conviction that Ada does in fact address those issues better than something
else? It isn't fundamentally an intellectual issue.
Without a direct experience it is difficult for people to apprecitate
the ergonomic motivation for the intellectual circus surrounding good
tools.

It is true that real educational experiences are very expensive from many 
perspectives. Perhaps those who first considered the need for Ada did not
correctly assess the cost of a complete solution to the problems that Ada 
attempts to address. The federal government should learn from the DoD
experience and establish standards and certification mechanisms in areas
of software development affecting public safety. 
No direct enforcement, just support for real education, 
standards of performance, and certification. 

richard

Re: Ada policy enforcement

[Robert Munck]

On 21 Mar 1996 22:45:51 GMT, pitre@n5160d.nrl.navy.mil (Richard Pitre)
wrote:
>If Ada were *manifestly* better then there would be no need to enforce it.
>Enforcment is the last refuge of the terminaly confused 

One more time:

1.  The largest costs of DoD software come in maintenance and
upgrades.

2. Ada is harder than other languages for some programmers,
easier for others; the differences are not huge.  However, Ada
programmers are generally somewhat more expensive.

3. In any significant system, the people responsible for
implementation costs are NEVER the same people as those
responsible for maintenance costs.  No DoD program officer,
civilian employee, or contractor has ever suffered the slightest
negative effect to career or reputation because the system they
implemented turned out to be an expensive nightmare to
maintain.

In other words, the people who see that Ada is *manifestly*
better are not the ones who decide whether or not to use it.
You need ENFORCEMENT from a higher authority.  Of course,
all of the current higher authorities will be long gone when 
today's decisions have negative results.  Those few who fight
for Ada are demonstrating altruism, a contra-survival trait for
a bureaucrat.

I just noticed your NRL.Navy.mil address.  WHY DON'T YOU
KNOW THIS??? The Navy has horrendous current maintenance
costs, because of all of those programs in AN/UYK-20 assembler,
the variants of CMS-2, FORTRAN, ECOS, and SPL-1 and the long,
long time between refits of ships at sea.

Bob Munck@acm.org

Re: Ada policy enforcement

[Ted Dennison]

Richard Pitre wrote:
> 
> If Ada were *manifestly* better then there would be no need to enforce it.
> Enforcment is the last refuge of the terminaly confused and soon to be
> extinct. (Contract specification is a different matter, and yes you
> can spank me for the unattributed misquote.)

Sorta' like seatbelts?

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Ada policy enforcement

[Richard Pitre]

In article <315223f3.629346743@news.interramp.com> pp000166@interramp.com  
(Robert Munck) writes:
> On 21 Mar 1996 22:45:51 GMT, pitre@n5160d.nrl.navy.mil (Richard Pitre)
> wrote:
> >If Ada were *manifestly* better then there would be no need to enforce it.
> >Enforcment is the last refuge of the terminaly confused 
> 
> One more time:
> 
> 1.  The largest costs of DoD software come in maintenance and
> upgrades.
> 
> 2. Ada is harder than other languages for some programmers,
> easier for others; the differences are not huge.  However, Ada
> programmers are generally somewhat more expensive.
> 
> 3. In any significant system, the people responsible for
> implementation costs are NEVER the same people as those
> responsible for maintenance costs.  No DoD program officer,
> civilian employee, or contractor has ever suffered the slightest
> negative effect to career or reputation because the system they
> implemented turned out to be an expensive nightmare to
> maintain.
> 
> In other words, the people who see that Ada is *manifestly*
> better are not the ones who decide whether or not to use it.
> You need ENFORCEMENT from a higher authority.  Of course,
> all of the current higher authorities will be long gone when 
> today's decisions have negative results.  Those few who fight
> for Ada are demonstrating altruism, a contra-survival trait for
> a bureaucrat.
> 
> I just noticed your NRL.Navy.mil address.  WHY DON'T YOU
> KNOW THIS??? The Navy has horrendous current maintenance
> costs, because of all of those programs in AN/UYK-20 assembler,
> the variants of CMS-2, FORTRAN, ECOS, and SPL-1 and the long,
> long time between refits of ships at sea.
> 
> Bob Munck@acm.org

I reassert that enforcement won't work, at least not in the long term.
I believe that if DoD started really enforcing *the law* then
DoD would be beaten into an understanding of the social and 
economic realities of what it wants. DoD would get an education in
higher law and authority. Real enforcement comes from the bottom up. 
If contractors cannot afford to use Ada and/or DoD can not be made to
appreciate the real cost of software that meets their requirements 
then enforcement  pushes contractors into passive 
agressive and competitive creative misrepresentational(pure marketing) 
modes.

It is perhaps a common belief  that within the government bureaucracy
real costs somehow never matter and no one is ever accountable. 
Private or public, people that matter take responsibility. No one has to do
that and when no one does then you get nothing. In the private sector
the problem is dealt with via marketing. The difference between being 
cynical and being realistic is in the commitment to use and change the real
situation for the better. Realistic people do make a choice about
what they want to achieve, they consciously and deliberatly assume
responsibility for their situation and their accomplishments and they
take risks. They live with their mistakes. They do exist.
Their early demise  is an endless source of comfort to those who  
strive for complete security.
  

DoD had the forsight and understanding to develope Ada. Maybe they
can get the understanding that they need to finish the job.
DoD needs a useable realization of the cost factors that they 
did not originally anticipate or grossly underestimated.

Its not hard for me to imagine Ada dying as a viable tool.
Bad things like that happen over and over again and the things 
left in their stead are often seriously defective.


 :-)O<

richard
 my opinons only
-------------------------
  The Lord's Prayer is 66 words, the Gettysburg Address is 286 words,
  there are 1,322 words in the Declaration of Independence, but
  government regulations on the sale of cabbage total 26,911 words.
   -- From an article on the growth of federal regulations in
      the Oct. 24th issue of National Review

  If a woman has to choose between catching a
  fly ball and saving an infant's life,
  she will choose to save the infant's life
  without even considering if
  there are men on base.  -- Dave Barry

Re: Ada policy enforcement

[Robert Dewar]

> If Ada were *manifestly* better then there would be no need to enforce it.
> Enforcment is the last refuge of the terminaly confused and soon to be
> extinct. (Contract specification is a different matter, and yes you
> can spank me for the unattributed misquote.)

Sorta' like seatbelts?

Or could one say "If having everyone drive on the same side of the raod
is manifestly better then having people drive on which ever side they
please, then there would be no need to enforce the rule about driving
on the right!"

Re: Ada policy enforcement

[AdaWorks]

N. L. Sizemore (102673.224@CompuServe.COM) wrote:

  [snip, snip, snip]

: The question:  Given the legal status of the Ada mandate as both 
: public law and regulation, why has DOD not only been lax in 
: enforcement, but allowed wodespread use of a language not even on 
: the list of DOD approved alternate languages?

  1) Wimpy DoD management
           (not by all, but by too many)

  2) DoD management's lack of understanding of the Rationale for Ada

  3) Uninformed programming decisions by senior commanders

  4) Managers who are intimidated by the technical superiority of
     their subordinates
          (Many old-time programmers, now managers, fail to keep current)

  5) Chain-of-command problems.  "Whoever made this policy is
     not in my chain-of-command, and therefore has no influence on my
     next promotion."

  6) Poorly implemented compilers.
          a) a compiler that passes validation but fails to
             support all the facilities of its targeted platform,
          b) a "checkbox" compiler that passes validation only well-enough
             so a hardware vendor can check the box, "Validated Ada."
  7) Badly constructed tools.


  -- ==================================================

     Jessica in "Who Killed Roger Rabbit"

             "I'm not bad. I'm just drawn that way."


     Ada, explaining her namesake language,

             "I'm not bad. I'm just compiled that way."


  Few of Ada's problems have ever been technical.  Most have been
  managerial, both within and outside the DoD.  


  Richard Riehle
  adaworks@netcom.com
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Ada policy enforcement

[Michael Feldman]

In article <4ism6v$dfr@ra.nrl.navy.mil>,
Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
>
>If Ada were *manifestly* better then there would be no need to enforce it.
>Enforcment is the last refuge of the terminaly confused and soon to be
>extinct. (Contract specification is a different matter, and yes you
>can spank me for the unattributed misquote.)  

What do you mean, "contract specification is a different matter?"
The Ada policy simply says, "if you're writing code for DoD, write
it in Ada." That is, they're making a global contract requirement.
There are perfectly decent waiver procedures for cases where Ada does
not make sense. DoD is paying the piper; they have the privilege of
calling the tune.

If DoD wants its ambulances built on HumVee chassis, I'm sure you
wouldn't dispute their right to say so; it's their (our) money. Simply 
ignoring the policy and delivering an ambulance built on a Cadillac would 
be nonresponsive; the PM who accepted a Cadillac would (or ought to)
be fired.

>It is true that real educational experiences are very expensive from many 
>perspectives. Perhaps those who first considered the need for Ada did not
>correctly assess the cost of a complete solution to the problems that Ada 
>attempts to address. The federal government should learn from the DoD
>experience and establish standards and certification mechanisms in areas
>of software development affecting public safety. 

I could not agree more; that's an independent issue.

>No direct enforcement, just support for real education, 
>standards of performance, and certification. 

Gimme a break. DoD is buying software for dollars. My dollars and
yours. If DoD wants to say "write the manuals in English; ask for
a waiver if, for some reason, you feel you must write in Sanskrit"
I'm sure you'd run screaming to your congressperson if you heard that
some contractor wrote manuals in Sanskrit without permission.

DoD policy is "if you write code for us, write it in Ada. Ask for a
waiver if you don't think this applies to you. We are paying for this
stuff, and we therefore have the right to write the specs."

What on _earth_ is wrong with this?

My only problem with the policy is the persistent rumors that contractors
aren't bothering to ask for waivers and are getting away with it. 
If these rumors are true, it's a scandal. Either it's policy or it ain't.

I don;t get it. The HumVee issue is clear. The manuals issue is clear.
What not clear about the Ada issue?

Mike Feldman

Re: Ada policy enforcement

[Ken Garlington]

Richard Pitre wrote:
> 
> If Ada were *manifestly* better then there would be no need to enforce it.

"If [insert your favorite law here] were *manifestly* better then there would
be no need to enforce it."

That's a trite (but true) argument to such statements. How about a different
one? Ada is _not_ *manifestly* better than other languages. (As far as I know,
there is no language that is *manifestly* better than all the others. If there
were, then there'd only be one language being used by everyone in the world!)

Ada's big payoff, at least in the original rationale for Ada, was that it
would be a better choice 5-30 _years_ from the initial development of the system.
That rationale is not obvious (manifest) to a developer who is only worried
about getting it out the door and getting paid. Thus, depending upon the
"manifest destiny" of any language selected for total life-cycle advantages
would be very suspect, in my mind.

> The federal government should learn from the DoD
> experience and establish standards and certification mechanisms in areas
> of software development affecting public safety.
> No direct enforcement, just support for real education,
> standards of performance, and certification.

Presumably, these standards and certification mechanisms would not
be required? :)

Actually, I do agree with a lot of what you say. A carrot approach would be
better than a stick. My conversations with OASD folks imply that they would
like to see this, as well. However, how do you give someone a meaningful
carrot twenty years after delivery? Is that something that fits well into the
five years (at most) business planning cycle, or for that matter the one
year defense budget cycle? I frankly don't know. However, if you can't
come up with a satisfactory carrot, and you take away the stick, then you've
probably decided (whether you wish to or not) that the original goal isn't
worth pursuing.

Re: Ada policy enforcement

[Robert I. Eachus]

     The original goal of the HOLWG was to cut the number of languages
that the DoD was paying to maintain compilers, tools, and classes for.
The numbers ranged from about 800 to over 1000 depending on how you
counted...

     The reality now is that many of those languages and tools have
gone away, and C++ is one of the few languages added.  I'd like to say
that the number is below 50 today, but it is probably closer to 100.
This is great progress, but some of the languages will only go away
when the programs that use them do, and others, even though worth the
cost of displacing, will take years of recoding and upgrades to get
there.

     Now taking this larger view, trying to eliminate C totally is a
waste of the government's time.  (And is in no sense a goal.  I've
been involved in many C exception requests, some I recommended
against, others I was the one to recommend.) There are still times and
places, even on projects where the majority of the the code is in Ada,
where C is much better for the purpose, or the only reasonable tool.
If the DoD could get to the point where a programmer who knew Ada, C,
and SQL could do 70% of the maintenance work, we would be in great
shape.  As it is there are still many large complex systems where the
software is in FORTRAN, CMS2, JOVIAL, or worse.  (And I even had to
work with 3 dialects of JOVIAL and two of CMS2 in the recent past.)

     Just to give you a clue, there is one program I am aware of that
requires over 50 compilers, assemblers, etc. to compile the source
code, and most of the tools are maintained at government expense.
There are many other systems where we would love to junk the existing
hardware and replace it with COTS hardware costing less than the
monthly maintenance costs of the existing hardware.  But doing that
requires porting the software, and in some cases there are no
programmers around who even know the languages used in the existing
systems, so reverse engineering may be out of the question.

     Using C instead of Ada might make a program more likely to fail.
Or using Fortran instead of Ada may cause later porting problems.  But
these problems pale into insignificance next to obsolete hardware
programmed in language no longer taught, where the government even has
trouble finding people willing to teach a course--if students can be
found.

    Now having said all that, C++ is a very different animal from C.
With C we know that--if the code is written and works--it may be
harder to port than Ada, but the costs are comparable.  With C++ it
turns out that the trick is porting the class libraries, and that this
means that often two C++ applications compiled with the same compiler
cannot be merged later because the class libraries are incompatible.
Figuring out how to make reuse work in that environment is difficult.
On the other hand C++ does seem to be good for small one-off
applications that won't require much maintenance.  It may have it's
place, but it is a very different place from C.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada policy enforcement

[AdaWorks]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:

:      The original goal of the HOLWG was to cut the number of languages
: that the DoD was paying to maintain compilers, tools, and classes for.
: The numbers ranged from about 800 to over 1000 depending on how you
: counted...

  [snip, snip, snip]

:      Now taking this larger view, trying to eliminate C totally is a
: waste of the government's time.  (And is in no sense a goal. 

  Good point.  

  We have a customer that has a lot of old Fortran programs that work
  well, and have worked well for a long time.  I believe that mature
  software that works is often better than new software that has not
  stood the test of time regardless of what language was use to write it.

  ONe benefit of the new Ada standard is its hospitality toward this
  existing source code through pragma Import, pragma Export, and 
  Annex B.

  It may not be good ecology to engage in a policy of clear-cutting 
  old-growth software.

  Richard Riehle
  adaworks@netcom.com

  
-- 

richard@adaworks.com
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX  328-1112

Re: Ada policy enforcement

[Richard Pitre]

In article <dewar.827528183@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
> > If Ada were *manifestly* better then there would be no need to enforce it.
> > Enforcment is the last refuge of the terminaly confused and soon to be
> > extinct. (Contract specification is a different matter, and yes you
> > can spank me for the unattributed misquote.)
> 
> Sorta' like seatbelts?
> 
> Or could one say "If having everyone drive on the same side of the raod
> is manifestly better then having people drive on which ever side they
> please, then there would be no need to enforce the rule about driving
> on the right!"
> 

Yes. I like that.
Ada will never be *manifestly* better to everyone, but with enough 
of the right kind of education the situation can improve a lot.
The key is sensitizing programmers to differences that have an objective 
impact while they are still in learning mode. Once you 
are into production you don't have time to experiment with differences.

If someone grows up drinking Ripple their first taste of really good wine
isn't something they write home about. They might even wash away
the bad taste with the *real* thing.


richard

Re: Ada policy enforcement

[Richard Pitre]

In article <4j2149$ljd@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael  
Feldman) writes:
> In article <4ism6v$dfr@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >
> >If Ada were *manifestly* better then there would be no need to enforce it.
> >Enforcment is the last refuge of the terminaly confused and soon to be
> >extinct. (Contract specification is a different matter, and yes you
> >can spank me for the unattributed misquote.)  
> 
> What do you mean, "contract specification is a different matter?"
> The Ada policy simply says, "if you're writing code for DoD, write
> it in Ada." That is, they're making a global contract requirement.
> There are perfectly decent waiver procedures for cases where Ada does
> not make sense. DoD is paying the piper; they have the privilege of
> calling the tune.
> 
> If DoD wants its ambulances built on HumVee chassis, I'm sure you
> wouldn't dispute their right to say so; it's their (our) money. Simply 
> ignoring the policy and delivering an ambulance built on a Cadillac would 
> be nonresponsive; the PM who accepted a Cadillac would (or ought to)
> be fired.
> 
> >It is true that real educational experiences are very expensive from many 
> >perspectives. Perhaps those who first considered the need for Ada did not
> >correctly assess the cost of a complete solution to the problems that Ada 
> >attempts to address. The federal government should learn from the DoD
> >experience and establish standards and certification mechanisms in areas
> >of software development affecting public safety. 
> 
> I could not agree more; that's an independent issue.
> 
> >No direct enforcement, just support for real education, 
> >standards of performance, and certification. 
> 
> Gimme a break. DoD is buying software for dollars. My dollars and
> yours. If DoD wants to say "write the manuals in English; ask for
> a waiver if, for some reason, you feel you must write in Sanskrit"
> I'm sure you'd run screaming to your congressperson if you heard that
> some contractor wrote manuals in Sanskrit without permission.
> 
> DoD policy is "if you write code for us, write it in Ada. Ask for a
> waiver if you don't think this applies to you. We are paying for this
> stuff, and we therefore have the right to write the specs."
> 
> What on _earth_ is wrong with this?
> 
> My only problem with the policy is the persistent rumors that contractors
> aren't bothering to ask for waivers and are getting away with it. 
> If these rumors are true, it's a scandal. Either it's policy or it ain't.
> 
> I don;t get it. The HumVee issue is clear. The manuals issue is clear.
> What not clear about the Ada issue?
> 

So I think what you are saying is that this Law is working fine and there is no
problem? I assumed there was a problem but your logic is impeccable. I guess
the orignal post was bogus and I responded to a nonissue. My appologies.

richard

Re: Ada policy enforcement

[Michael Feldman]

In article <4jf65c$9k3@ra.nrl.navy.mil>,
Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
>
>So I think what you are saying is that this Law is working fine and there is no
>problem? I assumed there was a problem but your logic is impeccable. I guess
>the orignal post was bogus and I responded to a nonissue. My appologies.
>
It would be naive to think the policy (what you are calling the Law)
is fine. I did not say that. I _did_ make a case - which you evidently
agree with - that it is quite reasonable, and in some folks' opinion,
a responsible way to spend our money, for DoD to _have_ a policy.

Rumors persist that some (who knows how many?) contractors and program
managers are simply ignoring the policy; I don;t have any specific
information. But DoD is a very big complex of organizations (the
central DoD, the various services, etc.), and in any organization
that large there will be disagreement on trhe value of various policies,
and perhaps some outright violations.

It comes down to whether the right authorities have the resources,
the will, and the ba**s to enforce policies. 

Meanwhile, I prefer to concentrate on the interesting  non-defense
projects for which Ada has been the language of choice: avionics,
air traffic control, high speed ground transportation, satellites, etc.

It also makes a great teaching language, as hundreds of profs and
thousands of students will probably attest.

Mike Feldman

Re: Ada policy enforcement

[David Weller]

In article <4jh3fq$27m@ra.nrl.navy.mil>,
Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
>
>Laws and policies that facilitate what most people already 
>want to do are nice laws. DoD should invest in building an 
>environment where everyone is sensitive too and is properly rewarded
>for solving their problems. 
>
That's in the budget, right after stopping tidal effects and making
the world stop turning :-)

>economical use of computing power to our economic benefit. DoD
>can justify a much greater expenditure just based on the idea that a
>strong economy is one assurance of our country's ability to defend 
>itself in the long term. Software costs are starting to eat everyone's
>lunch.
>

Alas, the DoD still has nothing in place to reduce the costs.  Greg's
points, though poorly worded, are still close in some ways:
Management:
	No repurcussions for using a "non-standard" programming
	language (this doesn't mean only Ada, by the way).

	Budgets for development and maintenance are separate, so there
	is little to no correlation between "getting something done on
	time" and "is the finished product maintainable?"

	Lack of management oversight on "small budget" items (under
	$10M for DoD projects), which is where the biggest
	"violations" occur.

Technicians:
	Incredibly huge "civilian" structure that favors C/C++ (if
	only in perception).

	Ineffective mechanisms to make the promises of reuse a reality
	(and I happen to agree with Greg that "closed" Reuse
	Facilities are _not_ the way to foster productivity)

	Ineffectual mechanisms to incentivize educational foundations
	to objectively evaluate Ada and decide if it should be part of
	their curriculum.

	A well-established "counter-culture" to using Ada.  All of it
	based on Ada 83 and the technologies and marketing approaches
	associated with that language.

Jeez, we're not trying to get people to use Ada, we're trying to make
a bevvy of four year-olds eat carrots, spinach, and broccoli :-)

-- 
Ancient man: Web apps? Java!  OO stuff? Eiffel!  "Real-time" stuff? C/C++! 
Modern man: Web apps? Ada 95!  OO stuff? Ada 95!  "Real-time" stuff? Ada 95!
	Not a revolution...but evolution.  http://lglwww.epfl.ch/Ada

Re: Ada policy enforcement

[Richard Pitre]

In article <4jfomp$8h8@felix.seas.gwu.edu> mfeldman@seas.gwu.edu (Michael  
Feldman) writes:
> In article <4jf65c$9k3@ra.nrl.navy.mil>,
> Richard Pitre <pitre@n5160d.nrl.navy.mil> wrote:
> >
> >So I think what you are saying is that this Law is working fine and there is  
no
> >problem? I assumed there was a problem but your logic is impeccable. I guess
> >the orignal post was bogus and I responded to a nonissue. My appologies.
> >
> It would be naive to think the policy (what you are calling the Law)
> is fine. I did not say that. I _did_ make a case - which you evidently
> agree with - that it is quite reasonable, and in some folks' opinion,
> a responsible way to spend our money, for DoD to _have_ a policy.
> 

Well then maybe your logic is impeccable but not comprehensive and there
is a significant problem. Does DoD want to have a well reasoned approach 
or one that is the most constructive and effective in the long term?
A well reasoned approach that do. It is my feeling, based on what
I've read here and the cultural hum, that DoD did not properly
account for the real cost of achieving their goals. 
To the extent that they defined their goal to be the implementation of
a good programming tool then they succeeded. To the extent that they
had a long term problem with the functionality of automated equipment
it remains to be seen if they have solved their problem. 

Laws and policies that facilitate what most people already 
want to do are nice laws. DoD should invest in building an 
environment where everyone is sensitive too and is properly rewarded
for solving their problems. 

> Rumors persist that some (who knows how many?) contractors and program
> managers are simply ignoring the policy; I don;t have any specific
> information. But DoD is a very big complex of organizations (the
> central DoD, the various services, etc.), and in any organization
> that large there will be disagreement on trhe value of various policies,
> and perhaps some outright violations.
> 
> It comes down to whether the right authorities have the resources,
> the will, and the ba**s to enforce policies. 
> 
> Meanwhile, I prefer to concentrate on the interesting  non-defense
> projects for which Ada has been the language of choice: avionics,
> air traffic control, high speed ground transportation, satellites, etc.
> 
> It also makes a great teaching language, as hundreds of profs and
> thousands of students will probably attest.
> 
> Mike Feldman

It looks like a great all around procedural language to me too.
I want it to succeed and I want DoD to nurture it in the best
possible way. It can be a success story about something
that benefited everyone. So this Ada story is largely about the 
economical use of computing power to our economic benefit. DoD
can justify a much greater expenditure just based on the idea that a
strong economy is one assurance of our country's ability to defend 
itself in the long term. Software costs are starting to eat everyone's
lunch.

richard