alan@hal.larc.nasa.gov (alan dare) (06/12/91)
Netlanders, A short time ago I put a request out for information on c++ vs Ada. I was hoping for several responses from people on both sides of the fence that were working on graphics applications. As my primary application is graphics. What did I receive? I received more requests to post the results than I received mail from people using c++ or Ada. I received only two messages from people using c++ in a graphics application and none from anyone using Ada. There were several messages from general users of c++ and only a few from Ada users. A kind soul FAX'ed me a document "A comparison of Experiences with the Maintenance of Object-Oriented Systems: Ada vs. C++". I didn't try to post a summary of the article (it's to big). The comments below were sent to me. I don't claim any responsibility for them. I don't currently use c++ or Ada. The comments are provided as a request from many people. Please don't use this posting to start a language war. The first post went to the following news groups: comp.sys.sgi comp.graphics alt.graphics comp.lang.ada comp.lang.c++ The comments below were edited only to reduce size, not content. ************************************************** *** Graphics ************************************* ************************************************** o I use C++ for graphics work. We considered ADA. Both have great pluses and a lot of minuses. Mostly the minuses are finding existing graphics packages which are compatible. They are rare with C++ and non-existent with ADA to my knowledge. o Ada has lots of features totally irrelevant to graphics which cost something in compile time even on a compiler that produces efficient code. It has no particular features to reccommend it for graphics particularly over any of the common block-structured languages. ************************************************** *** PRO ADA Comments ***************************** ************************************************** o The Ada MIL-SPEC and validation suites do a lot to insure a consistent interpretation of the language across platforms and vendors. No such validation or "frozen" specification exists for C++. This causes lost time and less portability. o Ada's Packages and Generic Packages are a lot easier to design for than C++ classes. o Ada has better support for embedded systems' work than C++. C++'s OO mechanisms (particurlarly dynamic binding) exact a performance penalty that will not be acceptable for some hard real-time systems. This will be less important in the future, as hardware gets faster and applications get more complicated (thus requiring the complexity-management mechanisms offered by languages like C++). Ada 9X will probably suffer similar performance penalties on the same kinds of mechanisms. ************************************************** *** CON ADA Comments ***************************** ************************************************** o The language is too big for the few benefits over C++ that it features. o Ada is a "weaker" language than C++ in expressing OO concepts (e.g. inheritance, polymorphism). Packages, Generic Packages and Ada's overloaded operators aren't enough. Ada 9X will supposedly deal with these issues, but it will be at least a decade before the Ada 9X environment is truly widely available at a reasonable cost. o ADA compilers tend to cost real money. o ADA suffers from having way too many features -- probably an artifact of the design-by-committee process. It's such a huge language that a programmer may never fully "learn" it. o Converting code to ADA from anything is a problem. o ADA still tends to be slow, though that problem is slowly going away. o Ada is only object-based (it has no inheritance), while C++ _is_ object-oriented. ************************************************** *** PRO C++ Comments ***************************** ************************************************** o The dynamic binding, polymorphism and inheritance mechanisms are *extremely* powerful, and very useful in graphical applications. Future enhancements including parameterized types (== Ada "Generic Packages") and exceptions (== Ada exceptions) are going to be equally powerful. o After extensive reading and personal evaluation, I came to the conclusion the ADA implementions are far worse than the C implementations (I use the stuff from GNU, don't see how anyone can write better software). o C++ compilers are cheap -- the GNU family is free, and runs on a number of different architectures. You can get the source code so that you can fix it if it's broken. o C++ seems to be a reasonably clean design; the features tend to be orthogonal and complete. A competent programmer can probably "learn" C++ pretty well in a month. o Converting code from C to C++ isn't a big problem. (And with some of the Fortran-to-C translators that are publicly available, the Fortran->C->C++ path, while a bit of a pain, isn't completely daunting.) o C++ runs just about as fast as C, i.e. it's plenty fast enough to write things like volume renderers. ************************************************** *** CON C++ Comments ***************************** ************************************************** o The tools for working with it maybe not as mature as ada tools. o C++ is hard to master. o C++ has reasonable OO mechanisms, but they are difficult to learn, and more difficult to use effectively. This is partially due to the low quality of the documentation, which is quickly changing. ************************************************** *** GENERAL Comments ***************************** ************************************************** o There are a lot more Ada people out there, at the moment, than C++ people. There will probably be a lot more C++ people in the future than Ada people, simply because the language is more accessable to more people (Gnu C++ is free, for example; "Turbo C++" costs ~$60; AT&T is very generous in licensing to Universities). o There will probably be a lot more C++ compilers available on a lot more platforms than Ada compilers in the future (the costs of validation are high; reuse of AT&T code or GNU code is cheap). I would like to thank the following for responding to my post : baker@csl.dl.nec.com blbates@aero36.larc.nasa brendan@illyria.wpd.sgi.com fmhv@inesc.inesc.pt jansm@cih.hcuge.ch jdt@voodoo.boeing.com jls@netcom.com jshumate@logdis1.wr.aflc.af.mil leisner.henr801c@xerox.com richard@elroy.Jpl.Nasa.Gov rsk@gynko.circ.upenn.edu uselton@nas.nasa.gov -- ********************************************************************* Alan Dare | Internet : alan@hal.larc.nasa.gov NASA Langley Research Center |
pmartz@undies.dsd.es.com (Paul Martz) (06/13/91)
In article <1991Jun12.164741.412@news.larc.nasa.gov>, alan@hal.larc.nasa.gov (alan dare) writes: > > > Netlanders, > > A short time ago I put a request out for information on c++ vs > Ada. [...] The comments > below were sent to me. I don't claim any responsibility for them. I don't > currently use c++ or Ada. The comments are provided as a request from many > people. Please don't use this posting to start a language war. > > [...] > > o I use C++ for graphics work. We considered ADA. > Both have great pluses and a lot of minuses. > Mostly the minuses are finding existing graphics packages > which are compatible. They are rare with C++ and non-existent > with ADA to my knowledge. Just for the record, Evans & Sutherland sells an Ada binding to PHIGS for use with our ESV graphics workstation. > [...] > > ********************************************************************* > Alan Dare | Internet : alan@hal.larc.nasa.gov > NASA Langley Research Center | -- -paul pmartz@dsd.es.com Evans & Sutherland
jls@netcom.COM (Jim Showalter) (06/13/91)
>o I use C++ for graphics work. We considered ADA. > Both have great pluses and a lot of minuses. > Mostly the minuses are finding existing graphics packages > which are compatible. They are rare with C++ and non-existent > with ADA to my knowledge. Ada bindings to X windows (including a nearly pure-Ada version donated by Rational to MIT) are available. There is at least one firm I know of that does nothing EXCEPT write X windows graphics applications in Ada. Incidentally, Ada is a name, not an acronym. So, like Pascal, it is capitalized, not uppercased like FORTRAN. >o Ada has lots of features totally irrelevant to graphics > which cost something in compile time even on a compiler that > produces efficient code. Any language has features totally irrelevant to graphics, unless that language is specifically a graphics language (which C++ is not). It is unclear to me how an Ada feature that is not used can "cost something in compile time"--could someone elaborate? >o The language is too big for the few benefits over C++ that > it features. What does "too big" mean, actually? I hear this bandied about all the time, but when I press someone to precisely explain what features of Ada they think are superfluous, they stammer about um, well, tasking or some such--and yet, if you ask someone who USES tasking, they regard it as indispensable. I am reminded of the line in "Amadeus" when the king tells Mozart that his work has "too many notes", to which Mozart replies "Well, sire, which notes exactly would you have me remove?". Really, factually, Ada has approximately the same number of keywords, control structures, and fundamental concepts as C++ or any other software engineering oriented language. Certainly it is bigger than C, but so is C++--that's the whole POINT. >o ADA compilers tend to cost real money. Indeed. And they tend to provide real functionality: they work, have few bugs, have excellent support backing them up, are validated, and scale to projects of significant size and complexity. You get what you pay for. >o ADA suffers from having way too many features -- probably > an artifact of the design-by-committee process. It's such a > huge language that a programmer may never fully "learn" it. Again--which notes would you have me remove, sire? As for the design by committee accusation, two points: 1) it wasn't a committee, really--it was actually a handful of clever people led by a particularly clever Frenchman named Ichbiah; the language was subject to extensive international review, but that doesn't constitute a committee, 2) a Lexus is a car designed by a committee; it is also one of the finest cars ever designed: perhaps the issue is not the existence of a committee but, rather, the QUALITY of the committee that should be taken into account. As for learning the entire language--why should one HAVE to? If you don't need concurrency control, then by all means ignore tasking. If you don't need fixed point types, then by all means ignore them. It is really quite simple to learn a very powerful and flexible subset of the language. >o Converting code to ADA from anything is a problem. Huh? >o ADA still tends to be slow, though that problem is slowly > going away. As with the "too many features" shibboleth, this common myth doesn't hold up under even rudimentary analysis of the facts. There are compilers available for a number of targets that produce code at least as dense and efficient as C/C++ compilers for the same target. >o C++ compilers are cheap -- the GNU family is free, and runs > on a number of different architectures. You can get the source > code so that you can fix it if it's broken. You get what you pay for. Personally, I'd much prefer to buy a validated compiler with the number of bugs approaching zero than use a free compiler so shot full of bugs the source code is provided to me to patch around problems that SHOULD have been taken care of by the vendor. >o C++ seems to be a reasonably clean design; the features tend to > be orthogonal and complete. A competent programmer can probably > "learn" C++ pretty well in a month. Funny, about every 9th posting to comp.object concerns one or another person's complaints about C++ being a kludgy, idiosyncratic, hard-to-learn language. And, in my experience, it takes more like 6 months to a year for a programmer to REALLY learn how to write well in C++ (yes, one can hack together executing code fairly quickly, but to get from there to where one can design competently in the language requires a lot of practice). >o Converting code from C to C++ isn't a big problem. (And with > some of the Fortran-to-C translators that are publicly available, > the Fortran->C->C++ path, while a bit of a pain, isn't > completely daunting.) The C++ code that results from a double translation effort as described is ugly in the fullest sense of the word. You don't gain much by translating legacy code written in an archaic language into a different language--the REAL win is in translating to a new DESIGN and then coding that new design in a more modern language. This requires human effort and ingenuity, and is NOT something that can be automated (at least not with current state of the art), but the eventual payoff is considerable. Automated translation of a bad design written in a bad language into a bad design written in a better language is a perfect example of the GIGO principle in action. Show me a translator that will convert legacy FORTRAN into a well-abstracted class hierarchy in C++ and I'll start to be impressed. Until then, spare me. >o The tools for working with it maybe not as mature as ada tools. Indeed. >o C++ is hard to master. Indeed. Note that this contradicts the claim made earlier that C++ is easy to learn. >o C++ has reasonable OO mechanisms, but they > are difficult to learn, and more difficult to use > effectively. This is partially due to the low > quality of the documentation, which is quickly > changing. It is even more due to the fact that such mechanisms, despite their billing, are actually quite tricky to master conceptually. The number of people I've encountered who'd I trust to actually design a class hierarchy of any significant complexity I can count on one hand. Sadly, hacker culture being what it is, EVERYBODY is going to want to do try their hand at building such things, and most are going to fail miserably. Not everybody is an architect, so why pretend that they are? -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
pierson@encore.com (Dan L. Pierson) (06/13/91)
Regarding c++ vs ada results; alan@hal.larc.nasa.gov (alan dare) adds: (quoting someone else; don't blame him :-)) > o Ada has better support for embedded systems' > work than C++. C++'s OO mechanisms > (particurlarly dynamic binding) exact a performance > penalty that will not be acceptable for some > hard real-time systems. This assertion contains a common misconception about dynamic binding _for languages which support both dynamic and static binding_. Such languages include C++, Common Lisp/CLOS and the current proposal for Ada 9X. The misconception is that the performance of a dynamically dispatched (bound) function call should be compared to that of a normal function call. It should not; it should be compared to the performance of a normal function call PLUS a case statement. If you don't need the case statement you should have used a statically bound call*. A good implementation of dynamic dispatch for any of these languages can be faster than static call plus case. There are several existence proofs for C++ and Common Lisp/CLOS, but I don't have the citations handy. *Of course, a poor programmer can overuse dynamic binding with greater ease than explicit case statements. IMHO, all of the cited languages have enough such options already available that this isn't a big issue when weighed against the advantages in software construction and reuse provided by dynamic binding. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com
paul@u02.svl.cdc.com (Paul Kohlmiller) (06/14/91)
jls@netcom.COM (Jim Showalter) writes: >As with the "too many features" shibboleth, this common myth doesn't >hold up under even rudimentary analysis of the facts. There are >compilers available for a number of targets that produce code at >least as dense and efficient as C/C++ compilers for the same target. Jim, Could you specify one or more machines that have an available ADA compiler that generates code that is as efficient as a C compiler for the same machine? thnx Paul Kohlmiller CDC standard disclaimers -- // Paul H. Kohlmiller // "Cybers, Macs and Mips" // // Control Data Corporation // Internet: paul@robin.svl.cdc.com // // All comments are strictly // America Online: Paul CDC // // my own. // Compuserve: 71170,2064 //
nelson@sun.soe.clarkson.edu (Russ Nelson) (06/16/91)
In article <1991Jun12.201740.16463@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >o ADA still tends to be slow, though that problem is slowly > going away. As with the "too many features" shibboleth, this common myth doesn't hold up under even rudimentary analysis of the facts. There are compilers available for a number of targets that produce code at least as dense and efficient as C/C++ compilers for the same target. >o C++ compilers are cheap -- the GNU family is free, and runs > on a number of different architectures. You can get the source > code so that you can fix it if it's broken. You get what you pay for. Personally, I'd much prefer to buy a validated compiler with the number of bugs approaching zero than use a free compiler so shot full of bugs the source code is provided to me to patch around problems that SHOULD have been taken care of by the vendor. Why is "ada is slow" a myth, but "GCC is shot full of bugs" is not? Certainly if you're an expert on GCC's bugs, you could name one of them. It's been my experience that the vendors of compilers *never* share their bug list with customers. For GCC, you just have to tune into gnu.gcc.bug. -- --russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker. I am leaving the employ of Clarkson as of June 30. Hopefully this email address will remain. If it doesn't, use nelson@gnu.ai.mit.edu.
sef@kithrup.COM (Sean Eric Fagan) (06/16/91)
In article <1991Jun12.201740.16463@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >Indeed. And they tend to provide real functionality: they work, >have few bugs, have excellent support backing them up, are validated, >and scale to projects of significant size and complexity. You get >what you pay for. And >You get what you pay for. Personally, I'd much prefer to buy a validated >compiler with the number of bugs approaching zero than use a free compiler >so shot full of bugs the source code is provided to me to patch around >problems that SHOULD have been taken care of by the vendor. 1. gcc (and g++) are among the best and least buggy compilers (especially considering their ages) that I've ever seen. 2. Real world experience: a certain software company, affiliated with my previous employer through various means, has a C compiler. We got their C compiler and resold it for our system. The compiler had more bugs than I can count on both hands (in binary, that is 8-)); when I found a bug, and asked "did you fix this?" I would almost always get a response of, "maybe, but we're working with this later version [which wasn't released until two years later, mind you] so we can't help you." My ex-housemate, working for yet another company (as a customer of said software company) eventually gave up on their software support and sent me dozens of email messages asking a) is this a real bug, and, if so, b) how can I work around it? 3. I have encountered far fewer bugs in gdb than, say, sdb. Yet sdb is a "validated debugger," for which one pays lots of money. Yep. Useful things, those proprietary development tools. >>o C++ is hard to master. >Indeed. Note that this contradicts the claim made earlier that C++ is >easy to learn. You are truly showing your foolishness here. Most people out of grade school realize there is a difference between "learning" something and "mastering" it. I guess you're just special, aren't you? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.