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

[Peter Wright]

On Tue, Nov 20, 2001 at 09:51:25AM +0800, Greg Mildenhall wrote:
> 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?

*pause for humour-but-not-really to settle in* I must admit, no. :/

> > You're thinking of becoming a programming language diplomat? :)
> 
> Yes, but without the diplomacy. :)
> Language design, actually.

Ohhhhhhhhhhhhhhhhhhhhhhhhhhh.

Can I be afraid now? :)

> > 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

A _hamstringing_ mirage? That's an interesting metaphor merge.

> at worst.

"Because Blob doesn't have generics, and I don't use generics, so I can't
really see what good they might be."

Actually, your Blob may have generics (I don't know what your preferred
language (if you have one) is, though I assume it's a Lisp or Haskell or ML
variant) but I gather you don't use generic programming much?

Fair enough. I also don't do generic programming "much", for some unclear
value of "much". I use the STL in my professional work, though nowhere near
as much as I'd like to, but I certainly admit that I don't _need_ to use
it. I write neater and more compact and hopefully more readable and
certainly more reliable code with it, but I _could_ do without it :).

I'm actually trying to pressure my C++-ing colleagues at the moment to make
an effort to improve their understanding of generic programming (and the
STL in particular). Our use of STL at the moment is, to put it mildly,
extremely limited, and it shows with all the (incomplete and poor)
concrete re-implementations of generic functionality already available in
the STL.

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

I'm not clear on what you mean by this last sentence... do you mean you
can't imagine _any_ problem domain where generic programming would be an
advantage? Or do you mean you can't imagine where generic programming would
be an advantage and C++ wouldn't be a disadvantage?

I'm not quite sure whether you're taking shots at generic programming or
C++ (or both) here :).

However - I would remind you that generic programming is one thing and the
STL is another. The STL _uses_ C++-style generic programming to do what it
does, but it provides a hell of a lot of frequently useful (and sometimes
very powerful), logically structured functionality. I haven't seen or heard
of an STL-like "library" implemented in any other language (that is capable
of generic programming), though I'd be happy to be corrected on this point.

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

I'd recommend at least some sort of evidence for a bald assertion like
that. The larger the project (and the more developers involved), the more
you need to keep the size of the code base under control - and it becomes
more and more important to make sure (as much as possible) that the same
wheels not get reinvented and reimplemented when they don't have to be. And
without generic programming, you end up in that situation.

Of course, even in a one-person project, while generics may be less
obviously necessary, they're still useful and keep code size down.

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

I don't have enough knowledge about this specifically to question your
assertion directly - I was just going by the information on Bjarne's FAQ
where he says "If you want automatic garbage collection, there are good
commercial and public-domain garbage collectors for C++."

http://www.research.att.com/~bs/bs_faq.html#garbage-collection

The rest of this FAQ also provides some good reading on some of the topics
you bring up above and below.

> If you have any need to use explicit memory management at all,

Well, I can certainly say that I've never used a garbage collector in C++.

> I question why you are not using C?

Oooookaaaaay.... now I'm beginning to wonder exactly how much you _do_ know
about C++, Greg. Are you just asking to see if I know why I'm not using C
(I do, but there's too many reasons to go into right now), or are you
asking because you really seriously don't know why someone would use C++
instead of C?

_I_ don't know why someone would use C instead of C++ (unless for very
specific performance reasons - eg. you don't have access to a good C++
compiler on one of your target platform(s), or you just have a need to do
stuff at a low level and you don't have a need for any of the extra C++
features).

> When would you want OOP _language_features_ (as opposed to OOP design) as
> well as explicit memory management?

I've heard of people attempting to write OO code in C. The thought scared
me :(.

I believe I have read some stuff somewhere talking about the limitations of
OO-by-convention programming in C as compared to OO programming in C++.
I'll see if I can track it down and get back to you.

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

Um.... "there's more than one way to do it?" :)

Have a read of "The Design and Evolution of C++" sometime. You can borrow
my copy if you like via the Shugg pipeline. Bjarne talks about this topic
at quite some length in that book. 

> At any one time, you will find yourself using a Java-like subset, or a
> C-like subset, or an ML-like subset,

I don't know enough about ML to argue about that, but I think the fact that
you _can_ program in a style much like those three languages indicates that
C++ is more than a single-paradigm language.

BTW, the FAQ I offered a link to above includes this snippet which I just
noticed after you mentioned ML:

  Standard C++ and the design and programming styles it supports owe a debt
  to the functional languages, especially to ML. Early variants of ML's
  type deduction mechanisms were (together with much else) part of the
  inspiration of templates.

I may have to take a further look at ML. Sounds intriguing.

> but trying to mix and match styles is a recipe for disaster,

You reckon? Always? What if the different styles actually work well together?

> 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,

I'd say so, yes. :)

> but you mind will not thank you for this,

It'll thank you more for learning multiple languages each of which uses a
different "style" or programming paradigm and then trying to use them
together?

> and the disjointed integration of feature-sets largely prevents any
> speedup in the learning process.

Then you use what programming styles you think are appropriate. But the
language doesn't force you to use only one.

BTW, I'm not sure what specifically you're referring to when you mention
"disjointed integration of feature sets". Could you give a C++ example?

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

Even when the standard sucks (and it's not a truly open standard)? (I
originally had a smiley here, but then I realised I actually meant this
question quite seriously, so I took it away)

The Swing GUI does have a few minor (to put it mildly) limitations. I'd
much prefer Qt or wxWindows for cross-platform GUI development, and not
just because they're written in C++.

> > Greater scope in programming style and syntactic sugar. I'd be mildly
[ ... ]
> You use C++ operator overloading? There may be no help for you. :)

Operator overloading is highly nutritious and good for the digestion.

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

But... it's not one function.

Just because you have

int add(int a, int b);

and

double add(double a, double b);

it does not mean that add(int, int) and add(double, double) are the same
function just because they have the same name.

And... "object and non-object"? C++ functions are defined with parameter(s)
of certain types and a return value of a certain type. If you overload an
operator (or write any kind of function), you specify it to apply to
(objects of) certain types.

> Semantically different behaviours should not (in general) be invoked by
> identical syntax - that way madness lies.

But the syntax is _not_ identical. The function that gets called depends on
the type both of the parameters and the return.

> Perhaps that is a matter of taste, but there are enough horror stories
> even from experienced programmers.

...in any language, but some more than others.

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

Does it really?

And is it _really_ smaller? Is not the entire set of Java "libraries"
included in Sun's Java "standard"?

> > 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. :)

Hmmmm. Someone want to hold Greg down before he starts foaming at the
mouth? :)

> -Greg

Pete.
-- 
http://akira.apana.org.au/~pete/

-- 
A computer scientist is someone who fixes things that aren't broken.