Well, I don't know Smalltalk, but I have read up on it and its environment. Here are a couple of points that I find interesting:
Smalltalk includes a graphic environment. I still haven't seen a solid answer on which set of graphical tools I should use with Ruby. I'd like to see a lot more done in that area.
Smalltalk is a complete environment where the system can see all of itself all the time. While it was never done, I find the idea of being able to spend trillions of spare CPU cycles doing optimization quite appealing. The vast majority of programming languages are structured so that global optimization (i.e. across modules) is impossible _and_ people are sensitive to compile time. This idea has been kicking around in the back of my head for a long time now, it's not really applicable to Ruby as long as Ruby is just a language and not the entire environment. I figured I'd let the folks on the list, who are generally much smarter than I am, think on it.
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
Smalltalk is a complete environment where the system can see all of itself
all the time. While it was never done, I find the idea of being able to
spend trillions of spare CPU cycles doing optimization quite appealing.
I've loved smalltalk from my first encounter with it back in 1980.
But very early in that encounter I learned just how dangerous a system
that "can see all of itself all the time" can be. I had a few clever
ideas that I wanted to try, and in the process of trying them I got to
learn all about rolling back & salvaging objects from corrupted system
images.
Not to say that it wasn't fun...
it's not really applicable to Ruby as long
as Ruby is just a language and not the entire environment.
That's probably the main reason I use ruby over smalltalk: ruby is
more--not quite sure what word I want here--secular? adaptive? humble
maybe? Smalltalk is wonderful as smalltalk, but ruby is easier to wedge
in to the interstitial spaces of a real system.