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 -- http://mail.python.org/mailman/listinfo/python-list