* Re: Ada vs. Posix -- the battle continues
@ 1989-11-25 15:19 Erland Sommarskog
0 siblings, 0 replies; 2+ messages in thread
From: Erland Sommarskog @ 1989-11-25 15:19 UTC (permalink / raw)
Michael Lutz (mjl@prague.UUCP) writes:
>Actually, both Unix and Ada are products of the 1970's. The difference
>is that Unix, being primarily of commercial interest, has been able to
>evolve,
Now, if Unix has been able to evolve why hasn't it done that? It
still looks like a remnant from the sixties to me.
--
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
^ permalink raw reply [flat|nested] 2+ messages in thread
* A farewell to Ada
@ 1989-11-14 21:24 Ted Holden
1989-11-15 16:06 ` Ada William Thomas Wolfe, 2847
0 siblings, 1 reply; 2+ messages in thread
From: Ted Holden @ 1989-11-14 21:24 UTC (permalink / raw)
I've noticed that much of the present scholastic debate over Ada
involves fine points concerning the letter of the law (was Ada "intended"
to function in embedded systems etc.). This is the kind of thing I expect
to see associated with losing causes. Remember, the Apostle said
something like: "The letter of the law killeth, whereas the spirit giveth
life..." People involved with winning causes are usually too busy making
money to be arguing over the letter of the law.
The spirit of the Ada documents was never in doubt. What was wanted
was a language which could be used for every kind of software project,
from embedded system to large database, and run on every kind of computer
system, from micro to mainframe. Reasonable performance was expected on
all computers and for all projects. Ability to run with minimal OS and
other language support was wanted. Further, logical clarity and large-
scale re-usability of software was desired.
Journal articles indicate a continuing failure of Ada to work for embedded
systems as well as for large scale projects, a continuing failure to run
with acceptable performance on anything other than parallel or special-
purpose, expensive systems, and an actual gain in cross-system complexity
and decrease in the stated goal of reuseability. In particular, the
ordinary systems which most people will be seeing in front of them for the
next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.
C began with real machines, real programmers. The idea seems to have
been:
"Lets take a hard look at this little PDP-7 and design a language
which is one-to-one with its logical operations as many ways as
possible (the plus-plus operator and register increments and so on)
so that the code is as FAST as can be contrived, maximally easy to
implement (so that next year when we get our PDP7.5 or whatever,
we're back rolling in 2 weeks), and, within these constraints, is
as amenable to human logic as possible in a no-nonsense, point-and-
shoot kind of way, so that we end up with a kind of high-structured,
low-level language; a thinking-man's assembler. And then, let's
write an operating system (UNIX) in that language so that, when we
get our PDP-7.5, or the next year's computer, whatever it may be,
we're REALLY back rolling two weeks later.
The maximal ease of implementation was achieved by making the core
language as small as possible, other functionality being left to the
operating system and to libraries, some standard amongst UNIX systems and
others peculiar to various other OSs and hardware bases for which C would
be implemented. This allowed good and inexpensive C compilers to evolve
rapidly for PCs and other micros and, since the authors of those compilers
maintained the standard libraries as close as possible to the UNIX
implementations, C became the natural bridge between mid-sized and large
computers running UNIX and the micros.
C thus achieved its present position of dominance in the mini-micro world,
and appears to be well poised for the future as well. C++ appears to be
an entirely rational and intelligent extension of C, superimposing the
entire object-oriented paradigm including the features Ada leaves out.
In particular, there appears to be no more than a 5% performance
degradation, if that, going from C to C++, at least judging from Turbo C
2.0 and the Zortech C++ compiler, and I assume the same will hold true
when you start seeing good native-mode C++ compilers for UNIX.
In fact, C++ appears to BE the very language which Ada was supposed to be
(the spirit of the law) but never can and never will be.
Far from sharing this "real-world" sort of a heritage, Ada appears to have
its beginnings on the other edge of reality or non-reality, dependant on
one's point of view. Ada appears to have been designed as a physical
embodiment of state-of-the-art principles of "software-engineering",
whatever that's supposed to mean, seemingly by assembling 300 committee
members in a room, having each draw up a maximum possible wish-list of
features for a programming language and/or operating system, and then
adding up all of the lists to a "standard", with any considerations of
real-world computers being regarded as unimportant.
Ada is what you might expect from a programming language designed by
committee; it is unbelievably slow, an unbelievable resource hog,
involves constant dilemmas over which is the real OS today, Ada or UNIX,
Ada or Dos etc. i.e. do we use Ada tasking, again frighteningly slow, or
ordinary UNIX tasking and inter-process communication, Ada source control
or SCCS, etc. Naturally, the Ada task manager and the UNIX process
scheduler clash. As for compiling, my experience has been that, with a
PC and lots of memory to play with, Ada compilers at least will get back
to you on the same DAY; on a UNIX machine with ten other users doing
various other kinds of things, God forbid other Ada compiles, forget it.
The one thing which one might reasonably expect all of this slowness and
clunk to purchase, the one thing which might partially redeem the
situation were Ada to have it, is the object oriented paradigm:
inheritance of classes and polymorphism. Ada doesn't have it.
Most of the Ada journal articles begin with glowing headlines, and you
have to be able to read between the lines, but this isn't terribly
difficult. For instance, a large section of articles in the December 88
Journal of Electronic Defense began with the title "Ada: Maybe Not So Bad
After All". Remember, Ada has been around since 1979. If that were the
best anybody could say about C after ten years, C compiler salesmen would
be starving and dying like flies.
A senior Intel product marketing engineer is quoted on page 36 of the
same issue:
"the people who designed the Ada programming language were compiler
experts, software experts - they weren't necessarily people familiar
with real-time embedded systems."
Another article in the same issue describes the use of Ada in connection
with a real-time embedded digital signal processing application. Since
Ada tasking could not be made fast enough for such work, the engineers
adapted a commercial run-time system, VRTX, and informed all programmers:
"Thou shalt not use Ada tasking, but rather VRTX tasking.
"Thou shalt not use Ada dynamic memory allocation...
"Thou shalt not use Ada generics; too slow...
and, when they finished with the "Thou shalt nots", what they had
left of Ada was a subset of Pascal which they had paid many thousands of
dollars for. A far better Pascal compiler is produced by Borland and can
be had at B Dalton's for around $100. Needless to say, the Rupe-
Goldbergesque system they ended up with was considerably less maintainable
than they might have gotten just using C. This seems to be the rule.
The September/October 88 issue of Defense Computing carried a similar
article: "Running in Real Time: A Problem for Ada". All other stories
concerning Ada and embedded systems read similarly.
Does Ada work any better for large scale systems? Another article
in the same Journal of Electronics Defense issue describing use of Ada on
the 1,246,000 line Army AFATDS system claims that:
"Ninety percent of the software requirements were met with no major
software problems."
as if this were good. The man is claiming that he had major language-
related problems with 124,600 lines of code out of 1,246,000. Again C
language is not noted for this kind of thing, nor would C be around if it
were.
There was a recent DOD Computing Journal Article titled "Is Ada
Getting Better or Just Older?". Again you don't read that sort of thing
about C. There is the August 21 89 issue of Government Computer News
describing the problems which the huge FAA Advanced Automation System is
having due to IBM Ada implementations and tools (or lack thereof).
The SoftTech notes from the RICIS convention included mention of one
speaker's statement: "Ada and UNIX doesn't work". I've heard that a
million times from users, first time that succinctly in print. Between
UNIX and Ada, UNIX is the real-world standard; conflicts between it and
Ada will not be resolved in favor of Ada. Hate to disillusion anybody...
It would appear that the articles written by the real-time people are
saying "well, it isn't doing us any good but it must be working out great
for the mainframe guys, else why would we still be seeing it and be
ordered to use it?" and that the mainframe and database crowd is claiming
just the opposite. Somebody must be hoping that nobody ever reads all of
these articles and starts putting two and two together.
There are numerous problems associated with the fact that Ada
believes itself to be an OS, aside from the clashes between Ada and real
operating systems. There is the further obvious problem that somebody
with a large mainframe/Cobol application which he thinks to port to a
UNIX/Ada system will need to redesign and rewrite his entire system from
scratch whereas, using C language, he might have written Cobol-callable
routines incrementally and had his application back up in a matter of days
or weeks instead of years. There is no real way to call an operating
system from a Cobol program.
The actual use of Ada is further complicated by three considerations
which really amount to theological problems INVOLVING Ada rather than
faults of Ada itself, but which, nonetheless, probably wouldn't exist if
Ada didn't exist.
First, the programming style being promulgated by DOD for Ada is anti-
conducive to the stated goal of readability; it's like looking at a
thousand-page novel such as "War and Peace" with three or four lines of
programming code interspersed every second page or so. The verbiage hides
the logic. When every variable name looks like:
"NUMBER_OF_CROWS_SALLY_ANNS_GRANDMOTHER_SHOT_WITH_HER_12_
GAUGE_-LAST_TUESDAY",
then a single subroutine call (involving several such variables) can take
up a whole page. In my own scheme of things, I try to keep literature and
programming separate.
Second, DOD is often insisting on portability via Ada rather than
portability via UNIX, POSIX calls etc. This amounts to such things as
insisting, for instance, that vendors provide direct Ada hooks to a
database rather than simply writing an Ada -> C -> database hook. Typical
vendor response is either "F... You" or "Manana".
A third is an over-emphasis on design, which often leads to grief in the
real-world. I believe in designing in the large, nailing down interfaces
at tightly as possible, then rapid prototyping of individual modules,
followed by final design documentation and PDLs at low level. I know of
numerous horror stories involving design-totally-then-code, but one very
recent one, naturally involving Ada, seems to top all.
A military project involving Sun machines and Ada was abandoned after
something like 4 years and $30 million effort because of unacceptable
performance; database screens were taking over a minute to come up. The
design work had all been done according to your formula, the individual
modules had been designed, written, and tested, all according to the
standard military schedules and formulas (2167 etc.). Everything seemed
hunky dory, only when they put the fricking thing together, it was too
damned slow to use. And, the remarkable thing is, the very system the
military insists upon for management of software contracts prevented
anybody from knowing they were in trouble until four years and millions
had been blown. The government people involved were essentially reduced
to the role of actors in a Greek tragedy.
Asked for a solution, my firm weighed the choice between offering an Ada-
to-C converter and silence, and opted for silence.
It sometimes seems to me that the Soviet military is kept backwards in
computers by a temporary lack of funds, while our military is required by
law to be backwards, and that may not be temporary. Any rate, my guess
is that the general Russian skill with linguistics would prevent them from
ever being ensnared with Ada; they would take one look and toss it.
Slava Bogu.
Ada threatens to leave DoD stranded and technologically backwards;
out of the mainstream of American computer science. The better class of
programmers coming out of the schools will be used to the 2 second
compiles of Turbo C and Turbo Pascal. Offer them jobs involving Ada, and
most if not all of them are probably going to give you the finger,
figuring they'd be happier selling used cars for a living.
There is the further problem of our present micro market being a
completely open system; a representative of the KGB, the Turkish Empire,
the Green Dragon Tong, the successors to the AssHola Khomeini, Khadaffi,
or anybody else could walk into a B. Dalton's today and buy a copy of
Turbo C 2.0 or Zortech C++ for about $100. Again, if I were the guy up
there getting into machine gun and rocket fights at 1600 mph, the last
thing I'd want to hear was that my machine guns and rockets were working
slower and/or less reliably than the other guy's because he bought a copy
of Turbo C at B. Dalton's, while my people were spending billions on Ada.
Ted Holden
HTE
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Ada
1989-11-14 21:24 A farewell to Ada Ted Holden
@ 1989-11-15 16:06 ` William Thomas Wolfe, 2847
1989-11-20 16:47 ` Ada vs. Posix -- the battle continues mjl
0 siblings, 1 reply; 2+ messages in thread
From: William Thomas Wolfe, 2847 @ 1989-11-15 16:06 UTC (permalink / raw)
From article <14033@grebyn.com>, by ted@grebyn.com (Ted Holden):
> Journal articles indicate a continuing failure of Ada to work for embedded
> systems as well as for large scale projects, a continuing failure to run
> with acceptable performance on anything other than parallel or special-
> purpose, expensive systems, and an actual gain in cross-system complexity
> and decrease in the stated goal of reuseability.
This is blatantly false; consider the November 1988 article
in IEEE Software ("Large Ada projects show productivity gains"):
After years of development and an initial skeptical reception,
many people are now using Ada and saying that they like it...
The growth in Ada's use has been helped by favorable reports
from early adopters ("Ada Catches on in the Commercial Market,
Soft News, IEEE Software, November 1986, p. 81) and by the
growing number of validated compilers... project results show
that Ada can greatly increase productivity for large systems...
[in a 1.2-million-line Ada project] reuseable software developed
on the project was counted only once. Roughly 13 percent of the
delivered software was reuseable. This reuse saved 190 man-months
of effort (a 9-percent savings) and reduced the schedule by two
calender months (a 4-percent savings)... Productivity for the
execution environment -- including the operating system, data
management, information management, communications support, and
communications interface -- was 550 lines per man-month...
Productivity for the applications software... was 704 lines per
man-month... the average productivity of the 1,500 systems in
productivity consultant Lawrence Putnam's database: 77 lines
per man-month (at the 1.2-million-line level)...
Sounds like a continuing *success* to me...
> In particular, the
> ordinary systems which most people will be seeing in front of them for the
> next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.
Precisely the point of Dr. Charles McKay, head of the Software
Engineering Research Consortium, in his Tri-Ada '88 presentation,
"Standards for the Sake of Standards -- A Recipe for Failure".
A prime example is Unix; the current POSIX effort aims to
standardize 1960's technology, thus resulting in a "lowest
common denominator" which locks users into obsolescence.
Ada's problem with Unix is that Unix, being 1960's technology,
does not properly support lightweight processes. Modernized
versions of Unix (e.g., MACH) which are designed to provide
such support remove the difficulty. Note that C or C++ programs
making use of the same "heavyweight" tasking facility will be
equally slow, since they rely on precisely the same system.
If one does not have to struggle with the limitations of *Unix*,
then there is a wide selection of Ada compilers which run Ada
within that environment quite nicely. Some, like the Telesoft
TeleGen2 compiler, have global optimization facilities which
result in better code than that which can be produced by current
C compilers (as of Tri-Ada '88).
> C began with real machines, real programmers. The idea seems to have
> been: [...] end up with a kind of high-structured, low-level language;
> a thinking-man's assembler.
Yes, as one Usenetter's .signature states, "C combines the power
of assembly language with the flexibility of assembly language".
Fortunately, the economics of software development are in favor
of using considerably higher-level languages.
> C++ appears to BE the very language which Ada was supposed to be
> (the spirit of the law) but never can and never will be.
Total rubbish; C++ retains all the low-level and dangerous
facilities of C, which is obsolescent by modern software
engineering standards. As stated by Fairley (Software
Engineering Concepts, page 228),
Modern programming languages provide a variety of
features to support development and maintenance of
software products. These features include strong
type checking, separate compilation, user-defined
data types, data encapsulation, data abstraction,
generics, flexible scope rules, user-defined exception
handling, and concurrency mechanisms. This chapter
discusses these concepts...
Now C++ has one useful feature which Ada does not: inheritance.
But it is also (as its designer freely admits) lacking in
generics and exception handling, and also does not provide
a means of expressing concurrency in a standardized, portable way.
Since tools such as Classic Ada permit the use of inheritance with
Ada (generating *standardized*, compile-it-anywhere code), this is
something which can be worked around until Ada 9X brings it in directly.
> Ada is what you might expect from a programming language designed by
> committee; it is unbelievably slow, an unbelievable resource hog,
This has been a property of some early Ada *compilers*, but is
not a property of the Ada *language*. Fortunately, compiler
technology is now capable of delivering tight, efficient Ada
object code, better than that being produced by C compilers.
Compilation is slower because the Ada compiler is doing much
more work for you; this reflects again the economics of software
development in that machine time is cheaper than programmer time.
> [...] There is the August 21 89 issue of Government Computer News
> describing the problems which the huge FAA Advanced Automation System is
> having due to IBM Ada implementations and tools (or lack thereof).
Are you saying that this is the fault of the *language*, or of IBM?
> There is no real way to call [Ada] from a Cobol program.
Ada users can call COBOL or any other language using pragma
INTERFACE; COBOL needs to have a similar standardized means
of calling other languages. Given that it does not, ad hoc
means of calling other languages have been devised; there is
no reason why such techniques cannot be used to call Ada just
as well as C or any other language. But this is COBOL's problem,
not Ada's.
> the programming style being promulgated by DOD for Ada [descriptive
> variable names] is anti-conducive to the stated goal of readability;
To C hackers, who are accustomed to single-letter variables, yes.
Software engineering specialists tend to have the opposite perspective.
> Second, DOD is often insisting on portability via Ada rather than
> portability via UNIX, POSIX calls etc. This amounts to such things as
> insisting, for instance, that vendors provide direct Ada hooks to a
> database rather than simply writing an Ada -> C -> database hook. Typical
> vendor response is either "F... You" or "Manana".
And the response of the Ada community is to turn to companies
such as The Ada Ace Group, Inc., a technical consulting company
specializing in the development of Ada interface to software
products and applications. They provide customized pure Ada
interfaces to existing commercial software products, such as
databases, operating systems, and specific applications such
as X-Windows. (Contact information: 4254 Indigo Drive,
San Jose, CA 95136; (408) 267-8296) Do you really think the
Ada community, with its emphasis on standardization and vendor
independence, is going to be stopped by an intransigent vendor?
> A military project involving Sun machines and Ada was abandoned after
> something like 4 years and $30 million effort because of unacceptable
> performance; database screens were taking over a minute to come up. The
> design work had all been done according to your formula, the individual
> modules had been designed, written, and tested, all according to the
> standard military schedules and formulas (2167 etc.). Everything seemed
> hunky dory, only when they put the fricking thing together, it was too
> damned slow to use. And, the remarkable thing is, the very system the
> military insists upon for management of software contracts prevented
> anybody from knowing they were in trouble until four years and millions
> had been blown. The government people involved were essentially reduced
> to the role of actors in a Greek tragedy.
>
> Asked for a solution, my firm weighed the choice between offering an Ada-
> to-C converter and silence, and opted for silence.
How about applying a profiler and recoding the "hot spots"?
If the slowness of Unix process handling is a problem, then
a more modern version of Unix should be used. Your company
should have considered more than two options.
There are problems in the government management process, but
this pertains to the government and not to Ada.
Bill Wolfe, wtwolfe@hubcap.clemson.edu
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Ada vs. Posix -- the battle continues
1989-11-15 16:06 ` Ada William Thomas Wolfe, 2847
@ 1989-11-20 16:47 ` mjl
0 siblings, 0 replies; 2+ messages in thread
From: mjl @ 1989-11-20 16:47 UTC (permalink / raw)
In article <7053@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>> In particular, the
>> ordinary systems which most people will be seeing in front of them for the
>> next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.
>
>
> A prime example is Unix; the current POSIX effort aims to
> standardize 1960's technology, thus resulting in a "lowest
> common denominator" which locks users into obsolescence.
Actually, both Unix and Ada are products of the 1970's. The difference
is that Unix, being primarily of commercial interest, has been able to
evolve, whereas Ada, a government sponsored thing-a-ma-bob, has
stagnated. It's a shrine to the ideas of 1975, both good and bad. The
fact that Unix has evolved in ways incompatible with Ada says as at
least as much about Ada as it does about Unix.
I followed the development of Ada from its inception as Strawman, and
became increasingly more depressed as the work proceeded. The good
concepts Ada embodies are overwhelmed by its complexity (see Hoare's
excellent discussion of this in his Turing Lecture -- all of his
comments still apply).
Ada is the PL/I of the 70's, unusable until the mid-80's; is it destined
to be the choke-collar of DoD software development in the 90's?
Mike Lutz
Mike Lutz Rochester Institute of Technology, Rochester NY
UUCP: {rutgers,cornell}!rochester!rit!mjl
INTERNET: mjlics@ultb.isc.rit.edu
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1989-11-25 15:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-11-25 15:19 Ada vs. Posix -- the battle continues Erland Sommarskog
-- strict thread matches above, loose matches on Subject: below --
1989-11-14 21:24 A farewell to Ada Ted Holden
1989-11-15 16:06 ` Ada William Thomas Wolfe, 2847
1989-11-20 16:47 ` Ada vs. Posix -- the battle continues mjl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox