The actual quote from the Post AAS article

The actual quote from the Post AAS article

[Mike Berman]

There have been a few posts referring to the 8 March Washington Post
article, "Out-of-Control Contract - How IBM's Effort to Modernize FAA's
Air Traffic Monitoring System Went Awry". 

Out of a several hundred word (~60 column inch) article, Ada is mentioned
directly in one paragraph only:

	"Adding a further level of complexity was the
	government's insistence that the entire project be done using a
	new computer language called Ada. The federal government was
	attempting to control a muddle of incompatible software
	languages by standardizing, but many programmers had to learn
	the exotic language from scratch."

"... new ..."? "... exotic ..."?!?

The majority of the article talks of enormous requirements documentation,
high reliability requirements ("The FAA wanted extreme reliability in
the network. 'The system has to be up and available for all but three
seconds a year,' [IBM Federal Systems chairman] Ebker said."),
continually changing requirements, lack of testing, management
problems ("Middle-level IBM managers began on their own
authority to circumvent formal practices by which software is vetted
within the company before being allowed into use, Ebker said. 'The
problem is key individuals in key slots who didn't do their jobs'), and
lack of adeequate software tools.

The article is pretty straightforward in placing "blame" on all factors
taken in toto, not representing IBM's failures as failure due to the use
of Ada. In fact, it appears that the article's author knows little about
the language (or software engineering, or even programming, for that matter).
Let's face it, the "exotic" features of the language are the same or
less exotic than the features found in OOP languages.

Any attempt to assert, based on the information in this article, that Ada
is the sole reason for failure, or even a major contributing factor, is
absurd. This project would have failed using any implementation
language.


-- 
Mike Berman
University of Maryland, Baltimore County	Fastrak Training, Inc.
berman@umbc.edu					(301)924-0050

Re: The actual quote from the Post AAS article

[Robert I. Eachus]

In article <1no3fbINN3h7@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:

  > Any attempt to assert, based on the information in this article, that Ada
  > is the sole reason for failure, or even a major contributing factor, is
  > absurd. This project would have failed using any implementation
  > language.

    This assumes that the project should be counted as a failure.  While
there have been a number of delays and cost overruns involving the ATC
moderization project, last I heard:

     The new system is a huge improvement over its predecessor.

     Upgrading of towers and en-route control centers is proceding.

  And last but not least:

      All modern ATC systems, in this country and elsewhere, are being
built in Ada.

  The real criticism that can and has been leveled at the FAA in this
project is that their insistance on sticking with IBM (or compatible)
hardware caused major delays in upgrading the US commercial ATC
system.  

  Incidently, if Ted Holden doesn't want to trust transportation
systems written in Ada, his transportation options will soon be
limited to automobiles.  Ada is also beginning to dominate software
for rail and ship traffic control systems.

--

					Robert I. Eachus

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

Re: The actual quote from the Post AAS article

[Michael Feldman]

In article <1no3fbINN3h7@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:
>
[stuff deleted]

>Out of a several hundred word (~60 column inch) article, Ada is mentioned
>directly in one paragraph only:
>
>	"Adding a further level of complexity was the
>	government's insistence that the entire project be done using a
>	new computer language called Ada. The federal government was
>	attempting to control a muddle of incompatible software
>	languages by standardizing, but many programmers had to learn
>	the exotic language from scratch."
>
>"... new ..."? "... exotic ..."?!?
>
[stuff deleted]
>
>The article is pretty straightforward in placing "blame" on all factors
>taken in toto, not representing IBM's failures as failure due to the use
>of Ada. In fact, it appears that the article's author knows little about
>the language (or software engineering, or even programming, for that matter).
>Let's face it, the "exotic" features of the language are the same or
>less exotic than the features found in OOP languages.
>
>Any attempt to assert, based on the information in this article, that Ada
>is the sole reason for failure, or even a major contributing factor, is
>absurd. This project would have failed using any implementation
>language.
>
Thanks for posting this, Mike. In fact, I was going to dig out Monday's
paper and post this paragraph myself, then I bumped into yours. Anyone
who knows anything about the FAA project knows that Ada has little or 
nothing to do with its success or failure. Ted's out there on his own
again.

Europe is rebuilding all its ATC systems in Ada; Ada is now the de facto
standard language for new ATC systems world-wide. People I know who are
close to the FAA project tell me that Europe's ATC problems are on a
much smaller scale than ours - many fewer flights. I wish IBM and FAA
well getting us a system we can use; you can read the Post article for
details of the ups and downs. But don't point the finger at Ada. 

Oh - a word of warning - if you hate Ada, don't fly into Copenhagen.

Cheers all -

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

Re: The actual quote from the Post AAS article

[Mike Berman]

(Robert I. Eachus) writes:
>In article <1no3fbINN3h7@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:
>
>  > Any attempt to assert, based on the information in this article, that Ada
>  > is the sole reason for failure, or even a major contributing factor, is
>  > absurd. This project would have failed using any implementation
>  > language.
>
>    This assumes that the project should be counted as a failure.

Oops. My mistake. Replace all occurrences of the word 'failure'
above with 'its failings'. Apologies to all those who have put hard work
into AAS!

I'm too used to seeing the following aberrated logic:

	Project X failed, was delayed, went way over cost, etc.
	Project X used Ada.
	=> Project Y should not use Ada or it will fail.

This is generally done via statistics taken completely out of context
which, at best, are anecdotal anyway. BTW, Ada benefactors use such
statistics as freely as do its detractors.

I always want to know the story behind the story. What kind of software
process is in place? What training did the software engineers and
managers receive? From the points raised in the article, it appears that
these and several critical factors were lacking.

To date, I have not seen clear evidence that any project has failed
solely because of the use of Ada. Most failure and setbacks that we hear
about concerning Ada efforts are also large, ambitious, highly political
situations. When all project factors are taken into account, the answer
to the question "would this project be in the same (or similar)
situation had we used [place language here]?" is "yes".

I know, I know ... preaching to the choir!

>					Robert I. Eachus

-- 
Mike Berman
University of Maryland, Baltimore County	Fastrak Training, Inc.
berman@umbc.edu					(301)924-0050

Re: The actual quote from the Post AAS article

[Tom Pole]

In article <1no3fbINN3h7@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:
>
>There have been a few posts referring to the 8 March Washington Post
>article, "Out-of-Control Contract - How IBM's Effort to Modernize FAA's
>Air Traffic Monitoring System Went Awry". 
>
>Out of a several hundred word (~60 column inch) article, Ada is mentioned
>directly in one paragraph only:
>
>	"Adding a further level of complexity was the
>	government's insistence that the entire project be done using a
>	new computer language called Ada. The federal government was
>	attempting to control a muddle of incompatible software
>	languages by standardizing, but many programmers had to learn
>	the exotic language from scratch."
>
>"... new ..."? "... exotic ..."?!?

... other good stuff deleted.

>
>Any attempt to assert, based on the information in this article, that Ada
>is the sole reason for failure, or even a major contributing factor, is
>absurd. This project would have failed using any implementation
>language.
>

The point is that these problems were known to be the major culprits
in the "software crises" and Ada was supposed to solve them.

		Thomas

>
>-- 
>Mike Berman
>University of Maryland, Baltimore County	Fastrak Training, Inc.
>berman@umbc.edu					(301)924-0050


-- 

Thomas Pole

Re: The actual quote from the Post AAS article

[Charles H. Sampson]

In article <1993Mar12.161548.6286@evb.com> pole@evb.com (Tom Pole) writes:
-In article <1no3fbINN3h7@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:
->
->There have been a few posts referring to the 8 March Washington Post
->article, "Out-of-Control Contract - How IBM's Effort to Modernize FAA's
->Air Traffic Monitoring System Went Awry". 
->
->Out of a several hundred word (~60 column inch) article, Ada is mentioned
->directly in one paragraph only:
->
->	"Adding a further level of complexity was the
->	government's insistence that the entire project be done using a
->	new computer language called Ada. The federal government was
->	attempting to control a muddle of incompatible software
->	languages by standardizing, but many programmers had to learn
->	the exotic language from scratch."
->
->"... new ..."? "... exotic ..."?!?
-
-... other good stuff deleted.
-
->
->Any attempt to assert, based on the information in this article, that Ada
->is the sole reason for failure, or even a major contributing factor, is
->absurd. This project would have failed using any implementation
->language.
->
-
-The point is that these problems were known to be the major culprits
-in the "software crises" and Ada was supposed to solve them.

     I've lost track of who edited whom, but what is missing in the above
is a large number of claims about non-programming problems, among them
one that mid-level IBM managers had been circumventing established proce-
dures for vetting software.  I don't know of any language that can solve
that problem.  I certainly don't think Ada proponents have every claimed
it for Ada.

				Charlie

Re: The actual quote from the Post AAS article

[Michael Feldman]

In article <EACHUS.93Mar11163046@goldfinger.mitre.org> eachus@goldfinger.mitre.org (Robert I. Eachus) writes:
>
[good stuff deleted]

>  Incidently, if Ted Holden doesn't want to trust transportation
>systems written in Ada, his transportation options will soon be
>limited to automobiles.  Ada is also beginning to dominate software
>for rail and ship traffic control systems.
>
Hmmm. Maybe cars are off limits to him too. Rumors have circulated,
which nobody could confirm but were said to be reliable, that GM has used
Ada in transmissions. 'Course Ted probably drives a Honda anyway.

Would you believe mopeds?

Mike Feldman

Re: The actual quote from the Post AAS article

[Michael Feldman]

In article <EACHUS.93Mar11163046@goldfinger.mitre.org> eachus@goldfinger.mitre.org (Robert I. Eachus) writes:
>
>  Incidently, if Ted Holden doesn't want to trust transportation
>systems written in Ada, his transportation options will soon be
>limited to automobiles.  Ada is also beginning to dominate software
>for rail and ship traffic control systems.
>
An article in today's Washington Times (the Moonie paper) described in some
detail the new highway traffic control system in Montgomery County, MD.
It includes TV cameras over the freeways, computer-generated maps, central 
reprogramming of traffic signals, etc. It also mentioned that there are
plans to integrate GPS (global-positioning satellite) tracking of
police and fire vehicles, towtrucks, county transit buses, etc.

The article specifically mentioned Fairchild as the contractor, and
stated that the technology is adapted from military stuff used in
Desert Storm. They showed some PC-looking screens with pretty
county roadmaps in them, in the control room in Rockville.

First comment: this is a neat dual-use technology.

Second comment: it would be nice to know if Ada were in this project.

Anybody happen to know?

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

Re: The actual quote from the Post AAS article

[Michael Feldman]

In article <1993Mar12.161548.6286@evb.com> pole@evb.com (Tom Pole) writes:

[stuff deleted]
>
>The point is that these problems were known to be the major culprits
>in the "software crises" and Ada was supposed to solve them.
>
Ada was to provide a _common language_ for the systems in its problem
domain. In 1973 or thereabouts, there were anywhere from 200-1000
different languages in use around DoD (I guess nobody knew for sure).
A common language is surely one useful component of a solution to the
"software crisis". Only one. Anyone who said or thought Ada, by itself, would
solve anything but the language Babel, was either a fool or a liar. There
was a lot of Ada hype in the early days; my impression at the time was that
much of the hype was produced by the "training terrorists" of the day.

I know of _nobody_ with enough education and honesty to distinguish
between a programming language and methodologies, management smarts,
contracting smarts, etc., who promised that Ada would be a panacea.

Surely nobody believes that of _any_ mere programming language nowadays...

Mike Feldman

Re: The actual quote from the Post AAS article

[David Weller]

In article <1993Mar12.161548.6286@evb.com> pole@evb.com (Tom Pole) writes:
>In article <1no3fbINN3h7@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:
>>
>>[Quotes from the March 8th Washington Post article deleted]
>>
>>Any attempt to assert, based on the information in this article, that Ada
>>is the sole reason for failure, or even a major contributing factor, is
>>absurd. This project would have failed using any implementation
>>language.
>>
>
>The point is that these problems were known to be the major culprits
>in the "software crises" and Ada was supposed to solve them.
>
>		Thomas
>

I'll be nice (for once, eh, Mike?) and turn on my flamethrower, so instead,
I'll flic-my-bic:

Tom, you seem to imply that Ada holds _some_ blame in the AAS problems,
since you point out that Ada was supposed to solve many of them.  I would
appreciate it if you told us "netters" out here is you meant "solve"
to really mean "reduce", or if you actually meant to make some 
unsupportable claim that Ada was supposed to genuinely solve the 
software crisis.   

In any case, this argument boils down to the issue of language choice.
Us "Ada Supporters" claim that any other language would have fared
just as badly (if not worse), precisely because NO OTHER language was
ever built to support systems on the scale Ada was.  This is not to
claim that one cannot build a large system in another language (say, C++),
but that doing so would require more resources.  THAT was the bottom
line with Ada -- the software crisis was "more complex systems with
(possibly) fewer resources", and Ada was designed to tackle such problems.

>>
>>-- 
>>Mike Berman
>>University of Maryland, Baltimore County	Fastrak Training, Inc.
>>berman@umbc.edu					(301)924-0050
>
>
>-- 
>
>Thomas Pole

dgw

Re: The actual quote from the Post AAS article

[news]

In article <1993Mar12.232510.7619@seas.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:

*>  Incidently, if Ted Holden doesn't want to trust transportation
*>systems written in Ada, his transportation options will soon be
*>limited to automobiles.  Ada is also beginning to dominate software
*>for rail and ship traffic control systems.

*Hmmm. Maybe cars are off limits to him too. Rumors have circulated,
*which nobody could confirm but were said to be reliable, that GM has used
*Ada in transmissions. 'Course Ted probably drives a Honda anyway.
*Would you believe mopeds?

Try a 1986 Merkur, 5 forward speeds plus turbocharger.  I avoid Japanese
cars out of patriotism, GM cars out of a normal instinct for survival.  And
when the ultimate total collapse of Ada air-traffic control grounds you, 
I'll still be up there, safe from the clutches of the FAA.



-- 
Ted Holden
HTE

Re: The actual quote from the Post AAS article

[Michael Feldman]

In article <343@fedfil.UUCP> news@fedfil.UUCP (news) writes:
>
>Try a 1986 Merkur, 5 forward speeds plus turbocharger.  I avoid Japanese
>cars out of patriotism, GM cars out of a normal instinct for survival.  And
>when the ultimate total collapse of Ada air-traffic control grounds you, 
>I'll still be up there, safe from the clutches of the FAA.
>
Hmmm. Which country do you live in, Ted? Not the US, I presume. It's 
patriotic to drive a German car but not a Japanese one, eh? For which
land are you a patriot?

RE: air traffic control: Ted, which countries will you fly into, out of,
or over? Every one of them either is running on Ada now, or will be
very shortly. Even Germany. (Can't speak for Japan - dunno.)

Mike

Re: The actual quote from the Post AAS article

[Mike Berman]

Hmmm...

The intent of making this a separate thread from the original posting on
the subject was to avoid a Ted Holden vs. the net flame exchange. Oh
well!

Straying from the topic of where Ted flies and what he drives...

If I remember my chronology correctly, the state-of-the-art in software
engineering awareness has matured along with its practice. When FORATRAN
was developed, it was considered by many to be a high level
_specification language_ which, relative to the machine and assembly
code programming of the day, it was. By today's standards of reuse and
portability, FORTRAN programs from two or three decades ago are
considered rather low level programming (low level meaning
application/machine dependent, not any kind of quality statement).

During the '70's, Ada was developed to address the software crisis in
very specific terms - the question was "Is it possible to design a
language which incorporates software engineering features?" (well, one
question - standardization on a single DoD programming language was a
biggie, too).

The answer is yes - Ada and many modern languages are living proof of
that.

Is is the _entire_ answer? No. The "component-based software society"
with its "software ICs" didn't occur in 1983 and is still barely present
today. Ada does not solve the software crisis - but its precepts are
most certainly a part of that solution.

Look at any of the software reuse guidelines developed over the last few
years. Language is identified as one relatively small part of the
problem. Cultural changes, process, all that Watts Humphrey stuff -
those are other key ingredients.

The development of OO paradigms has taken a parallel tack. OOPLs like
Smalltalk were up first. For large developments going straight to coding
isn't wise, hence the need for OOD. But OOD doesn't map well from
functional requirements, therefore OOA is needed.

The point of this Sunday A.M. rambling is (1) it beats shovelling snow,
and (2) nobody up front said "Hey, wouldn't it make things easier if we
wrote object-oriented requirements?" Similarly, while Ada may have been
envisioned as a "solution" to the software crisis in 1974, we're a lot
smarter about software engineering needs in 1993.

-- 
Mike Berman
University of Maryland, Baltimore County	Fastrak Training, Inc.
berman@umbc.edu					(301)924-0050

Re: The actual quote from the Post AAS article

[Don Tyzuk]

news@fedfil.UUCP (Ted Holden) writes:


>                                                  ...   I avoid Japanese
>cars out of patriotism,  ... 

"Patriotism is the last refuge of a true scoundrel."  


-- 
Don Tyzuk				| P.O. Box 1406
Jodrey School of Computer Science	| Wolfville, Nova Scotia
Acadia University			| CANADA     B0P 1X0
e-mail: don.tyzuk@acadiau.ca

Re: The actual quote from the Post AAS article

[news]

In article <1993Mar14.003649.24085@seas.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
*In article <343@fedfil.UUCP> news@fedfil.UUCP (news) writes:

*>Try a 1986 Merkur, 5 forward speeds plus turbocharger.  I avoid Japanese
*>cars out of patriotism, GM cars out of a normal instinct for survival.  And
*>when the ultimate total collapse of Ada air-traffic control grounds you, 
*>I'll still be up there, safe from the clutches of the FAA.

*Hmmm. Which country do you live in, Ted? Not the US, I presume. It's 
*patriotic to drive a German car but not a Japanese one, eh? For which
*land are you a patriot?

America.  The Merkur is a Ford product, and beyond that, trade with Germany,
Italy, England, and other european nations has never harmed this country
the way that trade with Japan has;  they do not attempt to use this
country like a colony.  If you lived here and paid attention, you'd know that.

*RE: air traffic control: Ted, which countries will you fly into, out of,
*or over? Every one of them either is running on Ada now, or will be
*very shortly. Even Germany. (Can't speak for Japan - dunno.)
*Mike

A small enough plane landing at small enough places might still survive.
The others won't be running or flying on Ada;  they'll be crashing into
eachother on Ada.


-- 
Ted Holden
HTE

Re: The actual quote from the Post AAS article

[Michael Shapiro]

berman@umbc.edu (Mike Berman) writes:

> If I remember my chronology correctly, the state-of-the-art in software
> engineering awareness has matured along with its practice. When FORATRAN
> was developed, it was considered by many to be a high level
> _specification language_ which, relative to the machine and assembly
> code programming of the day, it was. By today's standards of reuse and
> portability, FORTRAN programs from two or three decades ago are
> considered rather low level programming (low level meaning
> application/machine dependent, not any kind of quality statement).

I seem to recall Backus, in a talk, pointing out that FORTRAN was an 
experiment aimed at proving that you could write in a "higher level 
language" (I think the term may have come later) and get as good code out 
as an experienced assembly-language programmer could produce ... or maybe 
better.  That was the reason the early FORTRAN has a FREQUENCY statement, 
so you could tell the compiler which order to test multiway branching, 
for example.

This discussion does bring up one of the points I make from time to time, 
the observation is the only "high order" language around.  All the others
are "high level" languages.  I have the feeling that this arbitrary 
change of nomenclature (seemingly traced back to the HOLWG) gives people 
the feeling that the DoD doesn't really want Ada to fit in with the 
community of programming languages.


--                    
INTERNET:  mshapiro@netlink.cts.com (Michael Shapiro)
UUCP:   ...!ryptyde!netlink!mshapiro
NetLink Online Communications * Public Access in San Diego, CA (619) 453-1115

Re: The actual quote from the Post AAS article

[Michael Feldman]

In article <8ceF1B1w165w@netlink.cts.com> mshapiro@netlink.cts.com (Michael Shapiro) writes:
>
>This discussion does bring up one of the points I make from time to time, 
>the observation is the only "high order" language around.  All the others
>are "high level" languages.  I have the feeling that this arbitrary 
>change of nomenclature (seemingly traced back to the HOLWG) gives people 
>the feeling that the DoD doesn't really want Ada to fit in with the 
>community of programming languages.
>
I think it goes back farther than the HOLWG. DoD has _always_ used the term
"high-order" languages. DoD also referred to ADP (Automatic Data Processing) 
in the old days when the rest of the US said EDP (Electronic Data Processing).

DoD also calls its TV dinners MRE's (Meals, Ready to Eat). I read that
they were distributing leftover MRE's from Desert Storm to homeless
shelters.

One can argue that it's weird that DoD has its own unique sublanguage
of American English; I think I'd agree. But I don't think that it has
anything in particular to do with Ada, or even with languages, and 
pre-dates Ada. DoD didn't _change_ the terminology; they've _always_
diverged from the rest of us. Perhaps they should change now, to agree
with the rest of the world, but that is a different argument.

The bottom line: Ada is NOT the only HOL. _All_ HLL's are HOL's to DoD.
And Ada is an HLL to me, whatever my DoD friends call it!

Ask your friends in the service if I'm right on this, though I'll bet they
are all younger than I...:-)

Mike Feldman

Re: The actual quote from the Post AAS article

[Kevin Rigotti]

In article <1993Mar11.213532.12259@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:

   Europe is rebuilding all its ATC systems in Ada; Ada is now the de facto
   standard language for new ATC systems world-wide. People I know who are
   close to the FAA project tell me that Europe's ATC problems are on a
   much smaller scale than ours - many fewer flights. 

Yes, Ada is what we're using and I'm glad that we are. I'm not too
sure about our ATC problems being easier though ... ;-)

Kevin

--
Email : rigotti@hermes.mod.uk    (MIME & ATK)
Fax   : +44 (0)684 894109.
Post  : ATC Systems Division, DRA Malvern, Malvern WR14 3PS, England
--

Re: The actual quote from the Post AAS article

[Michael Feldman]

In article <RIGOTTI.93Mar15105925@ad4su1> rigotti@hermes.mod.uk (Kevin Rigotti) writes:
>In article <1993Mar11.213532.12259@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>
>   Europe is rebuilding all its ATC systems in Ada; Ada is now the de facto
>   standard language for new ATC systems world-wide. People I know who are
>   close to the FAA project tell me that Europe's ATC problems are on a
>   much smaller scale than ours - many fewer flights. 
>
>Yes, Ada is what we're using and I'm glad that we are. I'm not too
>sure about our ATC problems being easier though ... ;-)
>
Hmmm. My sources around FAA tell me that the main reason for Europe's having
_fielded_ new ATC systems - In Ada - is that European air traffic is
simply less dense than that of the US; there are fewer planes flying fewer
corridors into fewer big airports. I know little about the internals of
ATC systems, but general intuition and experience tell me that problems
in this kind of system scale up perhaps linearly: 4 times the traffic 
results in a system 4 times as complex. Maybe the "big O" is even worse.
It would be nice if it were sublinear, but somehow I doubt it. 

The point is - once more for good measure - that Ada can hardly make an
ATC system worse to build and run, and may well make it better. The
"lessons learned" reports that will, I'm sure, eventually come out of the
European efforts, will be very interesting to read.

Mike Feldman

Re: The actual quote from the Post AAS article

[david.c.willett]

Mike Feldman wrote:

	{Initial Discussion about ATC Systems deleted}
>>
> Hmmm. My sources around FAA tell me that the main reason for Europe's having
> _fielded_ new ATC systems - In Ada - is that European air traffic is
> simply less dense than that of the US; there are fewer planes flying fewer
> corridors into fewer big airports. I know little about the internals of
> ATC systems, but general intuition and experience tell me that problems
> in this kind of system scale up perhaps linearly: 4 times the traffic 
> results in a system 4 times as complex. Maybe the "big O" is even worse.
> It would be nice if it were sublinear, but somehow I doubt it. 
>
	{Some Conclusions and Hopes for "lessons learned" deleted} 
> 
> Mike Feldman

It seems to me that the complexity of an ATC system would increase similarly
to the N-body problem from physics.  An example of such a problem is to
predict the motion of an electron travelling through a distribution of 
charges.  If memory serves, that problem is O(X**n) where N is the number
of charges and X is the number of electrons.
-- 
Dave Willett          AT&T Federal Systems Advanced Technologies
A Theoretical Physicist is one whose existence is postulated to make
the numbers balance, but is never observed in the laboratory.

Re: The actual quote from the Post AAS article

[Tom Pole]

A whole bunch of people said a whole bunch of stuff about the
Washington Post article about the FAA project....
>>>
>>>Any attempt to assert, based on the information in this article, that Ada
>>>is the sole reason for failure, or even a major contributing factor, is
>>>absurd. This project would have failed using any implementation
>>>language.
>>>
>>
>>The point is that these problems were known to be the major culprits
>>in the "software crises" and Ada was supposed to solve them.
>>
>>		Thomas
>>
>
....
>
>Tom, you seem to imply that Ada holds _some_ blame in the AAS problems,
>since you point out that Ada was supposed to solve many of them.  I would
>appreciate it if you told us "netters" out here is you meant "solve"
>to really mean "reduce", or if you actually meant to make some 
>unsupportable claim that Ada was supposed to genuinely solve the 
>software crisis.   

Okay, mea culpa. I tried to get away with a short reply, and now
I'm paying for it. 

Blame Ada for the software crises ? or the AAS problems ?
Absolutely not !!

I meant "help solve", and be a major player in the solution.

But go back and look at the discussions about why Ada was needed.
The bureaucrats discussions that wrote the mandate, not the
techie discussions. Although in some cases you can look at both.

It was to be one of the tools that would help the DOD solve the
software crises. Reuse was supposed to be there, and code generators,
and AI, and a bunch of other keywords.

I didn't make the claim that Ada would solve the software crises. I 
just heard it repeated, often.

I was just amused that someone tried to distance Ada from the reasons
why the project is in trouble, when Ada was supposed to be part of the
solution. Ada is a worthwhile language, I enjoy using it in some cases
(not all), and there are some projects I wouldn't work on unless
they were using Ada. Not many, but some.

>
>In any case, this argument boils down to the issue of language choice.
>Us "Ada Supporters" claim that any other language would have fared
>just as badly (if not worse), precisely because NO OTHER language was
>ever built to support systems on the scale Ada was.  This is not to

Well....., I think you should look at the switch software that AT&T uses.
Its not written in Ada, and it is HUGHHHHHH !!!!!!!. Not designed with
the 'large scale development support' requirements explicitly stated
does not mean 'built to support'. 'C' does support large scale
development. For that matter there are a lot of huge Cobol systems
that have been running for years. Not efficiently, but still running.
I'm not arguing the ability of controlling large projects using Ada.
Just that other languages do support large scale development.

>claim that one cannot build a large system in another language (say, C++),
>but that doing so would require more resources.  THAT was the bottom
>line with Ada -- the software crisis was "more complex systems with
>(possibly) fewer resources", and Ada was designed to tackle such problems.
>

Trained experienced developers and inexpensive proven SE tools are
resources. In these categories Ada requires hard to find resources, and
C requires easy to find resources. Sorry, but that makes a big difference.
A lot of C++ folk think that Ada requires greater resources. 

Actually, I seem to remember that the big reason was to stop the standard
DOD development cycle for embedded system development.

GAther requirements -> write language to represent requirements ->
build compiler for language -> write most of it in Assembly anyway ->
Get on a new contract before the plane you delivered the present
contract on crashes. :-)   <<<---- NOTE SMILEY !

I can't believe that I'm here sounding like (NOTE 'sounding like') I 
support using C/C++ and (shudder !!) Cobol.

I'm going to go write some Lisp, and read the rest of this thread
tomorrow.

>>>
>>>-- 
>>>Mike Berman
>>>University of Maryland, Baltimore County	Fastrak Training, Inc.
>>>berman@umbc.edu					(301)924-0050
>>
>>
>>-- 
>>
>>Thomas Pole
>
>dgw


-- 

Thomas Pole

Re: The actual quote from the Post AAS article

[Tom Pole]

In article <1993Mar13.000402.8785@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:
>In article <1993Mar12.161548.6286@evb.com> pole@evb.com (Tom Pole) writes:
>
>[stuff deleted]
>>
>>The point is that these problems were known to be the major culprits
>>in the "software crises" and Ada was supposed to solve them.
>>
>Ada was to provide a _common language_ for the systems in its problem
>domain. In 1973 or thereabouts, there were anywhere from 200-1000
>different languages in use around DoD (I guess nobody knew for sure).
>A common language is surely one useful component of a solution to the
>"software crisis". Only one. Anyone who said or thought Ada, by itself, would
>solve anything but the language Babel, was either a fool or a liar. There
>was a lot of Ada hype in the early days; my impression at the time was that
>much of the hype was produced by the "training terrorists" of the day.

I really like "training terrorists" !
Great term.
Of course I don't know of anyone who fits that description. No really !!

>
>I know of _nobody_ with enough education and honesty to distinguish
>between a programming language and methodologies, management smarts,
>contracting smarts, etc., who promised that Ada would be a panacea.
>

Honesty is the operant attribute. I agree completely. Either the
person was less than honest, or naively believed someone who was.

>Surely nobody believes that of _any_ mere programming language nowadays...

Except for most of the 'beginner' engineers you meet who have 
a favorite language. Any favorite language.

>
>Mike Feldman


-- 

Thomas Pole

Re: The actual quote from the Post AAS article

[fred j mccall 575-3539]

In <1993Mar15.035032.10779@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael Feldman) writes:

>In article <8ceF1B1w165w@netlink.cts.com> mshapiro@netlink.cts.com (Michael Shapiro) writes:
>>
>>This discussion does bring up one of the points I make from time to time, 
>>the observation is the only "high order" language around.  All the others
>>are "high level" languages.  I have the feeling that this arbitrary 
>>change of nomenclature (seemingly traced back to the HOLWG) gives people 
>>the feeling that the DoD doesn't really want Ada to fit in with the 
>>community of programming languages.
>>
>I think it goes back farther than the HOLWG. DoD has _always_ used the term
>"high-order" languages. DoD also referred to ADP (Automatic Data Processing) 
>in the old days when the rest of the US said EDP (Electronic Data Processing).

>DoD also calls its TV dinners MRE's (Meals, Ready to Eat). I read that
>they were distributing leftover MRE's from Desert Storm to homeless
>shelters.

If you can say with a straight face that an MRE is the same thing as a
TV dinner, you've obviously never eaten either one or the other of
them.  Actually, their 'TV dinner' is called a 'traypack' (sp?),
except that it's a TV dinner for 40 or so.  MRE's aren't TV dinners; I
would maintain that they are also not Ready to Eat, but that's another
matter. 

>One can argue that it's weird that DoD has its own unique sublanguage
>of American English; I think I'd agree. But I don't think that it has
>anything in particular to do with Ada, or even with languages, and 
>pre-dates Ada. DoD didn't _change_ the terminology; they've _always_
>diverged from the rest of us. Perhaps they should change now, to agree
>with the rest of the world, but that is a different argument.

The argument that Ada tends to use different words for concepts that
were already known in other parts of the industry by different names
is fairly true, I would say, but I'm not sure that 'HOL' is an example
of that particular 'newspeak'.

-- 
"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.

Re: The actual quote from the Post AAS article

[Michael Feldman]

In article <1993Mar16.210613.7208@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>
>The argument that Ada tends to use different words for concepts that
>were already known in other parts of the industry by different names
>is fairly true, I would say, but I'm not sure that 'HOL' is an example
>of that particular 'newspeak'.
>
I agree that some of Ada's terms differ from some of ither languages'
terms. But many of Ada's terms were inherited from general language
development work (elaboration comes to mind). These terms seem strange
because the Ada standard is the first one to try to teach them to
the general techie public.

"Access type" as a substitute for "pointer type" comes to mind as one of
the few Ada terms that was not in use before - and even that one may have
come from elsewhere, I don't know.

There is a general situation I have characterized as "Feldman's Law
of Programming Terminology": Two languages implementing the same idea
must, on pain of death, use different terms.

This is not uniquely an Ada problem. E.g., Prof. Wirth, in designing the 
Modula family, did so _after_ Ada's terms were known. He had any
number of existing terms he could choose for "package spec" and
"package body". But he chose "definition module" and "implemehntation
module". He also chose "opaque type" for roughly what Ada calls
a private type. Yes, I know there are subtle differences. That's
actually the point. No 2 languages do the same thing in _exactly_
the same way (it would be REAL boring if they did:-)), so the terms
have to be changed to make the difference obvious.

I think this problem will always be with us, especially in the 
computing business where so much is based on perception and
religion. We will continue making up the terms as we go along.
In this regard, Ada is squarely in the mainstream.

Mike Feldman

Re: The actual quote from the Post AAS article

[Gregory Aharonian]

>It seems to me that the complexity of an ATC system would increase similarly
>to the N-body problem from physics.  An example of such a problem is to
>predict the motion of an electron travelling through a distribution of 
>charges.  If memory serves, that problem is O(X**n) where N is the number
>of charges and X is the number of electrons.

   N-body problems in physics, under many conditions, can be numerically
handle without the combinatoric explosion of calculations due to 
interparticle forces (for example, gravitational problems can be simplified
for cluster like problems using trees where the nodes are center-of-masses,
while electrical problems like in quantum mechanics can be simpligfied
using generalized potentials).
   Unfortuantely, none of these procedures works with planes, so that there
is little analogy to be made.

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

Re: The actual quote from the Post AAS article

[Robert I. Eachus]

In article <1993Mar16.145422.14034@cbnewsl.cb.att.com> willett@cbnewsl.cb.att.c
om (david.c.willett) writes:

  > It seems to me that the complexity of an ATC system would increase
  > similarly to the N-body problem from physics...
     
  There are two different problems here, the complexity of the
software, and the computational difficulties of a particular number of
planes in the same airspace.  Mike was talking about the first, David
about the second.  Both are involved here.

  The highest aircraft densities in the world occur over Southern
California and the Boston-Washington corridor.  Most of this traffic
is general aviation not commerical, but the ATC system still has to
deal with it.  However a much nastier problem is that with the long
traffic corridors in the US and in some cases, several parallel
corridors, all of this traffic can be concentrated in just a small
slice of the sky.  This is a particular problem with, for example the
approaches to Hartsfield in Atlanta.

   The complexity of the software to deal with these things does not
grow at the same rate as the mathematical complexity of the
computation, but you do need to use much more sophisticated algorithms
to keep the mathematical complexity under control.  Also the reality
of the situation is that only a few countries have or need more than
one enroute control center, and the distribution requirements do make
the problem much harder.

    Sorry to spend so much time contributing data not heat to the
discussion... :-)

--

					Robert I. Eachus

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

Re: The actual quote from the Post AAS article

[david.c.willett]

From article <SRCTRAN.93Mar17170253@world.std.com>, by srctran@world.std.com (Gregory Aharonian):
> 
>>It seems to me that the complexity of an ATC system would increase similarly
>>to the N-body problem from physics.  An example of such a problem is to
>>predict the motion of an electron travelling through a distribution of 
>>charges.  If memory serves, that problem is O(X**n) where N is the number
>>of charges and X is the number of electrons.
> 
>    N-body problems in physics, under many conditions, can be numerically
> handle without the combinatoric explosion of calculations due to 
> interparticle forces (for example, gravitational problems can be simplified
> for cluster like problems using trees where the nodes are center-of-masses,
> while electrical problems like in quantum mechanics can be simpligfied
> using generalized potentials).
>    Unfortuantely, none of these procedures works with planes, so that there
> is little analogy to be made.
> 
> Greg Aharonian
> Source Translation & Optimization
> -- 
> **************************************************************************
> Greg Aharonian
> Source Translation & Optimiztion
> P.O. Box 404, Belmont, MA 02178

The simplifications you describe depend on the relative positions and densities
of the masses involved.  I think the analogy is apt.

-- 
Dave Willett          AT&T Federal Systems Advanced Technologies
A Theoretical Physicist is one whose existence is postulated to make
the numbers balance, but is never observed in the laboratory.