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

[Greg Mildenhall]

On Wed, 21 Nov 2001, Peter Wright wrote:
> "Because Blob doesn't have generics, and I don't use generics, so I can't
> really see what good they might be."

You misunderstand me: I feel generics are just about essential for 
high-level programming.

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

On the contrary, I use generic programming enough that I can't bear a 
weak implementation of it.

> > I simply cannot imagine a problem domain where generic
> > programmin would be an advantage, but you will still use C++.
> 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?

The latter.

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

In some languages, generics are not considered so magical that they need
their own library, rather all libraries are as generic as they can be,
because that is just the way things ought be done.

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

Yes you do. I'm sure you can think of half a dozen ways in which you can
break a C++ garbage collector. Some of them would pop up in everyday 
(undisciplined) code. In particular array access, pointer manipulation...

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

Yes, but in order to use them, you lose the benefits of the C side of C++.
At that point, there is not reason not to use a higher level language.

> > If you have any need to use explicit memory management at all,
> > I question why you are not using C?

> Are you just asking to see if I know why I'm not using C or are you
> asking because you really seriously don't know why someone would use C++
> instead of C?

I'm not really using "you" in the second person sense. I very much doubt
that you need explicit memory management in your programming, since so few
tasks ever do. This frees you to use a language with garbage collection.
(and generics, hopefully. :)

If you actually _need_ to do explicit memory management, then the kind of
tricks you are playing no longer mesh with C++'s assumptions of how memory
should be treated, and at this point, you'll probably have to consider
some messy interactions every time you use the high-level features of C++
that C cannot provide, making them (IMHO) more trouble than they are
worth. Once you've rendered the higher-level features worthless, why use
them? Stick with C.

> _I_ don't know why someone would use C instead of C++
> (unless [...] 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).

Neither do I. But if you need to use explicit memory management, then you
are operating at that level already, and most of those C++ features have
become too messily entangled with your memory tricks to use.

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

You're probably running a kernel built on such principles as we type. :)

> The thought scared me :(.

I hope it doesn't scare you more than people writing non-OO code in C?

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

Yes, there are a few, but none of note once you get down to a low enough
level that you need the world's-best-assembler aspects of C/C++.

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

Yes, it allows multiple paradigms in multiple prgrams.
But not too many paradigms in one program, if you value your sanity.

> 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'm surprised this didn't tip you off about whether "Blob" had generics:
I did claim to be a rabid functional programmer in my previous post.
Unfortunately, too much was lost (Algebraic/polymorphic datatypes,
higher-order functions, partial application, et al) in translation
(because of contradictions with the nature of C) for my liking, and so C++
templates are (IMHO) only a poor subsitute for the functional abstractions
on which they were based

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

It is. (Though IMO, Haskell is more intriguing once you're used to
thinking in the functional manner)

> > but trying to mix and match styles is a recipe for disaster,
> You reckon? Always? What if the different styles actually work well together?

The styles might work well together, but too often the C++ implementations
interact in an unwanted manner.

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

Or perhaps learning a better-integrated multi-paradigm language.

> > and the disjointed integration of feature-sets largely prevents any
> > speedup in the learning process.
> 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?

The interaction of explicit memory management with the OO stuff: writing
good destructor code in a complex zoo of objects can get very hairy.

Abstract data-types (encapsulation) versus pointer maniuplation.

Templates vs. class polymorphism. (two seperate syntaxes with not entirely  
parallel semantics for two very similar ideas... and no middle ground)

Name two coding styles and I'll name a C++ conflict. :(

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

I don't know that it sucks more than the average GUI library. They
certainly all suck in one way or another, you just have to choose your
suckage to best match the way in which the rest of your app blows.

This is certainly one good reason to choose C++ over Java, but not to
choose it over languages which have a binding to $TOOLKIT.

> > > Greater scope in programming style and syntactic sugar. I'd be mildly
> [ ... ]
> > 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.
> But... it's not one function.

Ooops, sorry. One syntactic construction.

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

The point is that the behaviour of many functions should be different when
applied to an object than when applied to a primitive type. I guess this
is not as much of a problem in C++ as it would be in Java, where this
dichotomy is much stronger.

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

The local syntax is still identical, even if the types are delcared
differently in come far-off place.

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

I mean horror-stories specifically about operator-overloading and the
misreading of code it can cause. Granted it can be useful in the hands of
one good, careful programmer, but that is an unfortunately rare scenario.

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

Yes. Suckage is exponential in the size of the standard, dinchaknow? :)

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

But the seperation is clean and well-defined.

What I am really trying to say is: While C++ is indeed usable for many 
coding styles and many problem domains, I can't think of a single one
where there is not a markedly superior alternative.

-Greg