Dive Into Java?

[Diez B. Roggisch]

Bjoern Schliessmann wrote:

> Diez B. Roggisch wrote:
> 
>> While I do not love java, this is one of the dumbest statements
>> for a while in this NG - even though it is not meant to be too
>> serious.
> 
> Thanks for your concern. I didn't really state this from dumbness
> though.

What do you mean by "from dumbness"? I didn't accuse you of being dumb, if
that is what you are concerned of. But the statement was.

> BTW, definitely consider looking up "irony" and "emoticon" in an
> encyclopedia of your choice.

Putting a single emoticon on the end of an unreflected and wrong statement
doesn't make that statement a beacon of irony and wit. And in context of
somebody seeking enlightment regarding java, it's especially unhelpful and
confusing I think. Which was the reason for my post.

> C++ has a lot of wicked, complicated features like overloadable
>> assignment statements and so on, misses GC, and is in general
>> semantically very overloaded.
> 
> Maybe. Though I think there /are/ languages with more complicated
> features, with an imperfomant GC that can't be controlled, or more
> semantically overloaded.

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? 

IF you talk about java and GC: yes, can be painful sometimes, in high-load
scenarios. And you can tweak it, btw. 

But I can count the cases I ran into GC-troubles on one hand, where the
number of segfaults due lack of GCing in C++ are endless. And certainly not
only for me....

> BTW, what exactly do you mean by "semantically overloaded" in the
> case of C++? E. g. the :: and . operators where one could do both?

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. 

The subtle differences between pointers and references.

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

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

I could continue for some while...

>> All that make programming it a real PITA, as you permanently are
>> at risk loosing your feet through self-inflicted gun-shot-wounds.
> 
> It can be quite convenient. Not as convenient as Python, but it's
> not impossible at all to write working code without hundreds of
> bugs. But that's what it reads like in your posting.

I didn't state that you can't produce working code with C++, I said that it
is remarkably more difficult than with java (and python anyway). Because of
aforementioned complications in the language design of C++.

>> While Java is a language that makes it difficult to produce nice
>> or beautiful code,
> 
> 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? 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. Not to mention struct and friend of course.

Yes, they tried to make it appealing to the eye of a C++-programmer. But
that pretty much is it.

>> it certainly is a language that hinders you to shoot in your own
>> foot really badly.
> 
> No, it is a language that forbids almost everything from C++ which
> could be dangerous, and at the same time reimplements some of those
> features "under the hood": E. g. no operator overloading, but "+"
> concatenation of strings. What if you'd like to implement your own
> string-derived class? Ah, never mind. Operator overloading is
> bad(tm) ;) <= Irony, definitely

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. But nothing with operator overloading of + for _all_
objects that support toString()....

Yes, Java lacks operator overloading, and that is a pity sometimes. But
getting productive with it is certainly in between python and C++, and not
below.

Diez