A Lot of Smalltalk about Ruby

This past week, I’ve had the opportunity to write some code in Ruby. What really struck me was how much it reminded me of another language that I haven’t used since the late 90’s—Smalltalk.

After the PC revolution of the 80’s, Bank of America rolled out PCs to all their branches with in-house written business software. This posed another problem for them, how to manage and update all the computers in every branch. Bank of America was on the cutting edge, writing their own solution to this problem. IBM even licensed this product for a period of time, until they could develop their own solution.

Starting in 1989 and throughout the 90’s, I worked on Bank of America’s software delivery system application. It was a mainframe application with a terminal-based user interface. Of course, The users of the application were operations people, which was one of the last groups of people to migrate from terminals to PCs. Outside of the bank branches, a large portion of Bank of America’s business applications still ran on mainframe computers. The internal electronic mail system was a mainframe application. An early use of the desktop computers, within the company, were to run terminal emulation software, to access these mainframe applications.

With the availability of desktop computer’s user-friendly interface with PC applications, there was a desire to bring that same user-friendly experience to the bank’s mainframe applications. At first we looked at screen scraping tools, such as Easel, but, in all practicality, it wasn’t much of an improvement. So, the decision was made to write a new PC-based interface to the software delivery system mainframe backend, with the goal to address operator’s complaints and streamline the process. It wouldn’t entirely replace the terminal interface, but would, in stages, replace the most frequently used functions of the application.

Previous to my undertaking of this project, someone within the department had convinced management that object-oriented programming and Smalltalk were the wave of the future. Well, he was at least right about one of them and it gave us the opportunity to followup with the recommendation to use Smalltalk for the new user interface.

Having programmed professionally with mostly mainframe languages—COBOL, PL/I, Nomad, REXX—and some PC languages—C, Pascal—this was my first introduction to object-oriented design and I took an instant liking to this new paradigm and to Smalltalk.

Smalltalk began development around 1970 at Xerox Palo Alto Research Lab and became a publicly available in 1980. Alan Kay was a key designer of Smalltalk. It reached its peak in popularity during the mid 90’s, even IBM had a Smalltalk development kit, VisualAge Smalltalk, but by the end of the decade, Smalltalk would be all but dead.

Although, there are many things that hindered its wide usage—very expensive, computer resource demanding–the last nail in the coffin was the release of Sun Microsystems’ Java language. As the popularity in Java increased, Smalltalk languished. Smalltalk makers scrambled to compete with Java, which was free. Parcplace acquired Digitalk and formed Parcplace-Digitalk. A year later they acquired Smalltalk tools and add-ons maker, ObjectShare. Some of the Smalltalk tool makers shifted from updating their Smalltalk products to offering new Java tools, in order to survive.

Those were exciting times, and when I started programming with Ruby, it reminded me of those days writing Smalltalk. I then went online to see where Smalltalk was today. I knew that there was someone who was continuing to maintain the Digitalk version of Smalltalk. I had downloaded it seven, or so, years ago and never did anything with it. There are several open-source Smalltalk projects—one of which is Squeak, which has many of the people, as developers, who were in the original Smalltalk community. There is also a huge debate about which is better Smalltalk or Ruby. I am not sure why one needs to declare one better than the other, they are both beautiful pure object-oriented languages.

Both languages were intended to be multi-platform, real-time interpretation, by running on an OS specific runtime environment or virtual machine.

Although, I didn’t start hearing about Ruby, until after the demise of Smalltalk, in the early 90’s, it has a history that goes back to 1993, with its public release in 1995. On the official Ruby site, it states this as the goal of the creator in creating Ruby.

Ruby is a language of careful balance. Its creator, Yukihiro “matz” Matsumoto, blended parts of his favorite languages (Perl, Smalltalk, Eiffel, Ada, and Lisp) to form a new language that balanced functional programming with imperative programming. ^[1]

Ruby was, in part, influenced by Smalltalk, and they, indeed, do share many similarities. One thing that stands Smalltalk and Ruby apart from other “object-oriented” languages is that all values are objects. There are no primitive data types. Data types can only be represented as objects. Therefore, you can do this to get the absolute value of a number, -2.abs, in Ruby, and -2 abs, in Smalltalk, without converting a primitive to an object. Or, as with Java’s even more obtuse implementation of passing the primitive as parameter on a function call to a utility class. This is functional implementation in object-oriented language. To get the absolute value of a number one executes the “abs()” function in the Math class, Math.abs(-2).

Both Ruby and Smalltalk have very similar block execution syntax.

10.times do | l |
  puts "Loop: #{l + 1}"
end

1 to: 10 do: [ i | i printToTranscript ]

There is one big difference between Smalltalk and other languages, even Ruby—Smalltalk is message-based. Even Alan Kay has said that the “big idea” of Smalltalk was not “objects” but “messaging,” and he has expressed chagrin in the industry’s focus on “objects” instead of “messages.” You may be asking, “Aren’t messages just functions.” In some sense this is true, but not entirely. Smalltalk does not have language constructs such as “if-then-else” or “while” or even “+.” Everything is a message, even the “+” is a message that is implemented uniquely for each class of object to which it would be sent. An example of Smalltalk messaging:

3 > 2 ifTrue: [ ^'3 is greater than 2'] ifFalse: [^'3 is not greater than 2']

First, the ‘>’ message is sent to the numeric type object passing another numeric type object. The values in these objects are compared and a boolean type object is returned, which receives the “ifTrue:ifFalse:: message, with two blocks being passed. Depending on the value in the boolean, the “ifTrue:” or “ifFalse:” block will be executed.

Instead of relying on language constructs, it is entirely implemented by methods. This makes for a very flexible and dynamic language. There are, perhaps, five reserved keywords: self, super, nil, true and false and a few language constructs: message sends, assignments (a := 2) and method returns (^value). Everything else in the language syntax is defined by messages. It is a fundamentally different way of approaching coding, if you are used to programming in object-oriented languages that have implementations that rely heavier on the functional aspects of the language, such as Java or C++. First you must know what is going to receive the action, rather than passing something into a function. This greatly moves one towards better class design and encapsulation.

Ruby is somewhere in between these two extremes. It lacks the messaging of Smalltalk and has language constructs that were incorporated by the other functional languages that also influenced Ruby, but it is a much purer and elegant implementation, than other more popular object-oriented languages.

More on the subject:
Smalltalk on Wikipedia
Squeak Smalltalk
Ruby
Ruby the Smalltalk Way
Ruby vs. Smalltalk