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 HTE
schmidt@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