Ruby's Roots: Smalltalk Comeback and Randal Schwartz on Smalltalk

| Posted by Werner Schuster on Oct 27, 2008. Estimated reading time: 8 minutes |

A recent blog post by Gartner Analyst Mark Driver picks up on the increasing interest in Smalltalk. There are many factors contributing, but one of them appears to be the rise in popularity of dynamic languages like Ruby, Python and others. Smalltalk has pioneered many of the concepts behind these languages a long time before they were conceived and has been around since the 1970/1980s. Many of the Smalltalk VMs have been around just as long and have reached a high level of maturity.


Another reason for the interest in Smalltalk today is, like with Ruby and Ruby on Rails, a web framework. Seaside has been around for a while and has gathered a lot of interest. Avi Bryant is behind DabbleDB, an online database which is built on Seaside (InfoQ has an interview with Avi Bryant talking about how DabbleDB makes use of Smalltalk's image concept for persistance and how Squeak can be made to scale).

While Seaside was developed on Squeak, recently many other Smalltalk vendors have started supporting it as well. Cincom Smalltalk supports Seaside and offers WebVelocity, a GUI tool for Seaside development in the browser (a short video introduction to Web Velocity is available, a longer demonstration is available at Google Video). GemStone, who's behind GemStone/S, a Smalltalk that offers persistence and clustering, also supports Seaside, eg. with their GLASS product (which is also available in a free edition).

Ruby and Smalltalk

Smalltalk was one big influence on Ruby, and it continues to do so. Rubinius, for instance, has used Squeak Smalltalk as a model for implementing their VM, and GemStone's Maglev is built right on top of a Smalltalk VM.

While Ruby's grammar is more complex than Smalltalk's simple grammar, it's still being influenced. Named parameters ('keyword messages' in Smalltalk), for instance, aren't available in Ruby, although they can be emulated using hash iterals, a feature that's long been available in Smalltalk.


def foo(arghash)
 # ... do something with arguments

foo( :name => "foo", :size => 42)

Note: Ruby 1.9 offers a more compact literal hash syntax, which allows to omit a few characters.

The same using Smalltalk keyword messages (note that the method's name is made up of all keyword arguments):

:name name :size size
  "this is a comment ... do something with arguments"

receiver name: 'foo' size: 42.

Languages like Objective-C also have Smalltalk-style keyword messages.

Smalltalk has also managed to avoid the many variants of Lambdas, Procs and Blocks in Ruby, recently joined by the new 'stabby lambda' syntax (-> {}). Smalltalk has one way to create block: [:argument| ^42] creates a block, it takes one argument and returns the value 42.

Another difference between Smalltalk and Ruby is the availability of tools and IDEs. Ruby IDEs have only recently started to become available, whereas Smalltalk has always been closely integrated with IDEs (although there are Smalltalks without dedicated IDEs, eg. GemStone/S or GNU Smalltalk). Ruby IDEs, however, are very different from Smalltalk IDEs, for instance: all of the Ruby IDEs are written in a non-Ruby language. The Ruby support in Aptana (RDT), 3rd Rail (DLTK), Netbeans, IntelliJ is written in Java, SapphireSteel's Ruby In Steel is based on Visual Studio. There's the Ruby based FreeRIDE, although it's development seems to have stopped.

Ruby IDEs provide static analysis, type inference, and other logic for analyzing and modifying Ruby code - but all of that code is written in either Java or C# and depend on either JRuby's AST or RubyInSteel's AST. The availability of an AST of Ruby source has recently been improved with Ryan Davis' ruby_parser, which can take Ruby source and return the AST (in UnifiedRuby format), complete with comments and line numbers.

Smalltalk's IDEs,  on the other hand, are written in Smalltalk. Static analysis tools are available too, as well as refactoring tools (the first refactoring tool was actually Smalltalk's Refactoring Browser). 

Interview with Randal L. Schwartz

To get a view of someone who moved from a language often associated with scripting (Perl) to Smalltalk, we talked to Randal L. Schwartz. Randal is the author of many popular books and columns on Perl. Recently he's spent a lot of time using and advocating Smalltalk, declaring the "The Year of Smalltalk". He's also on the leadership team of Squeak.

InfoQ: Seaside's known for using continuations for maintaining state. Avi Bryant recently mentioned that the product he's working on, DabbleDB, has been moving away from using continuations because AJAX allowed for a different application model. What's your experience with this? What makes Seaside an appealing web framework to use?

Continuations allow me to create abstractions control flows, much in the same way that I would create abstractions of layout views. I can have an abstraction called "show this form until it validates" in a library, and the library can return the incomplete page containing the web form until it validates, all apparently "within" a call to the library. Without continuations, I'd have to hook up some top-level recognizer to say "ok, this is a response to a form input that this library now needs to see", and I'd lose all my local state.

InfoQ: What method(s) of persistence are you using in your Smalltalk and Seaside applications? Are you using an RDBMS with Smalltalk? What's the ORM library situation for Smalltalk?

For legacy interface, Glorp is Object-Relational mapper of choice. Glorp is in active development to add an "Active-Record"-style layer as well.
For new applications, I'd highly recommend the product from GemStone, which puts the VM inside a completely persistent environment. Objects just naturally persist, and thus don't need to be dissassembled into SQL for insertion into and retrieval from a classic database.

InfoQ: What Smalltalk versions do you use - which ones do you have experience with? Are they all equivalent - or are some more suited to particular problem domains?

I'm on the leadership team for Squeak, and I've been tracking Squeak since its initial release. I only recently started playing with Cincom VisualWorks, so I'm learning more about it as I progress. I think GNU Smalltalk is interesting, but as a Squeak contributor, I can't look at it because of the licensing issues (GPL code cannot be derived into MIT-licensed releases).

InfoQ: Ruby 1.9 added Fibers - a construct which can also be used as symmetric coroutine. Some Smalltalk versions also use these instead of exposing heavyweight kernel threads - what's your experience? In Smalltalk versions that only have userspace threads - are there situations where you'd like to use kernel threads?

I'm not a big fan of threads. In Unix, thread is spelled "f o r k" for a reason. I think sharing should be opt-in, rather than opt-out, and threads presume the wrong default.

InfoQ: You've been actively promoting Smalltalk for some time now. What are the two most common questions or objections to Smalltalk you get?

"Smalltalk, isn't it dead?" Hardly.
"Can I edit with my favorite editor?" Basically no, and you wouldn't want to use your favorite editor when you realize you're only editing 5 to 10 lines of code at once anyway, and you really want an editor that is sensitive to the current environment. The built-in code editors do that just fine.

One approach to make Smalltalk usable from IDEs like Eclipse is the STDT. It's based on Eclipse and translates Smalltalk's code into files and resources. The "Industry Misinterpretations" podcast has a long interview with one of the STDT developers. As an aside, Eclipse and Smalltalk should go together well, particulalry, as Rick DeNatale explains, because Eclipse grew out of IBM's Smalltalk efforts.

InfoQ:  What's your elevator intro to the Smalltalk  - how would you explain it to your, say, Perl friends?

Smalltalk - I can teach the *entire* syntax to you in 20 minutes. It's pure objects, and the debugger allows for live debugging, even in a web environment. Smalltalk has distributed source code management built in, and can talk to any library on the system either natively or via FFI. Smalltalk can talk to files, devices, and sockets as well as any Perl program can, and has been around for *far* longer. Every bit of your interaction with the system is open and editable and customizable, including your dev tools.

InfoQ: Who's behind Squeak nowadays - and how is development moving forward?

The Squeak Leadership team (including me) represents the community to oversee the overall project. We also have Web teams, Release teams, News teams, and so on, to handle the specifics. (

InfoQ: What features - language concepts or other - from Perl do you miss in Smalltalk, if any?

I still use Perl for command-line scripting. Smalltalk doesn't lend itself to small programs very well. :)

InfoQ: What's your opinion on Ruby's Open Classes (Monkey Patching)? Have you used Squeak's Traits?

It's nice that a package like Seaside can teach every object to "render itself" on a web page, with the class dispatch mechanism used for appropriate selection. Without that kind of patching, you have to build the equivalent of class dispatching at the user code level, and it's never as clean.

InfoQ: Ruby has seen many new implementations come along recently - Smalltalk has had many different runtimes from different vendors. Do you see the different implementations of Smalltalk as a problem or an asset?

The two big smalltalks I play with (Squeak and VisualWorks) actually shared a common ancestor (the original Xerox Parc image), so that's not much of an issue. However, projects like Seaside are actually helping to ensure that vendors stay fairly close in features, so this is a good thing.

For more information on Smalltalk by Randal, he's been interviewed on the Industry Misinterpretations podcast, and he co-hosts the FLOSS Weekly podcast. One episode is particularly interesting for everyone curious about Smalltalk: FLOSS 29: Interview with Dan Ingalls,  who wrote the first Smalltalk runtime from a language spec by Alan Kay back in the early 1970s, and many of the following Smalltalk versions at PARC, as well as Squeak. Randal also blogs about Smalltalk.

For more information on Smalltalk and how Smalltalk developers approach software development, one source is Cincom's James Robertson, who blogs about Smalltalk and also publishes a daily screencast and a weekly podcast.
GemStone has a blog focussing on GLASS, their GemStone/Linux/Apache/Smalltalk/Seaside software stack.

Finally, a list of free books on Smalltalk is available online.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I don't think so by Dan Tines

Smalltalk's keyword arguments can make APIs very english like, and Smalltalk environments really showed the productivity gains that are possible with a proper development environment.

But I could also say that GW-BASIC is "on the verge of a comeback". How long does a verge last? Does the comeback have to happen in the next year for "the verge" to be real?

It's all just a bunch of fanboy handwaving. I would expect Lisp to be "on the verge of a comeback" before Smalltalk anyway. And despite lots of predictions over the years, I never saw that happen either.

Correction Request by James Robertson


Where you link to me (James Robertson), could you link to my blog;

You've linked to Gemstone. Thanks!

Re: Correction Request by Werner Schuster

@James: it's fixed now.

Re: I don't think so by Werner Schuster

Well, if someone in the huge GW-Basic community comes up with a web framework like Seaside or a OODB (or persistent heap) solution like Gemstone/S, then maybe... ;-)

Also: this article is a look at the state of Smalltalk. No matter what'll happen in the future, Smalltalk has definitely profited from the interest in dynamic languages like Ruby. Deservedly in many cases, eg if you look at the reaction to Gemstone's announcement of MagLev (there's currently no equivalent of Gemstone/S in the Ruby space).

Also: it depends on what we mean by 'comeback'. Smalltalk companies (the companies behind the Smalltalk products) have been profitable for years if not decades. One of them, ObjectArts, recently literally made a comeback: after announcing they'd stop their Dolphin product, they took that back and are now planning their future products again.

Anyway: many of the current languages have a lot to learn from Smalltalk, so even if nothing happens any time soon, a look at Smalltalk can't hurt.

Re: I don't think so by Vaughn Vernon

> It's all just a bunch of fanboy handwaving.

I am one old "fanboy" then. I was developing with Smalltalk almost 20 years ago, and so were a lot of the patterns and originating agile community. Many in the Smalltalk community were productive at something like 20:1 against C/C++ developers. One of the most disappointing realities was when Smalltalk started to lose momentum and environments such as MS Visual C++ and MFC started to gain ground. I didn't see productivity anywhere near what like I had in Smalltalk until Java came around. I don't have a good feel for comparing Java to Smalltalk, but I don't think Java is quite up there. While I can jump into the Eclipse debugger (even remotely debugging against an app/web server) it is not the same.

I know Ruby on Rails development. I use RadRails, which is now under Aptana. To use a quotable quote, "I don't think so." I respect what RoR is and what I can do with it, but there is no way I can see Smalltalk types of productivity in Ruby the language or Rails.

I am not necessarily in a position to jump back into Smalltalk, but I wish I was being force to ;)

One of my big questions is, what are the issues with using Smalltalk on the desktop? Back in the days when I was using it evironments were highly client-server, with the rich client implemented in Smalltalk. The image was pretty big in those days, and if you wanted to "trim the blob" as we affectionately called it you had to invest in Envy Developer at $10K per seat. Obviously Smalltalk's entry point is drastically more affordable now, but what about image tuning tools?

Of course, when doing web/enterprise development, image sizes are really not an issue since they live on the server. But is the entire answer "deploy to server and use AJAX rich client," or is there still life on the desktop for times when it matters?

Thanks to those who can be involved, and here's to being force back into Smalltalk development :)


Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss