Why Smalltalk instead of Ruby
Richard Kenneth Eng
851

A point that Alan Kay has made re. Smalltalk in his retrospective paper, called “The Early History of Smalltalk,” is that while it began life as an attempt to make a programming language for children to use, after Smalltalk-76, the educational goals of the language were dropped, and Kay moved on to other things. Management of developing the language further went to Adele Goldberg. She and members of the Smalltalk development team developed it into Smalltalk-80, which is the version we know today. Kay said that they changed it to fit the goals of professionals, not children, and it’s something that he’s expressed regret about. Smalltalk-72, and Smalltalk-76 (I’m fairly sure there was a version in between) reflect the goals he had in mind for education. Smalltalk-72 had quite a different orientation re. its syntax, and the way it dealt with messages from Smalltalk-80, though ST-72 had some deficiencies that were worked out in ST-76. For example, in ST-72, classes were not obects, and could not be addressed as such.

ST-72 started out as an attempt to improve on Lisp, and if you look at some ST-72 code, it looks rather Lisp-like. He made it an iconic programming language. It kept the same idea of having a very small syntax, but most of the syntax was iconic symbols (such as an “eyeball” for beginning the process of parsing a message). Expressions looked a lot like conventional imperative programming, saying things like:

if a = b then print “Hello” else print “Bye.”

The first entity in the sentence, “if”, was the object that received the remainder as the message to itself. Another thing was there was no such thing as “new.” Objects were instantiated by merely mentioning their class name as the first thing in a sentence (“if” was a class). In processing the message, it may take parts of the message and evaluate them as-is (such as the “print” commands) so that they will execute on their own accord. This is reminiscent of how Lisp macros work. I tried my hand with ST-72 a while back, since Dan Ingalls put it on the web, and the way classes worked felt like a cross between Lisp functions and macros.

All objects parsed their own messages in ST-72, using their own internal logic for doing so. In ST-80, messages come to objects pre-parsed, and all messages use a standard syntax. The latter was partly motivated by the fact that in their studies, using earlier versions of Smalltalk with students, they observed that students had trouble passing messages to each other’s objects, because they had difficulty anticipating how their messages would be processed by the receiver. In ST-80, objects don’t parse their own messages unless you implement a doesNotUnderstand: handler for your class. Blocks were brought into the language in ST-80, and perhaps one version earlier, presumably to accommodate this new system of message passing, but I emphasize again that the educational goals were discarded, and in Kay’s opinion, ST-80 didn’t carry the “ease of use” goals that he had for children. Still, as you say, the set of reserved characters — the syntax of the language — fits on a postcard, so they are easy to remember.

I haven’t talked to Kay about this, but I suspect from how he has talked about some Smalltalk-80 code examples, what he dislikes is the rigidity in the structure of messaging. I just remember when I showed him an example of an ifTrue:ifFalse: expression once, he complained about how long of an expression it was, and perhaps the fact that one has to explicitly delimit where branching is going to take place by using blocks, when maybe that’s something that should be determined inside the receiver (as would be the case in ST-72). One of the big things in OOP is not revealing implementation in the course of computation.

Like what you read? Give Mark Miller a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.