Thursday, December 13, 2007

Back to the future

If you look at the programming language history poster there's a bunch or arrows leading to Java genesis, one of which comes from Smalltalk. Ok, I heard about Smalltalk and saw some code in books. I also knew that Gilad Bracha was one of the authors of Strongtalk (Smalltalk with static types) and later immensely contributed to Java evolution while working at Sun. I also saw references to this supposedly great language called Self in some programming language articles. But only now I see how it all linked together thanks to Avi Bryant's Keynote at RailsConf (yeah, of all places to learn about Java...) so I decided to transcribe here a small portion of this fascinating talk.

"There's a legend that there's something inherently about Ruby that makes it hard to implement a fast VM for it, because of open classes, because of dynamic typing - there's something about meta-programming, something about Ruby that makes it hard in this day to make it run fast. And it's just not true! It was true 20 years ago - it was a hard problem, but people solved it.

This is actually from Sun site, this is a bunch of papers that collectively explain how do you make Ruby go fast. But you'll note that they're written in 1989-91, you can go and look at the URL here, they come from the Self project. And the history is kind of interesting here, so since this is about the future and about the past, I'll give you a really brief history.

Self was a project at Sun to do Smalltalk, but even more so. Even purer object-oriented. And it meant that they had to find ways, because they wanted to make it so object-oriented, so pure, so turtles all the way down, they had to find more and more ways to make it go fast. And the technology they came up with was so interesting that they actually spawn off a start-up to try to implement new super-fast Smalltalk that was gonna be used on Wall Street. But before they got to release it, this was gonna be called Strongtalk, before they got to release it, Sun bought them back.

And Sun used the technology, used the HotSpot profiling and Just-In-Time compilation technology that have been developed here to build the Java VM. Which is sort of one of the great tragedies of technology, but it's true, that Java HotSpot VM in fact is what came of all of this great work of making dynamic languages go fast - of course they crippled it so that it doesn't make dynamic languages go fast anymore, but maybe that'll change. One interesting footnote to this is that a lot of the engineers that were involved in that have since left Sun and are back to doing Smalltalk."

2 comments:

Gilad Bracha said...

Hi Yardena,

Thanks for the kind words. If I might comment Avi's comments:

1. You don't need to go as far as Self or Strongtalk to make Ruby much faster than it is now. Even a straight Smalltalk interpreter like Squeak outperforms Ruby by a huge margin.The Ruby implementation is just slow and naive.

2. Self was not intended to "do Smalltalk". It was intended as ne language that would go beyond Smalltalk. That's probably what Avi meant by "even more so", but it could be misinterpreted.

3. Strongtalk was not spawned off by the Self group or by Sun. It was Dave Griswold's initiative. Key players on the team were Selfers - Lars Bak and Urs Hoelzle; but others were not, and likewise, key Selfers (including Dave Ungar and Randy Smith, the inventors of Self) were not involved in Strongtalk.

4. "A lot of the engineers involved have left Sun". Actually, all of us have left Sun. I was the last to stick around.

Despite the quibbles, Avi is basically correct. And yes, one could run Ruby on Strongtalk or Self or a commercial Smalltalk like Cincom or on a new VM and get spectacular improvements in performance.

Why hasn't this happened? I can only speculate. The Ruby community is focused on I/O bound tasks; given the performance, that' s not surprising.
Given that focus, no one seems to have the combination of time/will/talent to change the performance. It's chicken-egg thing.

Anonymous said...

Ruby's trickier than most due to more extensive dynamic features. You can actually add local variables to scopes after the fact. Other dynamic languages I know (JS and Python) don't support that. This kind of flexibility is nice in ways, but if you make it pervasive, optimization can get a lot more complicated. That said, I'm no expert on optimizing dynamic typing.