Ruby is the New Smalltalk

January 28, 2012

Over the past few months, I have had the opportunity to use the Ruby language on a small project.

Ruby was designed by Yukihiro “Matz” Matsumoto as an fully object-oriented, dynamically typed, interpreted language. Its design was influenced by Perl, Smalltalk, and Python.

What surprised me was the degree to which the language reminded me of Smalltalk – everything is an object and there are many familiar Smalltalk methods such as “select” and “collect” for collections.

All of the consulting work that I have done over the past decade has been for Internet applications with an emphasis on RIA (rich Internet application) architectures (ie with large amounts of JavaScript).

This usually involves considerable manipulation of data structures such as dictionaries and lists. And Ruby is very powerful in this area with an easy syntax for declaring literal structures ([…] for lists and {…} for dictionaries.

The Ruby environment that I use is on the Heroku cloud platform. Heroku, recently hired “Matz”, the inventor of Ruby, as a full-time member of their staff.

Twenty years ago, I used to build Smalltalk applications for Unix desktop workstations. There were many flavors of workstation popular at the time and Smalltalk offered a single solution to run on all platforms. With the current dominance of Windows and MacIntosh, the requirement for multi-platform desktop apps has mostly disappeared.

Today’s application environment is increasing becoming Internet based where standard protocols (HTTP,HTML,CSS,JavaScript,etc) mostly hide the specifics of client devices.

The client-side application language seems to be standardizing on JavaScript. So, our language choices come down to what works best on the server.

And, as I said earlier, Ruby is a descendant of Smalltalk which has excellent server-side implementations. My sense of Ruby is that it is about 80% influenced by Smalltalk, and perhaps 10% each by Python and Perl.

So, I think that one of the main reasons that we have not seen, and IMHO may never see, a Smalltalk revival is that its “ecological niche” is now occupied by Ruby.

The development environment so beloved by Smalltalkers (with browsers, inspectors, debuggers, etc) really had very little to do with the Smalltalk language itself but had more to do with the single-user desktop platform which Smalltalk was designed for.

On a desktop platform, you can halt a process to inspect its internal state. Internet applications running on a shared server hundreds or thousands of kilometers away are a totally different situation.

“Smalltalk-like” tools can probably be developed for many of the popular modern languages such as Python, Ruby, Clojure, Scala, or Groovy.

And maybe even for PHP…


11 Responses to “Ruby is the New Smalltalk”

  1. “On a desktop platform, you can halt a process to inspect its internal state. Internet applications running on a shared server hundreds or thousands of kilometers away are a totally different situation.”

    What if we are developing a distributed system.
    As thought experiment I’ve been thinking of developing a twitter like software… but in which every user account was a squeak virtual machine.

    Such a system would be in the spirit of “computers all the way down”

    I’ve developed php application for 10 years. Now I’m looking for an alternative I’m torn between Ruby or Smalltalk.

    So your thoughts on the matter are really valuable to me.

    • Peter Fisk Says:

      Hi Alejandro,

      I’ve been thinking of developing a twitter like software… but in which every user account was a squeak virtual machine.

      IMHO, that is not a good idea because of the startup time for Squeak – people won’t wait 30-60 seconds until the image loads.

      My suggestion is that you set up a *free* account on

      You can choose from:
      — Clojure (Lisp)
      — Ruby (Rails is optional)
      — Python
      — Scala
      — Node.js
      — Java (don’t use Java)

      For a fast, lightweight system (like Twitter) Node.js is probably the best solution because it uses an event-driven model.

      Hope this helps.

      — Peter

  2. PeterO Says:

    Ruby is a step in the right direction, but I disagree with your assertion. If you Google “Smalltalk vs Ruby”, you will find many references stating the opposite. You will read articles with titles such as “Ruby is Smalltalk minus minus.” When it comes to developer productivity, Smalltalk wins hands down.

    Languages can have religious followers. For many, supporting the development environment they know best, seems to be their default. In an objective comparison, features and benefits that are most important include: ease of learning; developer productivity; application to specific problem domains; power and flexibility; maturity in terms of robustness; limiting technical risk for mission-critical applications… I can go on. Any single language can not be the best technology for all problems or projects.

    Here are a few URL links to articles comparing Ruby with Smalltalk:

    I doubt, Ruby is the New Smalltalk. Although Ruby does close the gap. My bias, best use of money and time resources for business applications. Smalltalk remains well ahead of Ruby.

  3. Carl Gundel Says:

    Well I can see how Ruby may successfully replace Smalltalk in the development world at large, but only because people might not appreciate what makes them different from each other. Ruby isn’t really a descendent of Smalltalk. I suggest that ‘cousin’ is a better word for it.

    It does seem like a clever enough invention though and I understand the appeal of it.

  4. Marten Says:

    Well, perhaps IDE’s for those languages could be developed – but where are they and who would use them ? We have tremendous IDE’s out there (VS, Eclipse) – but they all miss parts when comparing against these living objects in Smalltalk images – and none of them have reached the interactivity of Smalltalk IDE’s.

    I’m working with VisualStudio everyday – marvelous part of software, but with a complexity I would never think of – and with technical problems here and there and with a memory consumption, where a Smalltalk IDE’s looks like a very little program against.

  5. Hans-Martin Says:

    The one thing that still differentiates Smalltalk from many newer languages (the image) is vastly underappreciated in the development world. Even for web development, being able to debug and change/fix the running code is extremely valuable. Whenever I demo the power of Seaside or any other Smalltalk-based web app framework, people used to file-based languages are amazed by the power of this approach.

  6. Good observations, but you missed the biggest influence on Ruby — Lisp. According to Matz, this was his recipe for Ruby:

    “Ruby is a language designed in the following steps:

    * take a simple lisp language (like one prior to CL).
    * remove macros, s-expression.
    * add simple object system (much simpler than CLOS).
    * add blocks, inspired by higher order functions.
    * add methods found in Smalltalk.
    * add functionality found in Perl (in OO way).

    So, Ruby was a Lisp originally, in theory.
    Let’s call it MatzLisp from now on. ;-)”

    • Peter Fisk Says:

      Very interesting.

      Alan Kay was influenced by Lisp as well when he was designing Smalltalk.

      I learned both Lisp and Smalltalk the same year – in 1987.

      After 25 years, I still haven’t decided which one I like the most.

      Maybe that is why Ruby seems like a good language to me – it combines ideas from both Lisp and Smalltalk.

      — Peter

  7. Antoine Says:

    Any flavour of Smalltalk has a better development environment than Ruby or Pyhton. I guess that if the proponents of those languages were eager to allow a Smalltalk-like experience, they would already have made something in that direction.
    Smalltalk sure is a language but it’s a different way of writing source code, and nor ruby or python have it.

    • Peter Fisk Says:

      I have used Smalltalk for about 25 years, and from 1987 to 1997 it was the main programming environment that I used (both VisualWorks and VisualAge).

      However, I find that I can be more productive when building web projects by using Ruby, Python, or Clojure.

      They have a much better syntax for handling data structures which means that I write a lot less code.

  8. PeterO Says:

    There are many, many Smalltalkers I know that would love to use a full Smalltalk development environment for their revenue-generating work. For my company’s requirements, Smalltalk lacks: (a) a VM that can properly utilize today’s multi-core processors on the server-side; (b) a ubiquitously deployed runtime environment for client-side apps; and (c) better inter-operability with other systems. We have implemented certain work-around designs to minimize the above limitations, but these are long-term key issues.

    Ruby and the other dynamic languages are also challenged with VMs that have limited multi-core capabilities. Ditto on the client-side VMs. Integration with other systems is more a matter of modular design and maybe utilizing JSON, WebServices, host OS APIs…

    Peter Fisk is on the right track with a Smalltalk executing on top of a Javascript VM, the most ubiquitously deployed runtime environment on the planet. This is an ambitious vision and project to implement fully, but worthwhile if it can gain critical mass support and functionality. It is simply too much for one guy to complete on his own.

    I would like to see an open-source Smalltalk-on-Javascript-VM with critical-mass support.. Everyone on this blog and other Smalltalk-centric blogs may want to speak-up and man-up if they would like to ignite interest and commitment for an end-to-end Smalltalk, from server to web-client.

    I am aware of two projects that are focused on a multi-core capable VM for Smalltalk. In addition, it may be possible to have a reasonable Smalltalk on top of a .NET and/or Java VM in the near future. Both of those VMs support multiple threads and cores. Both of these VMs are improving support for dynamic languages.

    The commercial Smalltalk vendors could speak up and share their insights on a market they know better than any of us. It would certainly be in their best interest.

    I have a Smalltalk bias, as Smalltalk has been a secret-weapon in terms of productivity, ease-of-learning, code re-use, and competitive advantage. I would like to encourage discussion around what it would take to have critical mass support for Smalltalk-on-Javascript, and beyond… (inspired by Buzz Lightyear).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: