In comp.lang.java.advocacy, (e-mail address removed)
<
[email protected]>
wrote
Java programmers seem to always be whining about how confusing and
overly complex C++ appears to them. I would like to introduce an
explanation for this. Is it possible that Java programmers simply
aren't smart enough to understand C++?
This is not merely a whimsical hypothesis. Given my experience with
Java programmers --- the code they write and the conversations they
have --- Occam's Razor points to this explanation. For example,
"Oooh I'm confused about the difference between pointers, references,
and objects! How confusing!"
[rest snipped]
First rule of software: know thy tools. This includes
the computer, the compiler, and the environment.
Both Java and C++ aim for a niche: the specification of
instructions to a modern computer. There are, of course,
many differences.
[1] Java hides pointers. This can be a good or a bad
thing; it's good in that Java has the option of playing
garbage collect (built in). It's a bad thing when Java
developers forget and leave an object to moulder in
a global collection map and then wonder why there's a
"memory leak".
[2] Java does not have operator overloading. C++ does.
In C++, this can be a convenience but it also can lead to
some hairy expressions.
[3] Java does not have a C preprocessor. C++ does. And
one thought operator overloading was bad. The Obfuscated
C process is testimony to some of the abuses of a useful
construct; fortunately those are for humorous purposes.
[4] C++ doesn't have packaging. Java does. While there
are some quirks in the implementation of packaging in Java,
it's a very nice way to organize one's code.
[5] Java doesn't have explicit deletes. The garbage
collection is expected to take care of things. (There are
some exceptions; a FileOutputStream for example will be
left open indefinitely, even if the reference is lost.)
There's a fair number of others but these will do for a start.
In any event, many programmers, myself included, migrated
from C++ to Java. To call us stupid invites ridicule, if
not worse.
As for operator overloading -- I'll admit, I occasionally
miss it. Matrix operations in particular would benefit
somewhat from a shortening of the notation; one could write
P = M * N instead of P = M.multiplyBy(N). But operator
overloading does complicate the language, requiring the
compiler to sort out whether an operator is overloaded or
not (and operator precedence issues). In Java it would
be especially bad as the operator may require a run-time
lookup.
If one assumes that an operator can be declared by the pseudo-code
(which looks suspiciously like C++, of course
)
String operator+ (String x, String y)
{
StringBuffer z = new StringBuffer();
z.append(x);
z.append(y);
return z.toString();
}
Integer operator+ (Integer x, Integer y)
{
return new Integer(x.intValue() + y.intValue());
}
and then have a code sequence
Object a;
Object b;
Object c = a + b;
what operator should be executed, and when should this be determined?
C++ doesn't have this problem, as all routines are determined at
compile time except for virtual methods.
It is possible Java could implement a C++-like solution (and complain
in the above case as I've not defined operator+(Object,Object)) but
someone will probably be unhappy with whatever solution is finally
implemented.
One can also compare Java to C#. I lack expertise in C# beyond what
I've seen in the press but know that C# has the interesting property of
converting an assignment:
a.b = c.d;
into a sequence of function calls:
a.setB(c.getD());
by a declaration within the classes somehow.
This can get arbitrarily tricky. I'm not sure if I like this property
or not. As I understand it, interactions with [] further complicate
things.
Java avoids all this; except for an issue that one can have variable
lengths in each array row in an Object[][] variable (which is easy
to resolve with some care), one can be sure that
a.b = c.d;
means
a.b = c.d;
