ted@grebyn.com (Ted Holden) (11/15/89)
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
HTEschmidt@PARIS.ICS.UCI.EDU (11/15/89)
In article <14033@grebyn.com>, ted@grebyn (Ted Holden) writes: >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. Along the same lines, lately I've heard a number of people make the claim that: `There now exist Ada compilers that produce faster code than C/C++ compilers.' Naturally, taken out of context this statement doesn't mean very much, since one can always find a lousy C/C++ compiler and an application that brings out the worst in the compiler and vice versa for Ada. Therefore, I'm curious to know what valid empirical studies have been performed to compare `x' Ada compilers against `y' C/C++ compilers across a representative set of benchmarks. Furthermore: 1. Which `top-of-the-line' Ada compilers produce the best code? 2. How long do they take to compile non-contrived programs? 3. What are their resource constraints and requirements? 3. How reliable are they in practice? 4. And how much do they cost compared to `top-of-the-line' C/C++ compilers? Without evidence of this sort the entire `language imperialism' debate becomes egregiously religious. Obviously, ``speed-of-generated-code'' or ``length-of-compile-time'' are not the only criteria by which to judge the success or failure of a language. However, since Ada supporters are beginning to make these claims I'd like to see some supporting evidence! thanks, Doug
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/16/89)
Painful as it was, I read your whole article, Ted. When you say (in article <14033@grebyn.com>, Ted Holden): > 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. how can you expect to be taken seriously? Do you really believe the math and premises behind your statement? Wow! Rich -- We use kill ratios to measure how the war is going. We use SLOC ratios to measure how our software is coming. (Idea from Gary Seath) rsd@sei.cmu.edu -----------------------------------------------------------------------------
schwartz@dinl.uucp (Michael Schwartz) (11/18/89)
OK. You win. I have to put in my 2 cents' worth. It's hard, because I
agree with many things that everybody has said.
Ada has been getting a bum rap. Ada was not designed by committee, it
was designed by competition. C, on the other hand, has been judged by
its applications.
Ada had no substantial applications to benchmark its design against.
The software engineering requirements imposed on Ada were for
programming in the large. Precisely what Ada has been shown to be good
at. Not surprisingly, Ada has not been found perfect for every
application area. Where it has failed, Ada-9X proposals have been
submitted to change it.
C was developed for systems programming. The worth of a compiler was
judged by the ability to build a good, modular, maintainable operating
system. Where C failed, the language was changed. And changed. And
changed.
It has surprised no one that C is more responsive to change requests
than Ada. Nor is it surprising that inexperienced software engineers
write better code in Ada than in C. It has not escaped anyone's
attention that there are more inexperienced software engineers than
experienced software engineers.
Sorry for belaboring the obvious, but let's start somewhere. Now let's
talk about Ada and Unix.
Areas where Ada and Unix have problems: a) System-dependent features
accessed from Ada b) Scheduler conflicts--Ada tasks vs Unix tasks c)
Ada image sizes and startup times
Of these areas, (c) is the most readily addressed. I have heard a
number of Ada 9X proposals amounting to a mechanism to freeze the Ada
image after elaboration, but before execution. So much for startup
times. I have also heard several vendors tout smarter link-editors
which will help resolve image size problems. I also hold hope for
shared library implementations; the Ada runtime can be shared among all
processes needing it.
Area (a) is one that requires Ada vendor support. It is difficult to
think of a non-trivial software system without some system-dependent
feature. After all, we buy different hardware precisely because of
these features. In my mind, a major difference between a good Ada
compiler and a marginal one can be found in the support for operating
system signals, pragma interfaces, and representation specifications.
It is no anathema to me to have an Ada system contain bodies which are
Pragma Interface (C,...) EVEN IF I DON'T HAVE TO. Maintenance costs
must be kept foremost. Reducing maintenance costs is, after all, one
of the major considerations in developing Ada. Let's not spoil this by
insisting that every Unix guru learn Ada.
Scheduler conflicts (b) remain a problem because Unix processes are not
the same as Ada tasks. Several have pointed out that Ada tasks are
'lightweight'; they mean that Ada tasks are represented by different
execution threads (instruction pointers and stack frames) but the same
data space. At least one Unix vendor has implemented a lightweight
process type in the Unix kernel. It is possible that a good solution
will be to build an Ada compiler which maps its tasks to lightweight
Unix processes, letting the Ada scheduler be either eliminated or
vastly reduced.
In the absence of this solution, a multi-tasking Ada program must build
a monitor to mediate all operating system calls which may 'use up' its
most vital resource -- the Unix operating system process. The
efficiency with which this may be done is directly related to both the
Ada compilation system's (ACS) ability to interface with Unix (see
(a)), and the 'goodness' of the Unix in question.
Since 'signals' are to Unix more or less what 'rendezvous' are to Ada,
the more events which can be propogated to the Ada monitor from Unix
via signals, the more efficient the implementation. Broad support for
SIGIO seems to particularly help.
With current compiler technology, one published result we have obtained
is multi-tasking access through sockets within 20% of the performance
of a C program using standard fork() and exec() calls. Both
applications were able to exchange over 5000 tcp/ip messages per
second with a cheap 68020 box. Turning off the time-sliced tasking in
the Ada program helped significantly.
One other result is that using our Ada abstraction, new employees were
able to contribute to our project within one to two days, even with no
prior Unix experience. Of course, a C abstraction is possible--but why
doesn't anyone use one?
A 'today' note: Dennis Ritchie spoke to the FRUUG (Front Range Unix
Users Group) last night about 9th Edition IPC. He has developed a
different IPC abstraction for his research. In syntax, it is similar
to our Ada (and C) abstractions. Of course, it has kernel support :-).
There. I feel better now ('thar she blows!)
Michael
-----------------------
schwartz@pogo.den.mmc.com "Expect everything ...
mschwartz@mmc.com and the unexpected never happens."
ncar!dinl!schwartz --the phantom tollbooth
DISCLAIMER: The opinions expressesed are not necessarily those of my
employer or myself.
--
-----------------------
schwartz@pogo.den.mmc.com "Expect everything ...
mschwartz@mmc.com and the unexpected never happens."
ncar!dinl!schwartz --the phantom tollbooth
DISCLAIMER: The opinions expressesed are not necessarily those of my
employer or myself.ted@grebyn.com (Ted Holden) (11/19/89)
Lots of good replies.... From: Richard S D'Ippolito, Software Engineering Institute, Pittsburgh, PA >> 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. >how can you expect to be taken seriously? Do you really believe the math >and premises behind your statement? Wow! The journal should be in your library or in that of Carnegie Mellon. I'm sure as hell not making any of this stuff up. Get serious. I'm quoting one of your own journals which was necessarily written in such a way as to paint Ada in as FAVORABLE a light as possible, and the most favorable thing the one gentleman could say was that he ONLY had major problems with 10% of his code. Pretty sad. From: Bill Wolf, Clemson >>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... Sounds very subjective to me and it sounds like a lot of factors are being left out. The funny thing is, that this subjective argument concerning productivity is the only technical or quasi-technical argument I have ever heard in favor of Ada. Every other argument in favor of Ada which I have ever heard was a variant of: "We will cut your ____ie off if you do not use Ada on your project..." That's not much to have to say to the world. >> 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. Proprietary OSs lock users into obsolescence; UNIX frees them. Until Dr. McKay publishes HIS portable OS and large numbers of people begin using it, UNIX will remain the only answer. > 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). I have personally watched the Telesoft Telegen Ada compiler take over 20 minutes to compile a 35 line program into a 300 KB executable on a 68020 based machine with almost nothing else happening on it. Knowing the Ada community's idea of progress, I'd expect the Telegen2 to take about 15 minutes to do the same job. Mach is five years away from anything approaching large scale use in America; right now, it is a student's hobbyshop project, albeit a hell of an interesting one. Mach-like or Mach-derived products such as the Sequent OS are beginning to be seen and, if your name is John Rockafeller, you should have no difficulty coming up with such a system to run Ada on. Ada does, in fact, run accepteably on a Sequent. Remember, however, the difficulties of building semetric parallellism into an imbedded system; that aileron controller won't be a Sequent. Remember also that the primary customer for Ada is supposed to be the U.S. military. Do you have any idea what the state of the art for computer hardware is in the U.S. military? We're talking about Unisys/Arrete 5000/80's, 5000/90's, 8186-based devices running Zenix on top of BTOS..... The 5000/95's are just now being installed. Get the idea? As for struggling with the "limitations" of UNIX, you'd better either get used to it or move to Mars. There is no other easily portable, mature operating system. Without it, you'll always be using ten-year-old hardware, because developing an OS the old way (like IBM and Microsoft seem intent on doing with BS/2) takes ten years. They paint themselves into some funny corners with it, like trying to tell the world that the N-10 chip is actually a graphics coprocessor for the 486. That's like having Theodore Roosavelt serve as Jimmy Carter's secretary of agriculture; it's driven by the obvious accessment of the chances of running BS/2 on an N-10, which is about like the chance of hell freezing over tommorrow morning. >> 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. > Fortunately, the economics of software development are in favor > of using considerably higher-level languages. Then perhaps you could explain the total dominance of C in the mini/micro world, the only completely healthy segment of the computer market? The last figures I've read indicated that 65 percent of all software development in this world was being done in C, and the next highest figure for any other language was around six percent. Are Borland, MicroSoft, Lotus, Ashton-Tate, WordPerfect, and all of those companies just that stupid? >> 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 Those features are there because they are necessary for real world programming. Tacking those features onto or into an Ada program (which is meant for real-world use) is not a superior solution; it makes for non-portable code. >> 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. Dead wrong. This is a grey area, but Ada tasking basically requires that the starting point be an Ada program i.e. predictable results/full Ada functionality are not possible from an Ada module called from a routine written in another language. The requirements to link low-level kinds of routines into Cobol programs are very real. Every Ada manual I've seen says that results from such code are unpredictable. >> 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"? There weren't any "cold" 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. First, the problem with performance didn't involve UNIX. Second, to my knowledge, the vender only offers the one version for the machine. Again, the customer was not John Rockafeller. >> [...] 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). > Apparently IBM has now changed its tune; its recent brochure > entitled "Ada and IBM... Capability and Committment" states: > IBM is committed to Ada. Ada's support for modern software > engineering concepts, its breadth of application, and its > support for reuseable software components place it squarely > in the forefront as a language of choice for both IBM's > software engineers and for IBM's customers. IBM was and is committed to PL/1, the PC-Jr, OS/2, MCA... Apparently, they have simply added Ada to their list of big-time losers with which (temporarily) there is a profit to be made. From: CAROZZONI: The Internet >>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 acceptably. > And the technical reason is ? Inferior design of the programming language. > Standardization among C compilers can best be shown by the Billions > and Billions of "ifndef"'s and "ifdef"'s in any C program such as > the Emacs Editor source code. You actually USE Emacs? Did it come bundled with Ada? Does the Internet have any kind of a rule regarding picking three losers, like the old New York three-time-loser law? How about Emacs, Ada, and Oracle? >>.....PC and lots of memory to play with, Ada compilers at least will get >>back to you on the same DAY; ................................... > I use Ada on a PC/AT (as do others here) and also use MS C 5.1! > We can't agree with you on this. Try reading the Ada compiler > installation manual. The best compile times I've ever heard of either on a VAX class machine or a 386 is around 1000/2000 lines/minute; Turbo C is around 15000 on a fast 286, Zortech C++ about the same, Turbo Pascal around 40000 on a fast 286; God knows what they run at on a 386. We're talking about at least a two-order-of-magnitude differential. >>......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. > Your facts are consistently confused. The availability of validated Ada > compilers covering a reasonable selection of machines have only > been around for 4-5 years. Ada started in 79; taking 6 years to write a validated compiler doesn't speak favorably of your efforts. World War II was fought in less time. >>.................... "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.................. > The UNIX standard? (BDS, System 5, Xenix, OSF, UI, Mach etc)? Pick one. >> Ada threatens to leave DoD stranded and technologically backwards; >>out of the mainstream of American computer science.............. > A recent article indicated that Ada and Ada like (Pascal, Modula 2) > languages are the primary choice for Software Engineering Curriculums. > May be you should enroll in one. Sorry, I live in the real world; I can't afford the brain damage that might do. .................... Am I missing something by citing 1988 and 1987 journals? Is it possible that in the year since the articles I have mentioned were printed that Ada has come of age? Consider the article concerning the Rational machine in this week's (Nov 13 89) issue of Government Computer News, page 47. It claims the price of the latest Rational Ada development machine has "come down" to around $100,000. It also claims that the machine will be used as a network resource in conjunction with Sun, DEC, and IBM file servers. The obvious implication is that these other machines, which are quite powerful, yet lack the capability for serious Ada development. Why is that? IBM, DEC, and Sun computers can easily be used to develope software in C, Fortran, Pascal, C++, Cobol... My own most recent machine is a Primus 386 which runs at 25 mh with no wait states, has 4 meg main memory and a 104 mh Conner disk which I paid around $2300 for. This system could easily be used to develope almost any kind of software with any reasonable language. What are you people getting for the other $97,700 with the Rational? Consider the possibility of an analogy from the world of medicine. In the medical world, the Rational might be referred to as a "heroic measure", possibly an iron lung. The patient (in this case, Ada), would be referred to either as "a terminally ill patient" or "the deceased". Aside from myself, who is saying that the end is near for Ada? Possibly, a certain Mr. Gorbachov in the CCCP, who is basically declaring the cold war to be over, and a Mr. Cheney in Washington D.C. who is talking about cutting 180 Billion from the U.S. defense budget over the next five years (Wash. Post, A1, Nov 18, 89). Anybody care to bet that Ada doesn't become one of the first casualties of all this? Ted Holden HTE
ted@grebyn.com (Ted Holden) (11/22/89)
From: mlewis: U. of Nebraska at Omaha >]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... >Yes, the time-frame of that project was such that (as clearly stated in >the article) there was ONLY ONE COMPILER AVAILABLE. On that compiler, >rendezvous took 15 msec, rather than the 1 msec required by the project, >which necessitated the use of VRTX to handle the high-speed task >scheduling. However, at the end of page 45, it says >"After acquiring an improved runtime performance compiler, the software >services package was implemented completely using Ada tasking and >rendezvous features." Okay, I missed that sentence. I have heard this same basic story several times from friends with no mention of happy endings and didn't expect one; nor is this truly a happy ending. A happy ending would read that they simply used ordinary, good, reliable tools and solved their clients problem, not that they spent ten units of time dealing with a language for each three solving problems and then had to rewrite a major piece of their package when industry finally managed a lame response to a non-sensical mandate. The question of whether the new system resolved any problems regarding Ada memory allocation or generics was left up in the air. >]... Needless to say, the Rube-Goldbergesque system they ended up with was >]considerably less maintainable than they might have gotten just using C. >If that is the case, then it needs saying. There was no mention of >maintainability in the article. Whence comes this conclusion? The >authors clearly liked Ada, and would not have done the job any other >way. Indeed, the biggest problem I read "between the lines" was that >their programmers were programming in some language (probably C or >Fortran) and coding the programs in Ada. The first item under the >heading "Lessons Learned" is: "Do not underestimate the importance of >*properly* learning the language." (emphasis mine). >But, let's see what else was NOT between the lines in this article: >"...Ada takes a long time to design and code. Once on the target >hardware, however, Ada requires significantly less effort to complete >integration and test." >"...the use of Ada resulted in a 12% increase in productivity over >assembly language and 27% over C." (That is the single most concise >condemnation of C I have ever seen... :-) Again subjective, again rubbish. I've heard too many people say that their projects simply could not be written in Ada at all, that the inherent clunk factor is just too great. Beyond that, you're leaving out a few things "on the lines": 1. "The host environment usually has better computing resources than the target. For example, the VAX is faster and uses 32-bit words while the 8186 is slow and uses 16-bit words. Thus, if care is not taken, this will lead to units which appear to operate correctly on the host when unit-tested but do not perform the same way on the target". So much for the Ada "standard'. 2. "Ada programmers need to understand how some of the most-used language constructs are compiled into target hardware instructions. An example is the number of arguments in a procedure call. The runtime performance of such a construct will be heavily influenced by the number of arguments vis-a-vis the number of registers the target processor has..." Why is it that C programmers don't have to walk around worrying about this kind of thing?? 3. "Table 1 shows a comparison of the percentage of the total effort for the development of three computer software configuration items: SCOTT Ada control processing CSCI, SCOTT assembley language digital signal processing SCSI, and another M/A-COM CSCI written in C..." This is obviously the same old approach to government affirmative action programs (here, for Ada); the Software Services CSCI was the token Ada module. Very obviously, for purposes of simplicity and/or portable code, any attempt to have the entire project in the same language could only have been achieved in C. >I have been lurking here for about a month, since I was offered a job >which requires that I learn Ada. The more I play with it, the more I >like it. I dislike C in all its thousands of dialects, but would like >to point out a very minor difficulty with Mr Holden's comparison between >C and Ada. C was (by Mr. Holden's argument, as well as historical >documentation: ie., he's right) designed to run efficiently ON A PDP >MACHINE. As was Unix. That these two systems run on other >architectures at all well is a tribute to 21 years of development by >thousands of HACKERS (in the proper sense of the term). Give Ada a few >more years to mature. Ada was not designed with a specific architecture >in mind at all, and so is inherently more portable than C. Your solution is technically superior and, yet, it runs two orders of magnitude slower than the old way? And you've only had since 1979 (the actual Ada spec) to get your act together? Why doesn't that sound right?? >But I am not here to bash C. I just wanted to point out that if you are >going to slam something, especially by comparison, you best have ALL >your ducks lined up nicely, or they might turn around and shoot back. Not in the case of Ada. Dead ducks don't bite (or shoot). >My only problem with Ada at this point is the cost ($ and hardware >resources) of a compiler for my XT clone. Both IntegrAda and Janus >require more memory than DOS 4.01 leaves available. This is BAD DESIGN. That seems to be the normal situation with Ada. Ever wonder why? >There is no excuse for a 551K executable in a PC (pass 2 of Integrada). >Janus Ada requires >580K available to run, and rumor has it that the >Integrada compiler is a repackaged Janus compiler. C users have no such problems. Ever wonder why? >Have a nice day. >Marc >-- >--------------------------------------------------------------------------- >Na khuya mne ehto gavno? | Internet: cs057@zeus.unl.edu Edinctvyeniy vid govna v etom mecte - Ada > preferred machine->| UUCP: uunet!btni!unocss!mlewis >--------------------------------------------------------------------------- Have a nice day, Ted Holden HTE
bagpiper@pnet02.gryphon.com (Michael Hunter) (11/22/89)
I have noticed many people including MANY lines of text that they do not comment on and that do not help context...can I please ask you to be nice to your neighbors and please cut out unneeded text!! ted@grebyn.com (Ted Holden) writes: >>"...the use of Ada resulted in a 12% increase in productivity over >>assembly language and 27% over C." (That is the single most concise >>condemnation of C I have ever seen... :-) > >Again subjective, again rubbish. I've heard too many people say that >their projects simply could not be written in Ada at all, that the >inherent clunk factor is just too great. If the numbers above are hard stats then they are not rubbish!! Since Ada is turing complete (as is every other modern HOL I can think of) I wouldn't trust anyone saying that their project "could not be written in Ada at all..." unless they were talking about some timing constraints that as we have all said is implementation dependent. >>There is no excuse for a 551K executable in a PC (pass 2 of Integrada). >>Janus Ada requires >580K available to run, and rumor has it that the >>Integrada compiler is a repackaged Janus compiler. > >C users have no such problems. Ever wonder why? wow man...he is talking about two (maybe 1) compiler on one computer running one OS...kindof small sample to be making those kind of comments. And making the commenbt that C users have no such problems is just basically wrong. Anybody who used pcc on a unix box with the reiser preprocessor with its horrible peep hole optimizer knows what I means!! Anyways the Ada environment must contain many things that the c environments very often don't. You should probably be comparing the size of your Ada system against a comparable C development system consisting of a compiler, lint, a safe malloc, and some tasking package. (and probably other pieces that I have forgotten!!) > >>Have a nice day. >>Marc >>-- >>--------------------------------------------------------------------------- >>Na khuya mne ehto gavno? | Internet: cs057@zeus.unl.edu >Edinctvyeniy vid govna v etom mecte - Ada >> preferred machine->| UUCP: uunet!btni!unocss!mlewis >>--------------------------------------------------------------------------- > >Have a nice day, > >Ted Holden >HTE > Ted, do you ever do any design work? If you ever happen to, you might learn a bit about the difference between DESIGN and a SPECIFIC IMPLEMENTATION of a certain design. Michael Mike Hunter - Box's and CPU's from HELL: iapx80[012]86, PR1ME 50 Series, 1750a UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!bagpiper INET: bagpiper@pnet02.gryphon.com
achille@cernvax.UUCP (achille petrilli) (11/22/89)
>From: mlewis: U. of Nebraska at Omaha > >>"...the use of Ada resulted in a 12% increase in productivity over >>assembly language and 27% over C." (That is the single most concise >>condemnation of C I have ever seen... :-) > Could somebody explain me those numbers ? How it comes that Ada is 12% more productive than assembly and 27% more than C ? This would mean that assembly is more productive than C ? This seems to me ridicolously wrong (assembly vs C productivity, I don't have facts to talk about Ada). Thanks, Achille Petrilli Cray & PWS Operations
rsd@sei.cmu.edu (Richard S D'Ippolito) (11/22/89)
In article <14036@grebyn.com> ted@grebyn.com (Ted Holden) writes: >From: Richard S D'Ippolito, Software Engineering Institute, Pittsburgh, PA > >>> 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. > >>how can you expect to be taken seriously? Do you really believe the math >>and premises behind your statement? Wow! You replied to me: >The journal should be in your library or in that of Carnegie Mellon. I'm >sure as hell not making any of this stuff up. Get serious. I'm quoting >one of your own journals which was necessarily written in such a way as >to paint Ada in as FAVORABLE a light as possible, and the most favorable >thing the one gentleman could say was that he ONLY had major problems >with 10% of his code. Pretty sad. (1) Your logic is faulty: The quoted statement does not contain the information that you can support your statement with, there being no-problem, minor-problem, major-problem and we-threw-the-requirement-out categories. You obviously need it to mean that 10% were met with major problems in order to blame it on the language, because you could have assumed that the 10% weren't met at all! (2) You made an incorrect assumption about software: It is unlikely that 10% of the requirements are met in 10% of the code lines. For example, can you identify the lines that are reliable, modular, and modifiable, to take three requirements. (3) You want us to think that the major problems were solely the fault of the chosen implementation language, without giving any evidence for it. I wasn't aware that the process of requirements specification had reached such a degree of perfection that all software requirements are correct, clear, consise, non-redundant, non-conflicting, operable, and implementable. Perhaps you could point me to the method. Now, to take your points separately: >The journal should be in your library or in that of Carnegie Mellon. Why _should_ it be? Do these libraries have obligations to carry it? >I'm sure as hell not making any of this stuff up. Beg pardon -- who accused you of that? >Get serious. Perhaps you mean to imply here that anybody who doesn't accept your premises and conclusions without evidence is just doing it to irritate you. >I'm quoting one of your own journals... Neither I nor the SEI publish, own, nor control any such trade journals. Surely you knew that, but let hyperbole get in the way of reason. >...which was necessarily written in such a way as to paint Ada in as >FAVORABLE a light as possible,... Why did they wait so long? C'mon, Ted, just express your opinions on articles without resorting to psychological diagnosis of the writers and editors. >...and the most favorable thing the one gentleman could say was that he ONLY had major problems with 10% of his code. If you are going to emphasize a word, at least place it properly before you make it stand out. Do mean "...he had ONLY major problems with...", or do you mean "...he had major problems with ONLY 10%..."? If the latter, see point (3) above. >Pretty sad. We agree totally here on the conclusion, but probabaly not on the antecedent. There is room for serious discussion on the design of Ada; please give your comments to the 9X committee. Please consider attending the next TRI-Ada conference and picking up a copy of the preceedings from the one just held here in Pittsburgh. Rich -- When you can measure what you are speaking about, and express it in numbers, you know something about it. Lord Kelvin rsd@sei.cmu.edu -----------------------------------------------------------------------------