Smalltalk: Requiem or Resurgence?

Four Rules of the language are defined with this vocabulary:

1. Everything is an object.
2. All objects are instances of some class.
3. Objects get things done by sending messages.
4. Messages are implemented by methods.

This sounds trivial until one realizes that...that really is all there is to know to start using Smalltalk. Want to create a new object? Send the new message to your Object's class. Need to add 2 and 2? Send the + message to the 2 object (an instance of the class Integer) with an argument of 2.

Want to define a new class? Send the subclass:instanceVariableNames:classVariableNames: message to its future superclass object. As you delve more deeply into your Smalltalk code browser, the magic continues to unfold before your eyes. With very few exceptions, The entire Smalltalk system and set of libraries is built with this vocabulary. Object, Collection, Number, Class, Method, Process, Context... all are classes within the system, defined in terms of one another. At once, they all exist in a live execution context, the behavior of which can be changed on the fly by simply sending messages to objects in the system. We start a Java program, whereas we modify a Smalltalk system.

All this is a bit of brain twister for the uninitiated. We first begin to understand that we're dealing with a novel environment, however, when we write the canonical "Hello World" program in Smalltalk:

'Hello World'

That's not a snippet — that's the program. Both syntactically legal and complete, this code can be displayed, inspected, or executed directly within the live Smalltalk environment. How very Zen.

Here's a program to calculate the factorial of 10000:

10000 factorial

Verbosity aside, attempting this in another language would probably cause more than a slight hiccup. In Smalltalk you simply browse the result. Sending the factorial message to the SmallInteger "10000" results in a LargePositiveInteger object which I won't replicate here. Just inspect it for yourself!

A line of code that stops execution and opens up a debugger halted at that point:

self halt

Smalltalk's weak type system also lets us think about some problems a bit more naturally. Heeg elaborated an example in which the hand of a boy is used to both draw things and to pull things.

As such, a boy may have an instance variable "hand," which might be used as follows:

declaration:
	hand

	hand := Mommy getPen.
	hand draw.
	...
	hand := Daddy getWagon.
	hand pull.

where in Java:

declaration:
	private Object hand 

	hand = Mommy.getPen();
	((Pen) hand).draw();
	...
	hand == Daddy.getWagon();
	((Wagon) hand).pull().

Though some might find it unnatural to relate a pen and a wagon through their use in a boy's hand, others might find that this makes perfect sense. We note that there is no single correct way to conceptualize and model a system, and that it's nice when the modeling tool can support one's conception.

Above, Java programmers revel in the added security of compile-time checking: "No runtime 'messageNotUnderstood:' stack traces" they say. Smalltalkers bristle at all the extra parentheses, downcasting, and verification when this code eventually needs to be changed. "Where did my smile go?" they ask. We won't try to solve the strong/weak typing argument here, but can note that Smalltalk seems to allow more expressiveness to the developer, where Java has a somewhat more defensive, practical bent.