bob@imspw6.UUCP (Bob Burch) (11/20/88)
From: Ted Holden, HTE A priori Disclaimer: The following opinions are entirely my own and in no manner represent policy of IMS or of my old buddy Bob Burch who generously allows me to post articles here on occasion. .......................................................... From: Jan Steinman: Tektronix Inc. >Last I changed jobs, I had been doing object-oriented design in Ada, and >switched to Smalltalk. About the same time, we got two kittens, so we named >them Ada and Smalltalk. >Now my spouse and I are both beginning to get involved with C++, and have >gotten another kitten. We named her CoreDump. >> Object Oriented DESIGN is one thing; want to know how I can tell this >>writer has never actually DONE anything serious with Ada? Simple... you'd >>die of old age WAITING for anything serious to get as far as a core dump in >>Ada. ....... >(Please, make personal attacks by email, so that defenses don't have to be made >in public!) Ted claims that: ><...you'd die of old age WAITING for... a core dump in Ada...> >and I agree, unless you turn run-time checking off -- it's a FEATURE, not a >bug! (Wouldn't you rather die of old age before seeing another core dump?) It >seems obvious that he has not used a language that employs any more run-time >checking than C++. Unless I'm missing something, you still have to >specifically implement run-time checking in C++, although if a real, common >environment existed, it might have something like a BoundedArray class in it. >(Of course, Real Programmers never allow bad indices to reach their arrays. >They never take input from the Real World, either. :-) No personal attacks intended; I simply stated an honest opinion. To me, at least, it is inconceivable that anyone who has done much serious programming could prefer Ada to C or C++. I see Ada as a first magnitude disaster looming in the near future. Reality as I understand it also indicates, to me at least, that the choice an awful lot of people are going to have to be making soon will be between Ada and C++, and not between C++, Objective C, Small-Talk, Modula 4.77 etc. etc. as much of the discussion on this group might indicate. Therefore, it seems logical to take a hard look at Ada, and whether any of us could live with it. Mr. Steinman, having "designed" in Ada seems to think he could. I have watched a 30 line Ada program take 27 minutes to compile on a multi-processor 68020 device with nothing else happening on it. I am seeing evidence of major-league projects on the verge of failure for no other reason than the Ada mandate. I am aware of at least one major project whose managers simply refused to deal with Ada, successfully convincing top brass that there would be a two year differential in the time needed to complete the project with versus without Ada. I am aware that Air Force personnel whose bitter misfortune it is to have to deal with Ada refer to it as the "Tar Baby", claiming it tangles lives, projects, and careeers even as the tar baby tangled the rabbit in Joel Chandler Harris' old fairy tale. I have watched people busily removing every instance of the word "PACKAGE" from specification documents because, in the realm of DOD, "PACKAGE" implies "ADA". I mean, this is the kind of terror which only Count Dracula, Jaws, and Jenghis Khan are supposed to inspire. Preventing bad indices from reaching arrays and taking real-world input don't begin to account for the kinds of grief I'm talking about; the problem lies more in the fundamental design of the language (Ada). I have always had the impression that in computer science generally and in government computer science more particularly, there has been about an 80 - 20 mix of people who design things on paper and people who make anything breathe and live on real machines. C began with real machines, real computer users. The idea seems to have been: "Lets take a hard look at this little PDP7 and design a language which is one-to-one with its logical operation 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 OS in that language so that, when we get our PDP7.5, or the next year's computer, whatever it may be, we're REALLY back rolling two weeks later. I thus believe C was a product of the 20%. 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 1.5/2.0 and the Zortech C++ compiler, and I assume the same will hold true when you start seeing good native-mode compilers for UNIX. Ada clearly is a product of the 80%. 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, at least initially, as unimportant. I see all kinds of useless features in Ada, such as assigning array members values in random order, and I have to figure that checking all such contingencies accounts for a lot of the irrational ammounts of time spent on compiling. The fact that, with most if not all Ada compilers, "hello world" seems to take up irrational amounts of space, often as much as 300K bytes, adds to this suspicion. "Hello world" take 2K bytes with Turbo Pascal 4.0. Ada 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. 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 problem with compile/link speed, especially, tends to take modern programmers out of the rapid prototyping mode which they get used to using Borland products with 5 second compiles, and throw them back into the computer world of 1973, in which they might have gotten three shots a day at compiling a program batch mode. Real world programs get written in finite amounts of time, with finite quantities of psychic energy. Within these limits, there is a huge difference in the quality of programs which get written today and those that got written in 1973. Since Ada believes itself to be an OS, 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, incidentally, 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 use of Ada is further complicated by two 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 three pages 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". Ada threatens to leave DoD stranded and technologically backwards. 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 better off 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 AssHola Khomeini, 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. That would be an awfully sorry reason to have American machine guns and rockets (presumably programmed in Ada) working 10 - 100 times slower than the other guy's. I mean, if I'm the guy up there getting into machine gun and rocket fights at 1600 mph, I'd want to have EVERY edge I could have, no matter how small. Don't get me wrong. I'm not REALLY paranoid and I don't REALLY hate Ada; actually, I figure to make a great deal of money with it. If the DOD affirmative-action program for Ada stays in effect for two more years, I figure to make a great deal of money cleaning up the mess and teaching people C language (and possibly C++). If the program stays in effect for 5 years, I'll make even more money teaching those same people Russian, which they'll need at that time. You'd better believe, the Russians program in C. If I had a kitten I wished to name after an Ada project, I'd name him either Methusaleh or Rip Van Winkle. The thing I like best about C++ is the feature nobody says much about: that it has all of the potential to serve as an intelligent replacement for Ada; it can actually do all of the things Ada is supposed to be able to do and never will do. And if even part of the giant sums of money now being thrown in the direction of Ada could possibly be diverted in the direction of C++ projects...... Who knows what might could be done. Ted Holden HTE
tom@hprmokg.HP.COM (Thomas Vachuska) (11/22/88)
Ted, you talk (write) too much and you say too little. What is worse, you say that you do not know what you are talking about. You obviously do not know much about Ada, for you would not write such non-sense about Ada trying to be an OS or a 30 line Ada program taking 27 minutes to compile. Perhaps 27 seconds would be more appropriate and even then the program would probably have to contain at least one generic unit that consists of several hundred lines of code. Or then again there is an alternative that you were using a crummy Ada compiler, if you ever used one at all. I'm not putting C++ down at all, but for medium-large to large projects I would definitely prefer Ada. Thomas Vachuska P.S.: Why don't you read the Steelman, and then talk. And also remember that compiler technology did not stop getting better.
sommar@enea.se (Erland Sommarskog) (11/22/88)
This has of course nothing to do with C++. I guess I ought to cross-post to comp.lang.ada and direct follow-ups there, but I thought I should save the readers of that group. As for you C++ fans I care less about you, since I don't read this group myself. Ted Holden borrows Bob Burch's account (bob@imspw6.UUCP) and writes: >I have watched a 30 line Ada program take 27 minutes to compile on a >multi-processor 68020 device with nothing else happening on it. And I have seen an Ada compiler compile in just as the same time as any compiler at that machine. I *have* seen compilers behaving something like the one Ted describes, but that was five years ago. Things have changed. A lot. True it takes longer time to get a program through the compiler. To some extent this could be blamed on language complexity, but mostly to the fact that the compiler finds more of your errors. >I have always had the impression that in computer science generally and >in government computer science more particularly, there has been about >an 80 - 20 mix of people who design things on paper and people who make >anything breathe and live on real machines. C began with real machines, >real computer users. The idea seems to have been: I haven't dealt with C, but I have dealt with langauges where simple implementation was considedered more important than a complete langauge. The look powerfull to begin with, until you stumble on all the cases which were not important to the implementors but to me. It's a question to look around the corner. It's good to have the language now, but it's not good to be stuck with all the limitations forever. >Ada 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. I ran a very simple test on our machine here. (VAX 780, 4.3 BSD) A word- counting program in Ada (Verdix 5.41) took 2-3 times longer time than old "wc". On the other hand, the Pascal program was 5 times slower than Ada and the Fortran 3 one times. And don't jump to conclusion about the Ada-C relationship. Verdix uses far from all possibilities the VAX architecture offers (their compiler is a multi-target one). Looking at the code I'm surprised that the programs run as fast as they do. >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. My experience Ada wasn't designed to run real-time applications on a time-sharing system, one should have this is mind. Its real-time primitives were intended for embedded systems. Probably, with today's computers you have to resort to the target systems own process handling if you want to write a fast multi-tasking application in Ada for a system like Unix or VMS. Not really satisfactory. but what other options does other langauges offer you? >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. So what says that you must use such names in Ada? If you love long names you can have them in C too. I prefer readable names rather than obscure abbreviations, but I don't fall into exagerations. >Ada threatens to leave DoD stranded and technologically >backwards. The better class of programmers coming out of the >schools will be used to the 2 second compiles of Turbo C and >Turbo Pascal. If they prefer to find the errors themselves and wasting a lot of time of testing, instead of having the machine finding them. Personally I prefer if I can trust as much as possible on the computer. I have enough of things to think of anyway. >If the program stays in effect for 5 years, >I'll make even more money teaching those same people Russian, which >they'll need at that time. You'd better believe, the Russians program in >C. If they do, I would stay calm. They will get a core dump before they can do any harm. To conlude: your Ada flames are based on a total misconception. Apparently you haven't been working with any serious Ada compiler. Come back when you have. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.se "Frequently, unexpected errors are entirely unpredictable" - Digital Equipment