TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

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

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

Print Reply
Subject:
From:
James Squire <[log in to unmask]>
Reply To:
James Squire <[log in to unmask]>
Date:
Fri, 5 Sep 1997 15:16:02 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (157 lines)
"W. Wesley Groleau x4923" <[log in to unmask]> 09/05/97 01:34pm
quoted the following:

>----- Begin Included Message -----
>....
>     Programming language selections should be made in the context of
>     the system and software engineering factors that influence
>     overall life-cycle costs, risks, and potential for
>     interoperability.  The selection factors should be reviewed
>     by the program Integrated Product Team (IPT).

I am struck by how on target this paragraph is with respect to what
*should be done*.  No one in their right mind would dispute the
necessity of this.

The *issue* has always been:  *will it be done*?  I honestly don't know
one way or the other, but I keep getting hints that it is not too hard
to fudge the above idealism in plausible (hence successful) ways.

>     Among the factors the IPT should considered are:
>
>     . extent of compliance with/incorporation or other related
>       direction (e.g., ATA, open systems, and
>       commericial-off-the-shelf software) and the impact hereof;

Feels like there's a word missing in there somewhere, but it sort of
looks like this is talking about the issue of bindings.  Assuming I'm
decoding it correctly:

How's ARA/SigAda/whatever-entity-was-supposedly-on-top-of-this-problem
coming on standardizing and producing bindings for the various things
that need to be interfaced to?  If bindings aren't available, companies
like mine (at least the part that used to be its own company a month
ago) ain't all that interested in writing their own.  Even though I
suspect some people grossly overestimate the difficulty of writing
bindings (I've written a few myself), there are most likely better
reasons why we don't write them ourselves.

This might be one criteria where it is conceivable that C++ could be
better than Ada(95).

>     . long-term maintenance implications, including evolvability,
>       supportability and lowest life-cycle operations and sustainment
>      (O&S) costs;

Even in Don Reifer's flawed comparison of Ada and C++/C, his numbers
showed an advantage for Ada 83 over C and C++ (the sample size was too
small for Ada 95 as I recall) in the above mentioned areas.

I note simply that it is my understanding that Ada was designed in the
first place with this in mind, among other things.

>     . software reuse;

Was it not also designed with this in mind as well?

>     . system/software requirements, including performance,
>      interoperability, reliability, safety, and security requirements;

And these?

>     . system/software architecture, including partioning into
>       components;

Also these, though it seems like some of this was also addressed by
Ada9x?  Is there still a delay in bringing these features to the
marketplace, or are we seeing compilers and tools supporting this stuff
now?  Are we still bucking the false myth that Ada 95 is brand new
technology?

>     . selection of software development and support methodologies and
>       processes;

Honest, non-polemical question:  Aren't these issues largely language
independent?

>     . use of software development and support tools and generators;

This has always been where Ada has the weakest reputation - deserved or
otherwise.  And in fact it is one thing that cannot be completely
addressed when designing a language.  It can be impacted I suspect, but
not completely determined.  So here is another area in which C/C++ might
conceivably beat out Ada.

>     . integration of software issues and decisions with other planning
>       considerations to include cost, schedule, acquisition strategy
>       and staffing.

Cost used to be a deciding factor for C/C++ over Ada, but as someone
pointed out, when you compare commercial costs for C/C++ versus Ada, it
is misleading to just compare compiler to compiler, because with C/C++
you need additional tools to do things that are included in the Ada
compiler.  Nowadays I hear more about how one Ada vendor is
significantly cheaper than another, but not so much C/C++ cheaper than
Ada.

Staffing has suddenly reared its ugly head ('round these parts at least)
as a C/C++ point-winner:  "There aren't enough Ada programmers
available".  Maybe Mike Feldmann has a handle on whether that's because
few recruits *know* Ada or few recruits *want* to do Ada.  In terms of
the former, *I* learned Ada from scratch in one week and had no problem
growing into the language, and I had never even been exposed to it
before.  Anyone who is good enough at C++ to put it on a resume should
be able to learn Ada.

>----- End Included Message -----

I guess my point is that with possibly one or two exceptions, wasn't
each of the above criteria uppermost in the minds of the designers of
Ada and the DoD entity that contracted for the language 20 years ago as
the answer to the Software Crisis?

Weren't those who designed the language all experts in the field with
years of experience in doing things like this, and for all the
difficulties they might have experienced coming to consensus wasn't the
end product still worthy of respect?

And now for a year or so the DoD *and* the leadership of the Ada
community itself have been saying that all the above criteria should be
assessed by each DoD project individually on a case-by-case basis.
Again, I emphasize, this sounds impressively intelligent (no sarcasm
intended).

But there is one insidious reason available to DoD projects who are
presented with these criteria:  The answer to these questions *used* to
be Ada, period.  Now, it only *might* be.  "Something must be wrong with
Ada!  Why else the shift?"

In the meantime, the challenge to the Ada community (if it decides to
accept it) is to ask, and keep asking until an answer is forthcoming:
How is C or C++ better than Ada in any of these categories?  And if the
answer makes sense, then:  catch up in those areas and reask the
question.

From my side of the fence, I can't help feeling like there is a basic
prejudice among my "guild" toward *anything* that is presented as "the
best" - no matter how much the claim can be backed up.  And I am
personally embarassed by that.

Thanks for letting me rant ;-)
---
James Squire                Send my Spam to
mailto:[log in to unmask]
MDA^H^H^HBoeing St. Louis
http://www.boeing.com
---------------------------------------------------------------------------
Now that VMS is on the way out, it tips its cap to Unix by implementing
the
PIPE command.  Talk about locking the barn door after the horse has
gotten
away...  Opinions expressed here are my own and NOT my company's
---------------------------------------------------------------------------
"Mollari, what did he say...really."
'He said...that we are both damned.'
"Well, it's a small enough price to pay for immortality."
        -- Refa and Londo, "The Coming of Shadows"

ATOM RSS1 RSS2