Chris said:
My post said "This can be handled if the language designers so
choose." and "Again, if the language designers want to support
this,..."
How does that turn into "the language designers didn't care enough?"
Okay, let's put this in context. Original poster asks why Java doesn't
base polymorphism on parameter types. Someone responds saying
performance. You respond saying "this can be handled if the language
designers so choose." So, what you said is that the performance impact
is solvable, and there's some *other* reason for the choice instead.
You may not have meant to say that, but you clearly did.
I objected, and you made some statement about "different trade-offs" and
"fast enough" to imply that you were minimizing the importance of
performance. I agreed that this is sometimes the case.
The "didn't care enough" was hyperbole on my part. You haven't said
what other reasons you believed the language designers to have in
omitting the feature, if indeed you believe it to be the case.
and strengths. If it was all weaknesses, no one would do it. If it was
all strengths, no one would not do it.
Of course! That's not the issue. The issue is that when someone
pointed out the weaknesses, you jumped in and and said "that can be
handled" as if it weren't an issue.
What's your evidence for this? It's messy in C++ because namespaces
are involved. But I've not seen any results that show programmers in
the Common Lisp Object System (CLOS) have any trouble here with normal
programming.
Messy in C++? It doesn't even exist in C++! The difficulty in
predicting method dispatch on so many factors is explained merely by the
observation that there are so many more factors involved. That
implicitly makes it harder to predict. Frankly, I think the amount of
difficulty people have with just static resolution of overloaded
parameter types indicates great trouble in that direction.
I don't know anything about CLOS programmers, so I can't speak one way
or the other about whether they are confused. I can only point out that
there is a much longer and more complex process involved than is
generally the case.
No one gave any performance metrics here or cited any "very real
performance measures." Googling for "multimethod dispatch performance"
finds a number of results such as constant-time lookup for Cecil, and
modest to no penalty for an multimethod extension to Java, and that
was in the first few search results.
It would take a good bit more effort than USENET is worth for someone to
put together a comparative benchmark of performance between a real
language and a hypothetical language.
You provide a pseudo-comparison in which the authors compare the
techniques using a worst case scenario piece of code, and even then
conspicuously avoid quoting results of the original code running on an
unaltered modern virtual machine using standard JVM performance
techniques. Instead, they represent "normal" with an interpreted VM; a
meaningless number, as we all know. Furthermore, even this paper making
the case for such method dispatch in Java doesn't dare apply it
universally. Instead, they mark a few very specific places to use the
technique using a marker interface, recognizing that it's not
universally applicable.
(As for constant time, I should certainly hope that method dispatch is
constant time! That's generally considered a basic assumption in
programming languages, not an accomplishment. The challenges in
practical optimization of language implementations relate to minimizing
the cache touches of the process and thus chance of a page fault, the
plain processor cycles involved, etc.)
I'm all for giving something a fair shot, but I think you're
misrepresenting the issue by claiming that general polymorphism on
parameters in Java might possibly not have a performance impact.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation