Dive Into Java?

[Bjoern Schliessmann]

Diez B. Roggisch wrote:

> What do you mean by "from dumbness"?

It didn't originate from the "dumbness" area of my brain (== it
wasn't my honest opinion). It was meant satirical.

> And in context of somebody seeking enlightment regarding java,
> it's especially unhelpful and confusing I think. Which was the
> reason for my post.

I understand.

> So what? Either you talk about Java here, then name it and prove
> these points, or not, then where is the relevance of that
> statement to this discussion?

Again, it wasn't meant as honest and true argument. I'd better try
not to try be funny.
 
> For example: the overloading of assignment operators, casting
> operators, copy constructors and the like that, and the fact that
> one of them is possibly chosen in absence of the other.

Isn't the overloading concept an effect of type strength? In Java,
you'd have to overload them too. Or am I missing something?
 
> The subtle differences between pointers and references.

That's an issue, though you don't have to use them both. Kind
of "historically grown".
 
> Ahh, not to forget the joys of slicing through non-virtual
> copy-constructors. And while we are talking about it: virtual - a
> keyword with a great deal of meanings....

ACK.
 
> Missing definition of static initializer order, at least for some
> binary formats.

Didn't come across this one though.
 
> I could continue for some while...

Okay, I got it :)

>> because it wanted to be new and good but took over much of C++'s
>> syntax and made it even weirder,
 
> Even weirder? Care to explain?

Example:

int spam = 5;

but

String eggs = new String();

The latter seems totally unnecessary to me, as well as being too
verbose -- why couldn't they go the simple way as in Python and
just state

String eggs;

-- is it because in C++ it'd mean something different?

> While they _did_ choose some 
> unneccessary syntactic crud to stay in, even though it isn't
> needed (e.g. the superfluous new-keyword), I don't see a lot of
> things like ::, ->, virtual, =0 and so on.

ACK.

> Not to mention struct and friend of course.

Mh, struct seems to be an ancestor from C and being kept for
compatibility reasons (like many other stuff in C++
though). "friend"? Mh, nice to have, I once needed it. But anyway,
I like the Python way (don't forbid anything) better.

> Yes, they tried to make it appealing to the eye of a
> C++-programmer. But that pretty much is it.
 
That's a wrong decision, IMHO. A new and practical language (what
Java wanted to be) shouldn't provide 3/4-compatible syntax, but be
clear, concise and customizable, and shouldn't say "That's bad, you
mustn't do that."

> You are confusing things here. That you can't implement your own
> string derived class has to do with java.lang.String being final -
> something I grief about, too.

That's not exactly my point. What if I just wanted to build my own
interface compatible class ... impossible.

For a start, it just doesn't look pretty ...

String ham;

ham = "1" + "2";

... is translated to ...

ham = new StringBuffer().append("1").append("2").toString()

> But nothing with operator overloading of + for _all_ objects that
> support toString().... 
> 
> Yes, Java lacks operator overloading, and that is a pity
> sometimes. 

And that was a clear design decision that is defended as "groovy"
until today.

Another funny thing are those awkward wrapper classes, but that's
been "patched" in an awkward way with 1.5 IIRC.

> But getting productive with it is certainly in between python and
> C++, and not below. 

May in parts depend on the scenario, but ACK.

Regards,


Björn

-- 
BOFH excuse #442:

Trojan horse ran out of hay