C++/Java (was Re: [plug] Uni Course - UWA or Curtin?)

Greg Mildenhall assassin at live.wasp.net.au
Tue Nov 20 09:51:25 WST 2001


On Mon, 19 Nov 2001, Peter Wright wrote:
> On Mon, Nov 19, 2001 at 10:47:50AM +0800, Greg Mildenhall wrote:
> > I can't even begin to imagine what you see in C++ over Java.
> Well, there are a few obvious things someone might see in C++ over Java...
> (see below)

> > (unless what you really mean is that you prefer C to Java)
> I wouldn't understand _that_ at all. :)

Do you know a more convenient assembler?

> > I'd love to hear your opinions. (sorry to those not interested in the
> > topic, but differences and preferences between languages look like ending
> > up as a career for me.  :)
> You're thinking of becoming a programming language diplomat? :)

Yes, but without the diplomacy. :)
Language design, actually.

> Anyway -
> Well, the _most_ obvious "advantage" C++ might have over Java can be
> described in three letters: STL. The C++ Standard Template Library.
> Generic programming.

I seem to have sent my last message directly to Jonathon Bates, instead of
the list...rectifying that...OK. As you might glean from that, I view
generics in C++ as of limited utility at best, and a hamstringing mirage
at worst. It's still better than no generics at all, I guess, but why
would you ever want to use either of these languages if you are
programming generically? I simply cannot imagine a problem domain where
generic programmin would be an advantage, but you will still use C++.

Yes, this is a theoretical advantage over Java, but in practice, anyone
who needs this advantage is already shooting themselves in the foot.

> Having the option to use explicit memory management or a garbage collector
> of your choice (as opposed to not having an option) might be considered
> another advantage.

Completely automated garbage collection in C++ is simply not possible:
programmer discipline is still required. If you have any need to use
explicit memory management at all, I question why you are not using C?
When would you want OOP _language_features_ (as opposed to OOP design) as
well as explicit memory management?

> C++ being a significantly larger and more flexible language than Java
> _might_ be considered an advantage - though I believe some Java proponents
> might argue the opposite.

I'm hardly a Java proponent, but I certainly argue the opposite: mainly
because the many and varied features of C++ are not orthogonal enough to
all be used to their fullest at once. At any one time, you will find
yourself using a Java-like subset, or a C-like subset, or an ML-like
subset, but trying to mix and match styles is a recipe for disaster,
particularly when the development is a team process, or heavy
maintainence is required. It might sound good at first blush to be able to
use these different styles without having to learn multiple languages,
but you mind will not thank you for this, and the disjointed integration
of feature-sets largely prevents any speedup in the learning process.

> Then there are just a lot of miscellaneous things. A great deal more
> choice in (for example) GUI libraries, but certainly not only that.

More choice is a positive, but so is an always-there standard.

> Greater scope in programming style and syntactic sugar. I'd be mildly
> annoyed at not being able to do operator overloading, for example, if I
> started programming Java seriously again - though it's certainly not a huge
> thing by itself.

You use C++ operator overloading? There may be no help for you. :)
In an impure-OO language, I think it is a grave mistake to allow one
function to apply to both object and non-object entities. Semantically
different behaviours should not (in general) be invoked by identical
syntax - that way madness lies. Perhaps that is a matter of taste, but
there are enough horror stories even from experienced programmers.

> A language which has an ANSI standard as opposed to a standard controlled
> by one vendor. Again, perhaps that depends on how much you trust Sun,

I don't trust them at all. However, their standard is smaller, and that
counts for a great deal.

> PS. Have a look at http://www.paulgraham.com/lib/paulgraham/sec.txt if you
> haven't seen it before. A good article about language comparisons in
> general as well as a rabid Lisp advocacy piece. :)

Yes indeed. We functional types are especially rabid, but that is only
natural, considering we are Right. :)

-Greg



More information about the plug mailing list