From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.sys.sgi:10645 comp.graphics:18566 alt.graphics:163 comp.lang.ada:5652 comp.lang.c++:14031 Path: utzoo!utgpu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!netcomsv!jls From: jls@netcom.COM (Jim Showalter) Newsgroups: comp.sys.sgi,comp.graphics,alt.graphics,comp.lang.ada,comp.lang.c++ Subject: Re: c++ vs ada results Message-ID: <1991Jun12.201740.16463@netcom.COM> Date: 12 Jun 91 20:17:40 GMT References: <1991Jun12.164741.412@news.larc.nasa.gov> Organization: Netcom - Online Communication Services UNIX System {408 241-9760 guest} List-Id: >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++. *