Dynamically disadvantaged?

After dabbling with Ruby, Tim Bray posted some thoughts, specifically on some advantages of static typing.

(I have some reactions about the intersection of his arguments with Perl, but I want to keep that separate, so that goes in another entry.)

The point that an IDE for a statically typed language can provide a lot of conveniences isn’t new – I particularly remember Henning Koch’s previous take on it, where we had a long back-and-forth in his comments. Bill de hÓra’s response to it over at lesscode.org is the best articulation yet about why that “advantage” makes me uncomfortable.

But instead of that point, I want to linger for a moment on another:

And unless I’m missing something, the static typing ought to give the compiler and runtime enough extra information to make the code run faster; implicit in the notion of duck typing is that you’re going to spend plenty of cycles executing code like “Does this thing have a quack method and if not, does its superclass?”

Isn’t this just the sort of reasoning that was levelled against Java when the beanheads started championing the virtues of virtual machines and garbage collection? Bytecode execution was made pretty fast. Is there any reason that method lookup couldn’t? Or any other thing that might happen “a lot” in a dynamic language?

Referenced in And how dynamically disadvantaged is Perl, really?.