Sunday, July 15, 2007

Smalltalk, Outside The Ivory Tower?

If you went to RailsConf, you saw Avi Bryant explain how Ruby can be seen as essentially just a Unix dialect of Smalltalk.

It's a meme. You can see an example of the same idea on Ramon Leon's blog, and in this quote from Kent Beck:

I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby.

One way to look at the Ruby on Rails success story is to say that constraining Smalltalk within a virtual machine trapped it. By transferring Smalltalk to a Unix environment, Ruby let the genie out of the bottle. The minute Smalltalk left the confines of its virtual-machine ivory tower, it turned out to be not the doddering academic many people had remembered it as - and indeed forgotten it as - but instead an elderly kung fu badass, like a dude from a 70s movie who can still kick the crap out of thirty different people at once when he's in his 70s.

Not this:

Bueller? Bueller? Anyone?

But this:

Smalltalk definitely contained ideas so powerful that you could change the world forever by commercializing them.

Maybe that's still the case.

There's just one problem with this idea, however: Matz himself might not agree with it. The creator of Ruby named Ruby after Perl, and has said he wanted a language "more powerful than Perl and more object-oriented than Python." Matz' comments in a recent discussion about Ruby's block syntax on the ruby-talk list referenced CLU, not Smalltalk, even though Smalltalk's blocks have a lot in common with Ruby's.

One thing I'm sure of, however: writing Smalltalk will make you a better Ruby programmer, even when you're still just barely making sense of it in your tiny fragments of spare time. The need for small, concise, atomic methods becomes not just clearer to understand but simpler to satisfy.


  1. Matz has stated elsewhere that the three main inspirations for Ruby were Lisp (he wrote a mail client in Lisp before working on Ruby), Smalltalk and Perl.

    He was just saying that the 'yield' keyword was borrowed from CLU, not blocks.

    His stated beef with Smalltalk is the syntax isn't clear enough.

    The influence of Smalltalk is all over Ruby.

  2. Instead of "VM", don't you mean "image"? Ruby runs on a VM (several, now!) as well, but the environment is not caged inside the image.

  3. The object model itself is lifted almost directly from Smalltalk. The failure to lift blocks and use yield allowing the passing of a single magic block was a mistake and is one of the few things where Ruby suffers. It'd have been better to copy Smalltalk more in that regard.

    Lisp also heavily influenced Smalltalk, so it's hard to say whether Ruby copied Smalltalk for some things, or was influenced by Lisp just as Smalltalk was.

    It doesn't really matter. Programming in Ruby feels very much like programming in Smalltalk, just without all the great tools and environment Smalltalk provides.

    Both Lisp and Smalltalk allow the programmer access to the running image and the ability to recompile, at the method level, that image. Image based development is where Ruby really dropped the ball.

    Most Smalltalks do only image based development, but Lisp does both image and file based development proving that you can live in both worlds successfully.

  4. Smalltalk is a Walled Garden of programming languages.

  5. @Ramon: Programming in Ruby feels very much like programming in Smalltalk, just without all the great tools and environment Smalltalk provides.

    Which is a gigantic "just". For me, that makes programming in Ruby feel almost nothing at all like programming in Smalltalk. Maybe like programming in Smalltalk with one hand tied behind my back...

  6. @anonymous: "Smalltalk is a Walled Garden of programming languages."

    There's Self, implemented in Smalltalk, and LispKit, an implementation of Lisp and Scheme in Smalltalk.

    There's an article on LispKit (linked to on the LispKit page). It's a start, providing some basic functionality. I don't know about the Self implementation. Each of these could probably be better developed. The point is it's possible to implement other languages in Smalltalk.

    I have little doubt Ruby and Python could be implemented in it, just as they are now implemented in C and Java, if anyone would dedicate the effort. But I'm sure the retort would be, "what's the point in doing that?" Indeed, I couldn't really tell you. They were implemented in C for performance, and then Java for access to enterprise resources. I suppose one rationale would be the ability to run Seaside in more than one language, and access to Smalltalk's rich class library. For example even though Ruby's syntax is more limited, I think such a feat would be possible with some translation logic included. It wouldn't look as elegant.

    Seems like a lot of trouble to go through just to extend access to a continuation server. I don't understand why Ruby and indeed Rails isn't changed to make this functionality possible. So far I've heard of one Ruby-based framework, called Wee, that implements many of the ideas of Seaside, but it's completely different from Rails.

  7. Thanks for linking to my site.....

    You have really quality blog Mr. Bowkett... adding to my Reader feeds :-)


Note: Only a member of this blog may post a comment.