Ryan Davis wrote:
> Whether you expose the runtime structures or not is independent of how 
> you optimize the language. YARV isn't exposing anything more than MRI 
> does AFAIK, while rubinius is. Both can have the same level of 
> optimization (with different levels of ease of implementation. imo, 
> rubinius is going the easier/cleaner route just by using a better 
> language).

I think you're theorizing here about what optimizations are possible in 
YARV versus Rubinius.

> Hotspot seems to do just fine without exposing runtime structure as 
> well, as do various implementations of lisp/scheme (some are still 
> implemented in straight C), self (which isn't written in itself--yet), 
> and most of the smalltalks (the commercial ones usually still have a C 
> core).
> 
> Implementation details are orthogonal to language specification.

Implementation details, perhaps...exposure to userspace of APIs to 
manipulate runtime constructs like frames and scopes, definitely not. 
It's an entirely different ballgame when there are public, specified 
APIs for explicitly manipulating the call stack or arbitrary variable 
scopes. That at least can be predicted reliably and optimized for. 
What's different about Ruby is that there are a few secret methods that 
make such modifications under the covers, and there's no way to detect 
them or prepare for them. That's quite different from the languages you 
listed.

>> And hotspot evolved out of self and strongtalk, so I'm not sure I 
>> understand that logic.
> 
> Yes, it did. Mostly from self as I understand Ungar's background (minor 
> fanboy here). My point was that various aspects of hotspot (the ones 
> that came from self) do plenty for optimization in a completely dynamic 
> way.

Based on a much more restrictive language than Ruby. It's hard to draw 
that parallel when Java is extremely static and restrictive in nature. 
HotSpot has a much easier time optimizing because it has almost perfect 
knowledge of what's going to happen, with only a few exceptions.

- Charlie