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