Re: why are overloaded methods statically bound?

From: Chris Smith (cdsmith_at_twu.net)
Date: 11/01/03


Date: Fri, 31 Oct 2003 16:01:50 -0700

Chris Riesbeck wrote:
> 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.

> > There are valid reasons why even a good
> > implementation of a language with parameter-based polymorphism would
> > have weaknesses compared to a language without it;
>
> 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.

> > and both the
> > difficulty of predicting dispatch with that many factors involved
>
> 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


Relevant Pages

  • Re: Why do some people hate java?
    ... programming language like Java to exist, or if Java must exists, there's ... The majority of programmers at the time were using C++, ... and other resources that are just as important to ...
    (comp.lang.java.programmer)
  • Re: How did C++ beat the competition?
    ... Efficiency is supposed to be built into the JVM, ... With C++ that meant that programmers had to learn a lot more or only use ... about Java as C++ programmers know about their language. ...
    (comp.lang.cpp)
  • Re: Static vs Dynamic
    ... Are you saying that the Java designers have been ... Not a very good advertisement for that language. ... it's easy to miss the bug because the code looks quite correct ... from programmers is a waste of time. ...
    (comp.lang.lisp)
  • Re: CollabRx seeks brilliant engineers for an excellent e-science adventure
    ... belief that lisp programmers are smarter/better. ... Java or PHP programmers. ... a type of language that attracts a personality that meets my perceptions ...
    (comp.lang.lisp)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... All the ISO standards in the world will not make the world ... Nothing keeps you from annotating your program with exceptions based on what ... language should adhere to your theory. ... Curiously, although you don't say it, Java has the opposite problem. ...
    (comp.lang.lisp)