Re: Air Force helping to undermine Ada

Re: Air Force helping to undermine Ada

[Bob Munck]

In article <SRCTRAN.93Mar8175011@world.std.com>, srctran@world.std.com
(Gregory Aharonian) wrote:

>(quotes article about Air Force use of a Xerox program.) ...
>     Another beta user, the U.S. Air Force, is implementing a work
>flow system based on InConcert that specifies 1,400 tasks and 60
>applications and will be used by 10,000 people. (end of quote)
>
>    This is a good example of the beginning of the end of Ada inside
> the DoD ...
> 

Ok, Greg, read this very carefully.  Try to concentrate.

Ada is mandated by DoD because a program that uses it cost less over
its full life cycle.  The larger the program and the longer the life
cycle, the higher the percentage saved.

DoD does not care if Xerox saves money or not.  Therefore there is no
reason for them to buy a bunch of object code that was created from
Ada rather than a bunch created from C, or C++, or BRUIN.

I personally think we are heading for a slow crisis because of the
mass of incomprehendable C that so many vendors are staking their
business upon.  There will come a time when the pile is no longer
maintainable, and the company will be in trouble.  Lotus went through
a crisis like this a few years ago, and the telephone companies are
going through it right now.  Proper use of Ada would help avoid this.

Greg, I have to wonder why you keep attacking STARS.  You never seem
to know much about the program, but you sure have an opinion of it! 
I can only assume that your opinion is based on the same kind of logic
as that you demonstrated with the Xerox example.

Also, what make you think the Air Force project using InConcert is
software development?

Bob Munck

Re: Air Force helping to undermine Ada

[Gregory Aharonian]

>DoD does not care if Xerox saves money or not.  Therefore there is no
>reason for them to buy a bunch of object code that was created from
>Ada rather than a bunch created from C, or C++, or BRUIN.
>
>I personally think we are heading for a slow crisis because of the
>mass of incomprehendable C that so many vendors are staking their
>business upon.  There will come a time when the pile is no longer
>maintainable, and the company will be in trouble.  Lotus went through
>a crisis like this a few years ago, and the telephone companies are
>going through it right now.  Proper use of Ada would help avoid this.

Bob,
	This is wishful thinking on your part.  When it comes to spending
their OWN money in the non-mandated world, people are not spending it on
Ada.  You have been on the dole too long to know what it is to make a
decision about spending your own money.  I agree Ada is probably a better
language technically.  But that is not the sole criteria for choosing a
language; there are a variety of socioeconomic factors that the DoD
continues to ignore.  But these arguments about Ada and C/C++ are like
the old arguments about democracy versus communism.  The only thing that
ever really counted was and is which direction people were choosing with
their own feet.  Similarly, all that really counts is how people spend
their own money, and it is rarely on Ada.  Eventually the Ada world will
be so far behind the non-mandated world, the DoD will have no choice but
to drop the mandate in order to fulfull its mission, as the supply base of
Ada programmers and tools won't be large enough (as the FAA reports allude
to to some extent).

>Greg, I have to wonder why you keep attacking STARS.  You never seem
>to know much about the program, but you sure have an opinion of it! 
>I can only assume that your opinion is based on the same kind of logic
>as that you demonstrated with the Xerox example.

Bob,
      Which version of STARS are you referring to?  The program has changed
so many times its hard to keep a steady aim.  But in general, here are some
reasons I attack STARS.
 
1)  ONE OF THE STARS GOALS WAS A LIE
 
    During the initial stages of the STARS program (the pre-RFP, the RFP,
the initial efforts, and promises to the press and Congress) one of the
often stated goals was that STARS would increase software productivity for
the DoD by a factor of 10 (TEN).  During the RFP stage, and for a time
after, a few of us complained that never before had any project anywhere
increased productivity by a factor of ten in software development, and that
the STARS program had no sub-project to build a economic model to assess
such a claim and collect the relevant data.  Yet the STARS program stuck
to this outrageous claim.  About a year into the program, spring of 1990, I
had a phone conversation with the then program manager, Colonel Joseph Greene,
during which I asked how the STARS program was going to validate such a claim,
especially since hardware and compiler advances alone were boosting
productivity.  He said, and I quote, "We are assuming that the gains in
productivity will be so obvious we won't have to measure them".
    Finally, in 1991, the STARS program tasked a group at the IDA to look
at the problem.  Their report, given at the 1991 STARS conference concluded
that: "Though the model and its parameters are subject to change, preliminary
conclusions are: small increases in the speed of technology adoption result
in large savings, the STARS program appears to be cost-effective, and
achieving a decrease by a factor of two in software expenditures by the
year 2000 WILL BE DIFFICULT.
 
   Thus, one of the things I know is that one of the main initial goals of
STARS was a lie.
 
 
2)  STARS CONTINUES TO IGNORE VHDL
 
    Defense weapon systems consist of two, ever overlapping items: hardware
and software.  To standardize software design and maintenance, the DoD
developed Ada.  To standardized hardware design and maintenance, the DoD
developed VHDL. Both are fine standards with a very close syntactic structure.
Thus you would figure that the DoD look into every possible way to integrate
Ada and VHDL, which would allow the closer integration of hardware and
software activities.  Certainly a better meta idea.
    Yet the STARS program, the ideal environment for such an exploration,
has completely ignored use of VHDL, even as VHDL is sweeping the commercial
digital design world, and now the Air Force is seeking proposals for an
analog VHDL - AHDL.  VHDL has been so ignored by the DoD that most VHDL
tool suppliers only have their products generate C code from a VHDL
specification, when it would be easier to generate Ada code, given the
syntactic similarities between the languages  ( I doubt highly anyone with
STARS has ever compared the Ada and VHDL grammars to discover this ).
 
   Thus, another thing I know is that STARS lack of vision has prevented
it from helping to build bridges from Ada to VHDL.
 
 
3)  STARS IS EMBARASSED ABOUT ITS RESULTS
 
    I am always hearing about the great technology and breakthroughs coming
out of the STARS program, with the emphasis on 'hearing'.  I go to many of
the commercial software engineering conferences and trade shows each year,
such as Object World, CASE World, Software Engineering, Embedded Systems,
and NEVER do I see any of the STARS technology being talked about on or
display.  These perfect opportunities to present STARS technology to the
non-Mandated world in order to get people interested in STARS and Ada are
ignored.  These perfect opportunities to present STARS technology at a
booth in order to be discovered by small, new, software engineering companies
who could contribute to STARS are ignored.  These perfect opportunities to
present STARS technology to the general public to get feedback and critiques
from people not on the DoD dole are ignored.
    In short, the STARS program has consciously ignored presenting itself
to the general public, at a great disservice both to the general programming
community and the DoD.  One can only assume that the STARS program is
embarassed by its results, especially groups like IBM, which offers totally
different technology to its commercial customers for solving the same problem.
    After all, when an Air Force unit can develop a CASE tool and get a US
patent for it, and we still don't hear much pubicly about STARS, you have to
wonder how embarassing these self-labeled breakthroughs really are.
 
    Thus, another thing I know about STARS is that the quality of the results
is so low that everyone is afraid to present this technology in public forums.
 
 
4)  STARS IS EMBARRASSED BY ITSELF
 
    As I have mentioned on comp.lang.ada, there are a variety of new industry
groups in software engineering to promote new software technologies.  For
example, one such group is the Object Management Group, set up to coordinate
object oriented programming and software tools.  Few, if any, of the STARS
contractors are members of this group and show up at Object World.  Since it
does not cost much to join the group, compared to the profits made on STARS
contracts, it is hard to come up with a reason that STARS contractors are
not members, other than their having an isolationist tendency.
 
    Thus another thing I know is that STARS for the most part is rejecting
contacts with the outside world.
 
5)  THE STARS REPOSITORY EFFORT ASSET IS A FAILURE
 
    I would like to say that most people think that ASSET is a joke, but
that would require that most people know much about ASSET.  Here is a software
repository staffed by people with no background in software repositories, not
doing any of things other established software reposities are doing.  They
don't post FAQs to comp.lang.ada, they are not anonymous-ftp accessible,
they are not mail server accessible, they publish no marketing newsletters,
they do not use CDROMs, their schema for components is useless for commercial
suppliers of reusable software, they have no active program for seeking out
resuable Ada software, they have little if any contact with non-DoD federal
software repositories to seek advice, they reject the advice of commercial
maintainers of software repositories and reusable software.
    Even though I maintain the largest database of information on reusable
Defense software on a budget of a few thousand dollars a year, not once has
anyone from ASSET ever called to ask how I do what I do, in order to help
their own operations.  Simply they don't care about running something more
than a sit-on-your-butt passive repository.
 
(One other thing.  As part of STARS, IDA developed a spreadsheet economic
model to make the above assessment that reducing costs by the year 2000 will
be difficult.  Not once has IDA ever bothered or cared to post information to
comp.lang.ada, or anywhere else, about this spreadsheet and its availability.
Like many other developed software items as part of STARS, the incompetency of
promoting its reuse is ongoing and criminal.)
 
    In short, STARS' ASSET software repository is a failure, its people
unqualified to run a repository, and all of this being tolerated by the
current STARS program office (partly because no one in the STARS program
office has experience running a repository, especially with their own 
money.  The blind leading the blind).
 
 
==============================================================================
 
 
    Thus, before you get on my case, please get on your own.  If my critiques
are not well developed or thought out, it is only because I do not have your
resources and funding.  You try running STARS on a budget of a few thousand
dollars a year, and see how far you get.
 
Greg Aharonian
Source Translation & Optimization
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Air Force helping to undermine Ada

[fred j mccall 575-3539]

In <21040.732067706@blackbird> munck@STARS.RESTON.PARAMAX.COM (Bob Munck) writes:

>I personally think we are heading for a slow crisis because of the
>mass of incomprehendable C that so many vendors are staking their
>business upon.  There will come a time when the pile is no longer
>maintainable, and the company will be in trouble.  Lotus went through
>a crisis like this a few years ago, and the telephone companies are
>going through it right now.  Proper use of Ada would help avoid this.

Proper use of *comments*, *documentation* and *configuration
management* would also help avoid this.  Ada is not some 'magic
bullet'.  Software is either properly engineered and maintainable or
it is not.  Language has no bearing on that.  Bad software can be
written in any language, as can good software.  The problem isn't some
lack of "proper use of Ada" (and note carefully the "proper"); it is a
lack of proper software engineering discipline, which can be exercised
or fail to be exercised in *any* language.

Some of us seem to have no problem reading and maintaining C, provided
that the implementer makes "proper use of C".

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

Air Force helping to undermine Ada

[Colin James 0621]

The NetWorld article states that the USAF is using a commercial off the
software product.  In DoD it is standard operating procedure
to use COTS rather than constantly reinvent the wheel.

The comments attached to the article criticize the USAF for following
orders which have nothing to do with the mandated use of Ada.  Hence the
comments do not follow logically and are known as a non sequitor argument.

The comments are admittedly hysterical (NOTE:  the use of the word hysterical
here is not a flame), and may be better left for mass e-mail rather than a
moderated internet forum.

Re: Air Force helping to undermine Ada

[Joshua Levy]

In article <9303100635.aa26443@dsc.blm.gov> cjames@DSC.BLM.GOV (Colin James 0621) writes:
>The NetWorld article states that the USAF is using a commercial off the
>software product.  In DoD it is standard operating procedure
>to use COTS rather than constantly reinvent the wheel.
>
>The comments attached to the article criticize the USAF for following
>orders which have nothing to do with the mandated use of Ada.  Hence the
>comments do not follow logically and are known as a non sequitor argument.

I don't think you understood the product the USAF bought.  It requires
integration with other products, customizations, and additions.  All of
this work must* be done in C.  Since this work is programming, by buying
a product which requires, C the USAF is (in a sense) mandating C for
that integration, customization, and addition work.  

If the USAF had required that the integration, etc. work be done in ADA,
they would have gotten some other product.  Or, more likely, they would
have had to pay someone to develop it all from scratch in ADA.

But that leads into the Real Problem (tm): there are almost no off the 
shelf products written in ADA.  So if you want to take full advantage
of a commercial product's API, you need to program in C, or some other
common language.  It is not impossible to use ADA in these situations,
but it is much harder than using C.  

* = "Must" might be a little strong here, but the commercial product's
interfaces and documenation all expect C, so using another language 
would be very difficult.

Joshua Levy   (joshua@veritas.com)

Re: Air Force helping to undermine Ada

[Gregory Aharonian]

>I don't think you understood the product the USAF bought.  It requires
>integration with other products, customizations, and additions.  All of
>this work must* be done in C.  Since this work is programming, by buying
>a product which requires, C the USAF is (in a sense) mandating C for
>that integration, customization, and addition work. 
>
>If the USAF had required that the integration, etc. work be done in ADA,
>they would have gotten some other product.  Or, more likely, they would
>have had to pay someone to develop it all from scratch in ADA.

   Thus, in time it will be cheaper and cheaper (even with a warrranty for
maintenance and safety) for the DoD to have developed larger and larger
systems using COTS products and APIs, which all trends point to C/C++.
A 10,000 user system, which the specific project is, is a moderate to
large project within current definitions.  More success stories like these
will lead to the questioning of the Mandate inside the DoD, and probably
its eventual retraction.
    The Mandate world will be able to ignore the outside world for only
so long.

Greg Aharonian
Source Translation & Optimization
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Air Force helping to undermine Ada

[David Emery]

>But that leads into the Real Problem (tm): there are almost no off the 
>shelf products written in ADA.  So if you want to take full advantage
>of a commercial product's API, you need to program in C, or some other
>common language.  It is not impossible to use ADA in these situations,
>but it is much harder than using C.  

Doing Ada bindings requires a certain level of skill, but after that,
there's generally no real problems with most commercial products.
Some "middleware" products (such as DCE) require assistance from the
compiler vendor, or intimate knowledge of both implementations to
prevent unwanted interference between the Ada RTS and DCE threads, for
instance.  

On the other hand, once you get a good Ada binding, my experience (8
years worth) is that the Ada binding is often much easier to use.  A
well-written Ada binding, using Ada strong typing, etc, catches many
errors at compile-time, and provides a much stronger error detecting
and recovery system at runtime.  For instance, we've been working with
XVT, a commercial GUI product.  The XVT C implementation does not
handle its errors very well.  For instance, it gets confused when you
try to locate a widget off the screen, or where the bottom-right
corner is above the top-left corner, etc.  By using Ada strong typing,
we detected several stupid mistakes at compile-time (e.g. type
mismatch when trying to add a vertical measurement to a horizontal
location), that would have caused a lot more work to detect, identify
and resolve at runtime (using debugging techniques).  (We have
experience using the XVT C binding, and so we know how painful it is
to run down runtime errors using XVT.)

The same is true of the POSIX bindings.  Several people (NOT Ada
people) have said that the POSIX/Ada binding is better written, easier
to understand, and easier to use, than the existing C binding.

				dave

Air Force helping to undermine Ada

[Gregory Aharonian]

     A recent article in Network World show one way in which the DoD is
helping to undermine Ada acceptance.  I will quote from the article (without
losing its essence) [Network World 3/8/93, 33]:

    XSoft, a division of Xerox, last week announced document-based work flow
software called InConcert, which provides a graphical user interface that
makes it possible for end users to construct a variety of complex work
flow applications.  InConcert is client/server software that tracks and
coordinates all tasks in a work flow process and automatically delivers to
end users the business documents and applications they need to complete a
work flow task.  Its server runs on Suns and RS6000s, as well as its clients
along with MSWindows.
  The problem with many high-end work flow products, according to consultants,
is that they require programmers to build work flow applications using a high
level scripting language.  This slows down the development process and takes
end users out of the loop.  "InConcert's strength is its graphical work flow
design tool, which makes it possible for end users rather than programmers
to build work flow applications", says a consultant.
    XSoft, which developed InConcert using the C++ programming language, has
published more than 270 application program interfaces that enable end-users
to integrate thiry part products with InConcert.  Developers can also use
these APIs to embed software agents within InConcert that carry out processes
in response to predefined events.

    Another beta user, the U.S. Air Force, is implementing a work flow
system based on InConcert that specifies 1,400 tasks and 60 applications and
will be used by 10,000 people.

==============================================================================

   This is a good example of the beginning of the end of Ada inside the DoD
for two reasons.  First, the Generals in charge are more and more going to
see that the information processing needs can be meet by taking commercial
products that are "open" and adapting them to defense needs, commercial
products all being written in C/C++.  As 10,000 people and 60 applications
is a serious integration effort, comparable in scope to most other DoD 
software efforts, one success makes it easier to do this again and again,
to the point where the Ada mandate becomes irrelevant.  It is impossible
for the DoD RIGHT NOW to achieve a similar work flow system relying one
any commercial or non-commercial system written in Ada.  As more and more
systems inside the DoD are based on C/C++ systems, the Mandate also becomes
uneconomical to retain.
   The second reason that the Generals will desert Ada is that the success
of these such efforts will get them to start asking what is going on with
efforts like STARS to create Ada technology that increasingly is falling
farther and farther behind the commercial world.  This questions the
competence of either Ada or Ada contractors, neither of which does much
good for retaining the Mandate.

    Thus my prediction: if you see more and more such stories about the
DoD solving its problems using C/C++ commercial software products, then
you know the handwriting will be on the wall for Ada.  Any given the
technology I see at the commercial trade shows, I would bet MY money on
seeing more and more such stories.

Greg Aharonian
Source Translation & Optimization


(In fact, maybe the DoD should change the name of the language.  When the
disease AIDS first became well known, a diet product pronounced the same
way changed its name because of confusion.  Given that most corporate
executives think of the sound "ada" as standing for the Americans with
Disabilites Act, are we not risking subconcious confusion for Ada as a
disabled language :-)
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178

Re: Air Force helping to undermine Ada

[Kevin Miller]

In article <SRCTRAN.93Mar8175011@world.std.com>, srctran@world.std.com
(Gregory Aharonian) wrote:
> 
>      A recent article in Network World show one way in which the DoD is
> helping to undermine Ada acceptance.  I will quote from the article (without
> losing its essence) [Network World 3/8/93, 33]:
> 
>     XSoft, a division of Xerox, last week announced document-based work flow
> software called InConcert, which provides a graphical user interface that
> makes it possible for end users to construct a variety of complex work
> flow applications.  InConcert is client/server software that tracks and
> coordinates all tasks in a work flow process and automatically delivers to
> end users the business documents and applications they need to complete a
> work flow task.  Its server runs on Suns and RS6000s, as well as its clients
> along with MSWindows.
>   The problem with many high-end work flow products, according to consultants,
> is that they require programmers to build work flow applications using a high
> level scripting language.  This slows down the development process and takes
> end users out of the loop.  "InConcert's strength is its graphical work flow
> design tool, which makes it possible for end users rather than programmers
> to build work flow applications", says a consultant.
>     XSoft, which developed InConcert using the C++ programming language, has
> published more than 270 application program interfaces that enable end-users
> to integrate thiry part products with InConcert.  Developers can also use
> these APIs to embed software agents within InConcert that carry out processes
> in response to predefined events.
> 
>     Another beta user, the U.S. Air Force, is implementing a work flow
> system based on InConcert that specifies 1,400 tasks and 60 applications and
> will be used by 10,000 people.
> 
> ==============================================================================
> 
>    This is a good example of the beginning of the end of Ada inside the DoD
> for two reasons.  First, the Generals in charge are more and more going to
> see that the information processing needs can be meet by taking commercial
> products that are "open" and adapting them to defense needs, commercial
> products all being written in C/C++.  As 10,000 people and 60 applications
> is a serious integration effort, comparable in scope to most other DoD 
> software efforts, one success makes it easier to do this again and again,
> to the point where the Ada mandate becomes irrelevant.  It is impossible
> for the DoD RIGHT NOW to achieve a similar work flow system relying one
> any commercial or non-commercial system written in Ada.  As more and more
> systems inside the DoD are based on C/C++ systems, the Mandate also becomes
> uneconomical to retain.
>    The second reason that the Generals will desert Ada is that the success
> of these such efforts will get them to start asking what is going on with
> efforts like STARS to create Ada technology that increasingly is falling
> farther and farther behind the commercial world.  This questions the
> competence of either Ada or Ada contractors, neither of which does much
> good for retaining the Mandate.
> 
>     Thus my prediction: if you see more and more such stories about the
> DoD solving its problems using C/C++ commercial software products, then
> you know the handwriting will be on the wall for Ada.  Any given the
> technology I see at the commercial trade shows, I would bet MY money on
> seeing more and more such stories.
> 
> Greg Aharonian
> Source Translation & Optimization
>
 
Are you saying that the government should go out and develop an application
when there is a commercially available AND SUPPORTED product that meets the
need?  Doesn't sound very cost-effective to me.  In a situation like this
it would cost more for the government or Air Force to develop and maintain
a seperate package, irregardless of the language.  I would welcome the day
when the government can satisfy all it's requirements with commerically
developed and maintained packages.  Until that time comes (if it ever does)
the idea of having a single language for as much of the
government-developed software as possible makes sense.  I still maintain
that Ada is a reasonable choice for such a language.  Chasing after the
language de jour only componds the kind of problems that the use of Ada was
intended to address.

> 
> (In fact, maybe the DoD should change the name of the language.  When the
> disease AIDS first became well known, a diet product pronounced the same
> way changed its name because of confusion.  Given that most corporate
> executives think of the sound "ada" as standing for the Americans with
> Disabilites Act, are we not risking subconcious confusion for Ada as a
> disabled language :-)
> -- 
> **************************************************************************
> Greg Aharonian
> Source Translation & Optimiztion
> P.O. Box 404, Belmont, MA 02178

-----------------------------------------------------
Kevin Miller       | MITRE's lawyers can't moan,    |
MITRE Corporation  | 'Cause what's stated up there, |
Bedford, MA        | Is my opinion alone,           |
(617) 271-4520     | And not MITRE's to bear.       |
kjmiller@mitre.org |                                |
-----------------------------------------------------