Re: Eiffel for DoD development? (Was Re: Why Commit to Eiffel?)

Re: Eiffel for DoD development? (Was Re: Why Commit to Eiffel?)

[David Weller]

In article <1994Sep9.072456.1302@gtewd.mtv.gtegsc.com>,
 <krajnakm@gtewd.mtv.gtegsc.com> wrote:
>> [Robert "Rock" Howard of Tower Technology writes, when asked about
the feasability of using Eiffel for a control and monitoring system]
>>    Do it. The technology is inexpensive. The uptake time is short.
>>
>I'd like to *do it* but I primarily develop software for the DoD.  Which
>brings to mind the question are there any precedents for using Eiffel for
>DoD development, and if so how do I contact those brave souls?
>

I don't understand how a precedent could be set.  The DoD requires
usage of Ada except in cases where significant cost savings could be
demonstrated across the life cycle.  Aside from some rather pedantic
features, Ada 9X offers _at least_ as much functionality as Eiffel.
(Flame bait! :-)
_Especially_ for real-time control and monitoring systems.  

Have you bothered looking at Ada 9X?  What were your conclusions?

-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
             Ada 9X -- It doesn't suck                       ||  father's Ada
For all sorts of interesting Ada 9X tidbits, run the command:||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)

Re: Eiffel for DoD development?

[Wayne Dernoncourt]

In article <34qal9$6s2@Starbase.NeoSoft.COM>,
dweller@Starbase.NeoSoft.COM (David Weller) wrote:

 > I don't understand how a precedent could be set.  The DoD
 > requires usage of Ada except in cases where significant cost
 > savings could be demonstrated across the life cycle.  Aside from
 > some rather pedantic features, Ada 9X offers _at least_ as much
 > functionality as Eiffel.  (Flame bait! :-)
 > _Especially_ for real-time control and monitoring systems.  

I thought Ada was mandated only for embedded combat software, things like
test sets, etc. were excluded from having to be written in Ada.  Has DoD
changed their tune and will now force new business system software, etc. to
be written in Ada.  You should understand that were I work, we have a
group that writes business systems and still does it all in COBOL. 
Thankfully, I'm not a member of that group.<grin>

-- 
Take care      |   This clown speaks for himself, his job doesn't
Wayne D.       |   pay for this, etc. (directly anyway)

Re: Eiffel for DoD development?

[Ted Dennison]

In article <g5WSkakPrwVQ070yn@cpcug.org>, wayned@cpcug.org (Wayne Dernoncourt) writes:
|> In article <34qal9$6s2@Starbase.NeoSoft.COM>,
|> dweller@Starbase.NeoSoft.COM (David Weller) wrote:
|> 
|>  > I don't understand how a precedent could be set.  The DoD
|>  > requires usage of Ada except in cases where significant cost
|>  > savings could be demonstrated across the life cycle.  Aside from
|>  > some rather pedantic features, Ada 9X offers _at least_ as much
|>  > functionality as Eiffel.  (Flame bait! :-)
|>  > _Especially_ for real-time control and monitoring systems.  
|> 
|> I thought Ada was mandated only for embedded combat software, things like
|> test sets, etc. were excluded from having to be written in Ada.  Has DoD
|> changed their tune and will now force new business system software, etc. to
|> be written in Ada.  You should understand that were I work, we have a
|> group that writes business systems and still does it all in COBOL. 
|> Thankfully, I'm not a member of that group.<grin>

You thought wrong. The Ada mandate NEVER had any such limitation on it. (In
fact, the application you mention is one of the most difficult to use Ada on
due to full Ada's run-time environment.) Rumors like that have been going
around for years, but they are just that: RUMORS. One must wonder about the 
motives of those who spread them...

Anyway, mandating Ada for business systems under DoD contract (are there such
things?) would NOT be a change of tune. 

ENFORCING the mandate might be.

T.E.D.

Re: Eiffel for DoD development?

[Robert Dewar]

Wayne, your idea that the mandate is restricted to embedded combat systems
is indeed hopelessly out of date, and YES, business systems are also covered
by the mandate (and the usual possible exceptions to the mandate).

And also, it isn't a matter of DoD changing its policy, the mandate is a
matter of law.

Re: Eiffel for DoD development?

[Fred McCall]

In <g5WSkakPrwVQ070yn@cpcug.org> wayned@cpcug.org Wayne Dernoncourt writes:

>I thought Ada was mandated only for embedded combat software, things like
>test sets, etc. were excluded from having to be written in Ada.  Has DoD
>changed their tune and will now force new business system software, etc. to
>be written in Ada. 

First of all, it's really Congress that's responsible for the Ada
Mandate, not DoD.  Secondly, it applies to *all* software.  The only
reason business systems can often get a waiver (and yes, they need to
get one, as the Mandate exists) is because of all the already existing
COBOL out there (demonstrable price savings over the lifecycle).  

And yes, the 'Ada Police' *will* come and get in your face if you get
caught trying to use something else, even if what you're doing isn't
embedded software and (sometimes) even if it makes more sense to use a
different language because of already existing things that you have to
work with (and no, this is not purely theoretical knowledge).

--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
---------------------------------------------------------------------------
merlin@annwfn.com -- I don't speak for others and they don't speak for me.

Re: Eiffel for DoD development?

[Kevin Weise]

In article <85BA3295BE6@annwfn.com>, Fred McCall <merlin@annwfn.com> wrote:
>In <g5WSkakPrwVQ070yn@cpcug.org> wayned@cpcug.org Wayne Dernoncourt writes:
>
>>I thought Ada was mandated only for embedded combat software, things like
>>test sets, etc. were excluded from having to be written in Ada.  Has DoD
>
>First of all, it's really Congress that's responsible for the Ada
>Mandate, not DoD.  Secondly, it applies to *all* software.  The only
>reason business systems can often get a waiver (and yes, they need to
>get one, as the Mandate exists) is because of all the already existing
>COBOL out there (demonstrable price savings over the lifecycle).  
>
>And yes, the 'Ada Police' *will* come and get in your face if you get
>caught trying to use something else, even if what you're doing isn't
>embedded software and (sometimes) even if it makes more sense to use a
>different language because of already existing things that you have to
>work with (and no, this is not purely theoretical knowledge).

Would that it were true!  I could give you a handful of programs that
are COMPLETELY ignoring the mandate and getting away with it.  Come to
think of it, I have NEVER seen the "Ada Police" in action, anywhere, at
any time.  I do know that RFP's come out with requirements for using
Ada, but with the emphasis on COTS, its an easy escape hatch.  Not that
I'm complaining about the appropriate use of COTS.  Its just that I see
too much non-Ada IR&D and other "internal" software development that
suddenly becomes COTS for the purposes of a proposal.  It seems to me
that any organization that has the slightest amount of chutzpah can
avoid using Ada at all, regardless of whether it is a technically or
economically sound decision.

But, of course, this thread has been beat to death by many a contributor
on this newsgroup.  I, for one, would like to see a few instances of
defense contractors that have been reprimanded or suffered ANY
consequences at all for breaking the Congressionally-imposed LAW.  

You don't have to convince me that Ada is a good choice, I've been using it
since the early '80's (started with teaching it at Martin Marietta in
Denver).  But I also have been "eased" into a C/C++ environment lately.
----------------------------------------------------------------
Kevin J. Weise			weisek@source.asset.com
COLSA Corporation		Voice - (205) 922-1512 ext. 2115
6726 Odyssey Drive		FAX   - (205) 971-0002
Huntsville, AL  35806
{Standard Disclaimers about my opinions & my employer's opinions}
{... which are in conflict often enough}
----------------------------------------------------------------
"Admire those who seek the truth;
  avoid those who find it."		Marcel Proust

Re: Eiffel for DoD development?

[Richard Riehle]

In article <36h4bp$k96@source.asset.com>
  weisek@source.asset.com (Kevin Weise) writes:


>>
>>And yes, the 'Ada Police' *will* come and get in your face if you get
>>caught trying to use something else,

>
>Would that it were true!  I could give you a handful of programs that
>are COMPLETELY ignoring the mandate and getting away with it.


From: Richard Riehle

We do not need the "Ada Police."  We need sustained quality leadership.

I am pleased to report that we have recently discovered more and more DoD
sites who are paying attention to Secretary Paige's instructions.  I just
returned from an Ada training assignment with one of the important DoD
computer programming installations and found a management that was both
enthusiastic and committed to implementing DoD policy.  Of real importance
was the fact that the Director of this installation was leading the way.  The
middle managers knew what the Director required, and they were taking steps
to make it happen.  This site has PC's, Mainframes, and UNIX systems. They
have a plan in place for moving ahead.  The Director even announced his
plans to follow Secretary Paige's advice to begin designing long-term
projects using the new Ada 94 standard.  

If we can continue to develop this kind of leadership in key DoD organizations,
there will be no need for recriminations.  There will be no need to explore
culpability.  The Director of this installation actually pays attention to
the direction from his top management.  He is naive enough to believe that
orders are orders.  And he makes cure his subordinates understand his firm
committment to following those orders.

Give us a few more managers like this, and all the talk about "Ada Police"
becomes irrelevant.

I, too, like Eiffel.  It is a beautifully designed language.  But DoD policy
is Ada.  Let's stick to it.

Richard Riehle
AdaWorks Software Engineering
Suite 27
2555 Park Boulevard
Palo Alto, CA  94303
(415) 328-1815   FAX  328-1112
email: adaworks@netcom.com

Re: Eiffel for DoD development?

[Gregory Aharonian]

>From: Richard Riehle
>
>We do not need the "Ada Police."  We need sustained quality leadership.
>
>I am pleased to report that we have recently discovered more and more DoD
>sites who are paying attention to Secretary Paige's instructions.
    As a percentage of what?  Certainly you are not referring to any DOD
site affliated with ARPA, the Air Force's KBSA effort at Rome AFB, etc.
If "More and more" means moving from 5% to 10%, stick to a good wine for 
your pleasure.

Greg Aharonian

Re: Eiffel for DoD development?

[Robert Dewar]

GA logic is known to have some unusual rules, does GA arithmetic also
have unusual rules and not consider 10% to be greater than 5% :-)

Re: Eiffel for DoD development?

[Dave Ceely]

In article <SRCTRAN.94Oct4001852@world.std.com>,
Gregory Aharonian <srctran@world.std.com> wrote:
>
snip
>>
>    As a percentage of what?  Certainly you are not referring to any DOD
>site affliated with ARPA, the Air Force's KBSA effort at Rome AFB, etc.
>If "More and more" means moving from 5% to 10%, stick to a good wine for 
>your pleasure.
>
>Greg Aharonian
>
And so it goes.........Greg.  You jump on Richard and then cite ARPA and
Rome Labs as though they were associated with the majority of DoD
programs. Sorry to disappoint you, but a 5% swing in the service
programs would be way more than what is associated with the those
agencies.  Get your facts right.  It'll be less work for the rest
of us.

Dave Ceely - My opinions represent my own thought processes.

Re: Eiffel for DoD development?

[Robert I. Eachus]

     Gee I was trying to end this debate, but some people insist on
not "getting it."

In article <jws-1102940843050001@seeker.tiac.net> jws@seeker.tiac.net (Jeffrey W. Stulin) writes:

 > >      The optimal number is one.

 > Absurd. That is like saying that DOD should standardize on one type of
 > screwdriver!

   The if I turn that around, it becomes clear who is being absurd.
How many different 1" 10-32 Pan-head screws should a maintenance depot
have to stock?  Slotted and Phillips, or can they agree to just stock
the Phillips head?  Do you want them to include 23 other types of
screws just in case some mechanic doesn't like Phillips screwdrivers
and prefers Allen wrenches?

   This is the right way to look at the issue.  There may be better
ways of tightening some fasteners, but the DoD HAS to pay attention to
the cost of new tools, training, stocking issues, etc.  There has to
be a significant payoff to justify a switch.

 > A reason for the profusion of languages is wide range of potential
 > applications; No language is appropriate for all situations.

   Yawn!  Who said that such a magic language existed?  Ada was
designed to be appropriate for all DoD embedded applications, and has
proven to have a wider domain of applicability.  But the policy is
designed to allow for exceptions when they occur.

 > What DOD should be doing is a compromise: keep a short list of accepted
 > languages and let each development project choose the best language (from
 > the list) for the job.

   Ah, so you have read the policy, and realized that this is exactly
what is done?  No?  Try again then.  As I remember it, the list
started with eight languages and has shrunk as some of those languages
went away.  (TACPOL and JOVIAL J3 for example.)  But there are some
languages which never have and never will made the list.  Eiffel is
one, would you care to guess others?

   In another thread responding to this question, someone mentioned
SQL.  That is a perfect example, and if you read the policy, you will
find in the database domain, use of SQL requires no waivers, no
exceptions, no nothing.

   On the other hand, where once ATLAS (and ATLAS variants) were the
only usually the language considered for certain types of testing
software, there has been a lot of work on developing a set of Ada
packages (ABBET).  Soon I imagine that ATLAS will be dropped from the
approved list--once the needed tools are in place--since ABBET seems to
be much more maintainable.

  > Using the wrong tool for a job is worse than having to maintain a
  > new tool.

    And using the wrong tool AND having to maintain it is the worst
possible combination.  If you can't understand that many of us have
been there and had to do that, you are totally missing the point.  We
just went through this exercise recently.  To reduce maintenance
costs, we had to port a compiler written in a vendor specific variant
of one obsolete language, which compiled a different vendor specific
variant of an obsolete language, was hosted on an obsolete mainframe,
and targeted an obsolete computer architecture.

    Maintenance costs on the mainframe were such that spending over a
million dollars on the port would have been acceptable--I think the
final cost was half that.   But we still have (now) a special purpose
front end for the gcc compiler, and a special assembler, and a special
linker all to maintain for ONE project.  That way lies madness.

--

					Robert I. Eachus

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

Re: Eiffel for DoD development?

[Robb Nebbe]

In article <CxCCv0.999@actrix.gen.nz>, dkenny@actrix.gen.nz (Des Kenny) writes:
|> 
|>   1) any technical reason why not?
|>      Eiffel compilers generate C for portability reasons.
|> 
|>     =>
|> 
|>     One word and one letter : Embedded C       
|> 

I don't think that using the C produced by an Eiffel compiler would
be a good idea. The C is really intermediary code and in my opinion
isn't suitable for modification. It sounds like a nightmare waiting
to happen, but then maybe I didn't understand your suggestion.

|>      Must sandwiches always be "peanut butter and jello", forever?
|>      Do you want your life to be one flavour, forever?

Do you actually eat "peanut butter and jello" sandwiches or was this
a typo?

- Robb Nebbe

Re: Eiffel for DoD development?

[Joseph Skinner]

In article <377864$tv@Starbase.NeoSoft.COM> dweller@Starbase.NeoSoft.COM (David Weller) writes:
>In article <jws-1102941650060001@seeker.tiac.net>,
>Jeffrey W. Stulin <jws@seeker.tiac.net> wrote:
>>> In article <jws-1102940843050001@seeker.tiac.net> Jeffrey W. Stulin,
>>> jws@seeker.tiac.net writes:
>>> >What DOD should be doing is a compromise: keep a short list of accepted
>>> >languages and let each development project choose the best language (from
>>> >the list) for the job.
>>
>>In article <376tq0$84b@dayuc.dayton.saic.com>, James Hopper
>><hopperj@dayton.saic.com> wrote:
>>
>>> When i got out of grad school
>>
>>snip snip snip
>>> i had to learn 5 different
>>> assembly languages in the first 4 years i was working.
>>snip snip snip
>>
>>I strongly agree that standards are important in eliminating confusion and
>>inefficiency. There is, however, much midlle ground between mandating one
>>language for all jobs and having workers learn 5 different assembly
>>languages.
>>
>>As a software professional I think I can probably handle two or three
>>languages on a daily basis. Smarter people can probably handle even more.
>>
>(Dave rolls up sleeves)
>
>OK, Jeff.  Enumerate for me what languages should be used, let me
>start the list (I'm talking about production work, not Prototype or
>R&D stuff):
>   Ada 9X

Rexx for shell scripting and general interface glue.

>
>Now, you list a language underneath it that provides a NON
>overlapping set of functionality.  (Hint: Don't put Eiffel down)
>(Another hint: There are answers, just damn few)


--
===============================================================================
Joseph Skinner                      | Invercargill
usenet: joe@jsnode.equinox.gen.nz   | New Zealand

There is no such thing as a wizard who minds his own business
                          - Berengis the Black
                            Court Mage to the Earl Caeline

Re: Eiffel for DoD development?

[Richard Riehle]

In article <781960828joe.joe@jsnode.equinox.gen.nz> joe@jsnode.equinox.gen.nz (Joseph Skinner) writes:
>In article <377864$tv@Starbase.NeoSoft.COM> dweller@Starbase.NeoSoft.COM (David Weller) writes:
>>In article <jws-1102941650060001@seeker.tiac.net>,
>>Jeffrey W. Stulin <jws@seeker.tiac.net> wrote:
>>>> In article <jws-1102940843050001@seeker.tiac.net> Jeffrey W. Stulin,
>>>> jws@seeker.tiac.net writes:


>>>> >What DOD should be doing is a compromise: keep a short list of accepted
>>>> >languages and let each development project choose the best language (from
>>>> >the list) for the job.
>>
>>Now, you list a language underneath it that provides a NON
>>overlapping set of functionality.  (Hint: Don't put Eiffel down)
>>(Another hint: There are answers, just damn few)
>

No one has yet provided an irrefutable argument that a properly implemented
Ada compiler, along with appropriate plaform-supporting packages, cannot be
used to solve the vast majority of real-life software problems that most
of us confront on a day-by-day basis.

If we can do the job in Ada, why would we want to create more confusion by
mixing in more languages.


For example, I sometimes enjoy the macaronic verse of Ezra Pound but it is
extraordinarily difficult to read with its mixture ofGreek, Latin, English,
Italian, and Chinese characters. I certainly would not advocate this kind
of writing for documentation anymore than I would encourage multiple
computer languages for software development.

Prove to me that Ada cannot do the job, and I will use an alternative.


Richard Riehle

Re: Eiffel for DoD development?

[David Emery]

>>   Business Applications
>	Yes, I believe so.  Especially when you combine the
>	Information Systems Annex with Ada 9X.  Perhaps throw in the
>	Distribution Systems Annex for "CLient-Server" applications.
>	Am I missing something?

I've done open systems-based client/server computing in Ada.  Ada
works very well, and provides advantages over other solutions.  See
the paper we wrote on this in the proceedings of the Software
Technology Conference from April 94.

>>   Prototyping
>	In general, I find Ada quite suitable for prototyping,
>	however, if you'll look at my original post, I distinctly
>	said "not prototyping or R&D work".  

I've done this, too.  For prototyps that evolve into 'real systems',
Ada is excellent.  The advantage is that Ada supports prototyping the
structure of systems (i.e. the package design).

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Eiffel for DoD development?

[Robert M. Wilkinson]

In article <379632$9to@starbase.neosoft.com>,
David Weller <dweller@Starbase.NeoSoft.COM> wrote:
>
>I find
>that those that are supporting Eiffel (actually, those that are
>challenging that status of Ada as the "one" langauge for the DoD) are
>not thinking through the ramifications of using multiple languages on
>multiple platforms for many different forms of applications.

I don't think the "mandate" is an issue of language choice.  The language
itself is actually a *very* minor concern when all the "ramifications" and
politics are concerned.


>As languages go, Ada is _the_ most reliable, portable, and general
>purpose language one can use.  That's no accident, either :-)

This statement is about as accurate as saying that a Corvette is *the*
most reliable and useful vehicle one can ever buy.  Maybe so for some
people, but I hardly think a farmer would agree.

Ada has its advantages, just like every other language, and it has its
disadvantages, just like every other language.  The question is its
suitability towards a particular problem.  As a refutation to one of your
earlier posts, Ada is probably *not* the ideal choice for report writing.
It is probably *not* the best language for implementing an operating
system.  But maybe it is the best language for other purposes.  It all
depends on the problem.  That's why there exists such a plethora of
languages.  If there was one solve-it-all language, everybody would be
using it.

-- 
____________________________________________________________________________
  
Rob Wilkinson                                              wilkinso@gdls.com
____________________________________________________________________________

Re: Eiffel for DoD development?

[Robert Dewar]

Rob, why don't you think Ada (I am talking Ada 9X of course) is suitable
for report writing? I would be interested to know. I know traditionally
that specialized report writers have seemed reasonable, but ultimately
they are less successful than one might suppose. For example the REPORT
WRITER module of COBOL turns out to be of dubious value.

Given the rapidly changing nature of the world, I wonder whether traditional
views of report writing are very relevant. One may soon find that writing
Mosaic pages automatically is more important than executing trees. Almost
all aspects of programming have this kind of flux.

Re: Eiffel for DoD development?

[gjennings]

dennison@romulus23.DAB.GE.COM (Ted Dennison) wrote:

>> From: dennison@romulus23.DAB.GE.COM (Ted Dennison)
>> Date: 21-SEP-1994 16:31:59
>> Description: Re: Eiffel for DoD development?

>> Message sent: 20 Sep 1994 14:26:37 GMT.

>> In article <g5WSkakPrwVQ070yn@cpcug.org>, wayned@cpcug.org 
>> (Wayne Dernoncourt) writes:
>> |> In article <34qal9$6s2@Starbase.NeoSoft.COM>,
>> |> dweller@Starbase.NeoSoft.COM (David Weller) wrote:
                               [...snip...]

>> |> I thought Ada was mandated only for embedded combat software, things like
>> |> test sets, etc. were excluded from having to be written in Ada.  Has DoD
>> |> changed their tune and will now force new business system software, etc.
>> |> to be written in Ada.  
                               [...snip...]
>> You thought wrong. The Ada mandate NEVER had any such limitation on it. 
>> (In fact, the application you mention is one of the most difficult to use
>> Ada on due to full Ada's run-time environment.)
                               [...snip...]

What "embedded" means is, in practice, open to debate.  However, I've written 
digital flight control software in Ada and JOVIAL targeting a 1750A bare
machine; this should satisfy the most stringent definition of "embedded".

We never experienced significant problems using Ada due to its run-time.  In
fact, I was very, very pleased with Ada in this environment.  We may not have
satisfied your definition of "full Ada" because we didn't use tasking or
dynamic allocation, but what does that give up when compared to other 
languages used in the same application?  

Wasn't there a "safe subset" thread recently that covered this topic?

>> Anyway, mandating Ada for business systems under DoD contract (are there
>> such things?) would NOT be a change of tune. 
[...snip...]

I'm not sure what the question is...

IF question is "are there business systems under DoD contract"
  This can't be the question, so I won't open myself for flaming
ELSIF question is "is Ada used in DoD business systems"
  Yes, indeedy-doody it is or I've been dreaming for the past three
      years.
  We currently have four large Info Systems in house.  Smallest is roughly
      90k Ada physical lines (physical - blank - comment), the larget 400k
      and growing.
ELSE  "neither is really the question"
  Please elaborate
ENDIF "question is..."

Re: Eiffel for DoD development?

[Fred McCall]

In <376a55$5af@Starbase.NeoSoft.COM> dweller@Starbase.NeoSoft.COM David Weller writes:

>I agree completely with this.  There should be sufficient flexibility
>in prototype work for people to explore alternative languages,
>architectures, etc.  Should that move out into the realm of
>long-lived, maintained software for the DoD?  No.  Emphatically no.
>You're welcome to disagree with me on this.  Counterarguments,
>however, won't change my opinion.

In other words, don't cloud the issue with facts.  Your mind is made
up.  Do you still wonder why I object to the Ada Mandate and the type of
thinking (like this) that it seems to engender?



--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
---------------------------------------------------------------------------
merlin@annwfn.com -- I don't speak for others and they don't speak for me.

Re: Eiffel for DoD development?

[David Emery]

Besides FRESCO, a group has been formed within the IEEE to standardize
Ada9X bindings to IEEE 1295 (IEEE Motif).  So the X Windows issue is
being solved.

But Dennis raises a more general question about Ada and bindings.  He
asserts that:
>[the costs of developing/maintaing an Ada binding] would
>overwhelm the savings provided by Ada's inherent software architecture
>advantages when compared to ANSI C.

The issue here is one of scale.  An Ada binding can (if done right)
provide substantial advantages to other parts of the system that use
the binding.  So, the issue is whether the fixed cost of maintaing the
binding is overtaken by the proportionate savings resulting from using
Ada and the associated Ada binding.  

We did a prototype client/server system, using a locally-developed Ada
binding to XVT.  The XVT/Ada binding was about 2k Ada statements, and
the application code was about 20k Ada statements.  In our estimation,
we 'broke even' with the Ada binding.  In particular, we isolated a
lot of C dependencies/warts and also XVT dependencies/warts within the
Ada binding, and hid them from the applications program, simplifying
the application.  Our prototype was about 15% of the total application
code.  Thus, we'd project a net win for the Ada binding, since there
would be savings/advantages in the other 85% of the code we didn't
write.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

Re: Eiffel for DoD development?

[HElliott]

Robert Wilkinson wrote:

>I don't think the "mandate" is an issue of language choice.  The language
>itself is actually a *very* minor concern when all the "ramifications" and
>politics are concerned.


>>As languages go, Ada is _the_ most reliable, portable, and general
>>purpose language one can use.  That's no accident, either :-)

>This statement is about as accurate as saying that a Corvette is *the*
>most reliable and useful vehicle one can ever buy.  Maybe so for some
>people, but I hardly think a farmer would agree.

>Ada has its advantages, just like every other language, and it has its
>disadvantages, just like every other language.

This is no surprise considering the source.

As I stated before, the Ada mandate is LAW.  I posted the actual text of the
law previously under this same subject, I can repost if anyone wants to see
it.  Its law, folks, just like the laws against fraud, perjury, etc etc.
This country is going to begin to unravel if we don't either enforce laws,
or get them off the books.  For DoD software, Ada is the law.  The law says
nothing about suitability for the purpose, although it does allow waivers.
Lets send somebody to jail for violating it, or fine their employer and barr
them from further DoD contracts, or else lets get the law changed and let
evolution take over.


Thanks,
Doc Elliott
LOSAT Computer Engineer
INTERNET:  helliott@losat.redstone.army.mil
The opinions expressed herein are mine, and do not
constitute an official government position, unless
specifically stated as such.

Re: Eiffel for DoD development?

[Thomas Hood 913-4501]

In article <CC5F9E2E019D1B76@-SMF->, HElliott@LOSAT.REDSTONE.ARMY.MIL writes:
|> Robert Wilkinson wrote:
<blah, blah, blah>
    .
    .
    .
|> As I stated before, the Ada mandate is LAW.  I posted the actual text of the
|> law previously under this same subject, I can repost if anyone wants to see
|> it.  Its law, folks, just like the laws against fraud, perjury, etc etc.
|> This country is going to begin to unravel if we don't either enforce laws,
|> or get them off the books.  For DoD software, Ada is the law.  The law says
|> nothing about suitability for the purpose, although it does allow waivers.
|> Lets send somebody to jail for violating it, or fine their employer and barr
|> them from further DoD contracts, or else lets get the law changed and let
|> evolution take over.

The problem I see is when the customer decides to abandon Ada on the
advice of the contractor.  At that point the contractor won't complain
since the customer made the decision.  I see a disconnect between the
enforcers of the mandate and the decision makers on the individual
projects.  More directly, it's not the contractors abandoning the
mandate, it's the customer.  How do you prosecute them?

|> 
|> 
|> Thanks,
|> Doc Elliott
|> LOSAT Computer Engineer
|> INTERNET:  helliott@losat.redstone.army.mil
|> The opinions expressed herein are mine, and do not
|> constitute an official government position, unless
|> specifically stated as such.

-- 

Thomas Hood
hoodt@lfs.loral.com
-- Ada grunt since 1985
-- Member Team Ada since 1994
-- Member Team Human since 1965
--
-- My opinions are not those of my employers, and if they were I'd probably
-- reject them out of hand and form new ones.

Re: Eiffel for DoD development?

[Test Account]

Richard Riehle (riehler@ajpo.sei.cmu.edu) wrote:

: Prove to me that Ada cannot do the job, and I will use an alternative.

This sounds like an argument used to avoid high-level languages
altogether, in lieu of assembler.

Regards,
David C. Matthews