I seem to remember a discussions about this a decade ago, with smalltalkers saying that the only big difference is that programmatic generation of code is not so common in ST as it is in ruby (i.e. "attr_*" is possible in ST but doesn't actually exist).

Other than that I _think_ maybe ST has a fixed number of slots per class compared to dynamically added instance/class variables in ruby? My memory is fuzzy.

By the way, there _is_ a ruby built by smalltalk developers[0] exactly because the object model is 99% the same.

[0] http://maglev.github.io

I don't know Smalltalk well enough to say for sure, it's just my rather vague impression that Smalltalk is more compiler-friendly, likely based mostly on what I've read over the years about this, for example looking at:

http://lambda-the-ultimate.org/node/2606

Ruby permits adding methods to individual objects; in Smalltalk, all methods reside in classes.

In Ruby, it is practical and somewhat useful to add methods dynamically; in Smalltalk, the practice is generally to treat the methods and classes as static.

Have also a look at:

http://www.hokstad.com/the-problem-with-compiling-ruby

I don't think all those 5 problems apply equally well to Smalltalk, do they?

> Ruby permits adding methods to individual objects; in Smalltalk, all methods reside in classes.

All Ruby methods reside in classes, too, "adding a method to an object" is really adding it to the object's singleton class (metaclass).

The difference between Ruby and Smalltalk is that in Smalltalk, each explicit class has an implicit metaclass (a class in which the class's instance methods are defined), whereas for Ruby each object (including, but not limited to, class objects -- and notably including other implicit metaclasses) has an implicit metaclass (often called the eigenclass).

And note that Ruby eigenclasses are in effect perfectly normal classes, with the exceptions that: 1) they dynamically get created the first time you define a method on it, 2) they are then "injected" into the inheritance chain, yet hidden from you when you try to follow the inheritance chain.

In effect, from an implementation point of view (at least for MRI), they're just normal classes except for when you define them, and a handful of insignificant cases where you have to check a flag to determine whether or not to consider them.

> http://www.hokstad.com/the-problem-with-compiling-ruby

I wrote that one in frustration when working on my Ruby compiler project, actually, and I think there are reasonable solutions to all of them, and in fact you will find that most of them, possibly all are solved to various extents in either Smalltalk implementations or Self implementations. In particular the Self papers is an invaluable resource for anyone who wants to implement languages as dynamic as Ruby, or Javascript...

The main problem is the effort. And implementations like MRI really has not tried very hard to address any of this - you'll note it first got a bytecode version (instead of AST walking) with 1.9, and still does not JIT. AFAIK they've not even tested simple optimizations like partial vtables to avoid the costly method dispatch etc.

A big part of the challenge is that Ruby is a remarkably hard language to implement, not just or even mainly because of the dynamic features - those make it hard to make it fast, not hard to implement - but because it's still largely unspecified, the parsing is chock full of annoying corner cases, and there are lots of dark, hairy areas of Ruby that almost nobody ever see. I love Ruby, but I think it badly needs a revision that deprecates a whole chunk of functionality that nobody really uses but that affects implementations, as well as writing a proper spec and then tighten up a whole lot of areas where users would be largely unaffected, but that would make it vastly easier to implement.

So a lot of effort that could have gone into making implementations faster, go into addressing annoying digressions.

Seems to me they would apply to Javascript though, and that got quite fast with V8.

Being the one widely supported client-side language for the web means that lots more money has been poured into making JavaScript implementations effective than has gone into Ruby (I wouldn't be surprised if Google put more resources into V8 than have gone into all Ruby implementations combined.)

For example, Lars Bak (virtual machine master) is the head programmer of V8.

http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)

True, but since V8 is open-source, shouldn't it now be possible for the Ruby developers to borrow the techniques from it that made Javascript so much faster?

None of the techniques that's gone into V8 are all that novel. Most of them - at least the ones that are relevant to Ruby - stems from research around Smalltalk and Self that's been well known for a very long time. The hard/time consuming part is implementing them.

Ruby isn't JavaScript. Studying V8's solutions to particular problems with making JavaScript efficient may help people seeking to make an efficient Ruby implementation, but how much is easily transferrable I don't know.

No doubt V8 is much more mature than MRI, I think some language considerations do still apply though, JavaScript doesn't have method_missing, problem #5 doesn't apply, I guess there is more.