Re: c++ vs ada results

[jls@netcom.COM (Jim Showalter)]

>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++.    *