pattis@june.cs.washington.edu (Richard Pattis) (11/20/88)
A longish message posted on comp.lang.c++ recently, that I thought would be of interest to this group. From bob@imspw6.UUCP Sat Nov 19 14:50:23 1988 Path: uw-june!uw-beaver!cornell!batcomputer!itsgw!steinmetz!uunet!imspw6!bob From: bob@imspw6.UUCP (Bob Burch) Newsgroups: comp.lang.c++ Subject: Re: C++ vs Ada / how to name kittens Message-ID: <195@imspw6.UUCP> Date: 19 Nov 88 22:50:23 GMT Organization: IMS Inc., Rockville, MD Lines: 212 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
peirce@claris.com (Michael Peirce) (11/22/88)
RE: Flame on Ada by Bob Burch I'm not sure such a flame deserves a reply, but (against my better judgement...) I'll give a short one anyway. This guy seems to have a boat load of preconceived Ada biases. I doubt he has ever used a decent Ada environment. Now maybe he has used AN Ada environment, but judging a language by one or two bad implementations is a bit premature. I worked on a medium size project (~35 engineers) doing factory automation work. We switched to Ada in mid-project to improve the quality of our system and to provide ourselves with a first rate SOFTWARE ENGINEERING environment. Ada made a big difference in this project by providing a excellent environment for well thoughtout design (NOT HACKING - Ada is a horrible hacking language) and development coordination. The environment was DEC's VAX/VMS Ada. Compile times were reasonable (a tad slower than Pascal, but it was doing work each compile) and the quality of the code produced was as good or better than some of DEC's other compilers. Keep in mind this was a non-DOD related project (no one force Ada down our throats) and we actually thought Ada had a very positive impact on the project. Ada has it place (espcially in larger, complicated project that demand a well thought out (DESIGNED) solution. I'm sure C++ will have it's place, but so does Ada. -- michael .
leake@cme-durer.ARPA (Stephe Leake) (11/22/88)
I can only say I totally disagree. I have been using DEC Ada under VMS, with (a customized) LSE as the user interface, to program a very large system (over 200 files). The amount of cross-checking the compiler does is absolutely essential; there is _no_ _way_ I could handle a project this size in C, without a good tool to do the cross checking (even on a Unix machine, I've never seen a lint that was as good as Ada). And no, the compile time is not slower than C, since I do far fewer compiles, and each file can be very small. This is what packages are for: to isolate code so it can be compiled quickly. And no, the compiled code is not slow; it is as good as DEC C when I use double float, and faster normally, since I can use single float. This is obviously a matter of personal experience, with a heavy helping of wishful thinking (on both sides). At WADAS 88, there were some serious studies by companies with a lot of money at stake, and they concluded Ada was worth it. One more point: Ted Holden made a virtue of the fact that C was matched to the PDP; does this mean that we need a new one for each machine? More importantly, Ada lets me think about the problem at hand, not the computer I happen to be using to help solve the problem. Stephe Leake (301) 975-3431 leake@cme.nbs.gov National Institute of Standards and Technology (formerly National Bureau of Standards) Rm. B-124, Bldg. 220 Gaithersburg, MD 20899
adolph@ssc-vax.UUCP (Mark C. Adolph) (11/23/88)
In article <6474@june.cs.washington.edu>, pattis@june.cs.washington.edu (Richard Pattis) writes: > From: Ted Holden, HTE > <Considerable flamage omitted> > > If the (Ada) 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. I didn't know that Morton Downey Jr. worked with computers... This whole flame reminds me of a guy I work with who constantly compares the world to FORTRAN and finds it wanting. -- -- Mark A. ...uw-beaver!ssc-vax!adolph
hblask@elric.Sp.Unisys.COM (Henry E. Blaskowski) (11/23/88)
> From: Ted Holden, HTE > > >>you'd > >>die of old age WAITING for anything serious to get as far as 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?) > To me, at least, it is inconceivable that anyone who has done much > serious programming could prefer Ada to C or C++. The last two projects I have been on have been very similar -- tactical displays for military applications. The major difference was the first was in C, the second in Ada. Therefore I feel qualified to respond to the claims of Ted Holden. Do I prefer Ada to C? It depends on what I am trying to do. > I have watched a 30 line Ada program take 27 minutes to compile on a > 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 Yes, Ada takes longer to compile. Of course compile time checking takes some amount of time. But how long do you spend tracking down type errors in your C programs? Usually more than the incremental compile time. Well, ok, you PERSONALLY don't make such errors, but what about the yo-yo next to you...? And yes, some managers are afraid to try Ada, but some are afraid to leave FORTRAN.. I bet some would use Basic if they could find the people to program in it. That says nothing about the language. > The idea [behind C] 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 > ... so that we end up with a kind of high- > structured, low-level language, a thinking-man's assembler. > > 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, > ...with any considerations > of real-world computers being regarded, at least initially, as unimportant. Oh, I see, you mean real world *UNIX* computers. Sorry, but the bare chips which many of us work with don't have Unix operating systems. But this does bring up an interesting point. Unix is like assembly, only easier. How big of a project would you like to write in an assembly-like language? > 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. But this doesn't increase linearly with the size of the program, like in C. The overhead is the same for small and large programs, so there is a break even point. How many weapons systems are less than 10 lines. And there is no reason the executable has to be much bigger than for a C program, which is what real systems care about. > ...using C language, he might have written Cobol-callable > routines incrementally. There is > no real way to call an operating system from a Cobol program. Ada can't help COBOL's problems. If the COBOL program had been written properly, there is no reason that using Ada, COBOL-callable routines can't be written incrementally. I've called C from Ada and vice versa. It's no big deal. > First, the programming style being promulgated by DoD for > Ada is anti-conducive to the stated goal of readability; > The verbiage hides the logic. When every > variable name looks like: > > "NUMBER_OF_CROWS_SALLY_ANNS_GRANDMOTHER_SHOT_WITH_HER_12_GAUGE_- > LAST_TUESDAY", First of all, Ada can have short names, but part of the goal is readability. Having worked with both, and using both styles, I MUCH prefer being able to read a statement and know what it means, especially when reading someone else's code, as frequently happens in the Real World. > Second, DoD is often insisting on portability via Ada rather > than portability via UNIX, POSIX calls etc. Again, not everyone has Unix on their newly invented chips, and probably don't have the time to write their own version for their specific hardware. > 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 I disagree. A lot of people are learning Ada in school, and will actually like it. Some people like C, some like Assembly, some like Ada. Isn't America great? > I figure to make a great deal of money teaching people > C language (and possibly C++). C is intuitively obvious, you don't need to TEACH it. :-) > You'd better believe, the Russians program in C. Hmmmmm.. > 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 Well, maybe if it got standardized, and easier to debug. The theory behind Ada is to do all the hard work up front, letting the compiler do the work. This is not without a price -- longer compile times, greater use of resources, etc. The real question is whether all the hassle is worth it. Having seen both sides, I have to say that for large projects with many programmers, the answer is yes. An individual programmer, who doesn't make mistakes, and promises to stay around and debug for the life of the project should use C. A person (or team) writing a small program ( <5000 lines, should use C. A person writing for a Unix based machine should use C. Defense related projects usually don't fit the C categories. Each language has it's place, and I don't think one will replace the other any time soon. h blaskowski I speak for myself, not my company.