[chrisseaton]

I mean that for Ruby it is possible to compile at runtime

    a + b

And

    a.send('+', b)

Into the same thing - machine code like

    add ra, rb, rx
    jo

Except for the jo to detect overflow, this is as good as you will get from any compiler including .NET, Java, C and so on.

Ruby really isn't constrained to do anything slow for normal method invocations - you can optimise I think literally all of them away entirely if you have a JIT. For normal method invocations this all all solved back in the early 1990s in the research on making Smalltalk fast, but wasn't fully applied to Ruby until my work (and Topaz, Ruby on PyPy achieved similar results around the same time actually). I extended it to work with reflection (metaprogramming).

[gravypod]

I think that this is still a reminant of the mentality that "interpreted languages are slow" when this is just a lazy way at looking at the problem. This hasn't been the case ever since I was in diapers. I've been going back and looking at old LISP machines and what kind of optimizations they've done to get those running fast. Some of the eairly voyagers were even powered by LISP (these being real-time space probe micro-controller-like systems that are far slower the the slowest ATMega on the market right now).

Everything can be optimized at a compiler or a runtime level. Even if you just scale it back to specific idom-optimizations (as you talk about in one of your talks you've done on your JVM work) you can tremendiously boost speeds by 200 to 300% just by writing operation-specific optimizations.

It's a sad state that because of this preceived "it's going to be slow" that no one seems to be attempting to implement things that Guy Steel and McCarthy implemented way back when. This sort of lazy thinking results in the "Just right it in C" mentality that much of the python community holds.

I'm glad at least you and the JVM people are working on this as this is quite important for all CS-focust disciplines.