This announcement came down from the top, by both Matz and Koichi. Matz, short for Yukihiro Matsumoto, is the creator of the Ruby language; Koichi is the developer of YARV, the “official” virtual machine for Ruby 2.0.

Making the situation more interesting is the development of two other interpreters, JRuby and RubyCLR. JRuby targets the Java VM, and is developed by Charles Oliver Nutter and Thomas Enebo, both of whom have recently been hired by Sun. RubyCLR, of course, targets the Common Language Runtime that powers .NET. It is developed by John Lam, who has been hired by Microsoft, not wanting to be left behind.

Chris Petrilli, provides a rundown of the current situation. And, while these VM efforts are admirable, Patrick Logan calls it like it is:

Seriously, Ruby is in dire need of a decent implementation. The JVM and the CLR are fine for what they are, old legacy. But Ruby needs its own *modern* implementation.

That leads me to Strongtalk. Strongtalk is a virtual machine for Smalltalk that adds on optional static type system, from which it derives its name. It was developed by a company named Animorphic, which was acquired by Sun, who put its engineers to work on the JVM.

Sun recently released the Strongtalk code under an open source, BSD-style license. Admittedly, the code has not been actively developed for about 10 years. Yet the research behind Strongtalk is state-of-the-art as far as dynamic, interpreted languages are concerned.

Having a Strongtalk-powered VM for Ruby would have a number of benefits. The most important benefit would be giving Ruby the advanced, high-performance VM that it desperately needs. Also not to be ignored is the the need a pure open source implementation, not mired by the questionable licenses that currently hinder both Java and the CLR. And, in my own idealistic programming world, it would unify Smalltalk and Ruby under a common runtime.

My Objective-C leanings lead me to use Ruby as a scripting language. Ruby has been propelled into the spotlight recently by Ruby on Rails, an incredible framework for developing web applications.

Objective-C and Ruby are both descendants of Smalltalk. All three languages are object-oriented, and have the notion of message passing as a central construct. Message passing is not found in more popular languages like C++ and Java, yet understanding it can give any developer an invaluable new perspective.

In an attempt to further my understanding of these concepts, I’ve recently been studying Smalltalk. While having been around for more than 30 years, the concepts behind the language are still considered state-of-the-art and its influence is broad. That influence extends all the way to the web, as I discovered in a recent entry by James Robertson.

Found in the comments is a link to an editorial by Dan Connolly, dated February 13, 1997. From the article:

HTTP was design as a distributed realization of the Objective C (originally Smalltalk) message passing infrastructure: the first few bytes of every HTTP message are a method name: GET or POST. Uniform Resource Locator is just the result of squeezing the term object reference through the IETF standardization process.

Recent projects have caused me to view the web as just such a distributed object system. However, I was not aware of the historical link to Objective-C and Smalltalk. Seen in that light, though, the message passing approach is remarkably consistent.

David Heinemeier Hansson, the creator of Ruby on Rails, is a true innovator in the web application frontier. His addition of Active Resource to edge Rails is the natural next step in this line of thinking. In his keynote address at RailsConf 2006, he gives a compelling presentation about the benefits of discovering a world of resources.

Message passing languages are efficient and productive for application development. Unfortunately, they have a minority stake of developer mindshare. Ruby and Rails are currently improving this situation. It may be wishful thinking, but I’d like to see these trends renew interest in Objective-C and Smalltalk as well.