This post originated from an RSS feed registered with Ruby Buzz by Obie Fernandez. Original Post: Joel is wrong, StrongTalk exciting Feed Title: Obie On Rails (Has It Been 9 Years Already?) Feed URL: http://jroller.com/obie/feed/entries/rss Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Obie Fernandez Latest Posts From Obie On Rails (Has It Been 9 Years Already?)

He used to be one of my heroes, but lately it's getting hard to even give him the benefit of the doubt.

Without knowing much about the implementation of Ruby, I would guess that the biggest issue is around late binding and especially duck typing, which prevents type inference or strong typing, which means that function calls will always be slow because you can never get something compiled down to the point where a function call is just a single CALL instruction (on x86)

As Avi Bryant points out that is simply wrong: "A proper implementation of a duck typed language will get method calls down to a single jump plus a single compare, 95% of the time. There?s no vtable indirection needed, which means that it?s generally faster than C++, because branch prediction works and the pipeline doesn?t stall."

Given Avi's smalltalk expertise I do believe him -- later in the same post he mentions that Sun has fully open-sourced StrongTalk, described as "by far the fastest implementation of Smalltalk ever."

One of StrongTalk's advances is its strong, static type system for Smalltalk. "Aha!" you might proclaim, "that's why it's so fast isn't it?" NOPE.

According to Avi:

The thing that?s most interesting about Strongtalk is that it does allow optional static type annotations, but the optimizer completely ignores them: your code runs exactly as fast if you duck type everything as if you statically type everything. That?s not because the implementors were lazy - their goal was to produce the fastest system possible, it?s just that their dynamic implementation was already fast enough that the static information didn?t help.

I find these kind of developments very exciting and promising for the future of Ruby as a viable mainstream language with the kind of adoption that Java and .NET enjoys. As Avi points out, "As it happens, the Strongtalk VM would make an excellent basis for the next generation Ruby VM. Given that Sun still employs some of the original Strongtalk engineers, and has just hired the JRuby guys, maybe they can make that happen?"