The Smalltalk programming language


Not the kind of smalltalk you hear at a cocktail party, Smalltalk is the second-oldest object-oriented programming language. The oldest is Simula-67, developed by Norwegian computer scientists Kristen Nygaard and Ole-Johan Dahl in the early 1960s. Simula was one of the inspirations for Smalltalk, and it also inspired Bjarne Stroustrup to develop C++. Smalltalk was developed during the early 1970s by a research group at Xerox PARC that included Alan Kay, Dan Ingalls, Dave Robson, Adele Goldberg, Dan Ingalls, Peter Deutsch and others.

In the early 1980s, Xerox decided to commercialize Smalltalk, and released code for Smalltalk-80 (release names indicated the year of release) to various companies on an experimental basis. The companies included Hewlett-Packard, which produced the first true commercial Smalltalk. At about the same time, Byte magazine devoted an entire issue to Smalltalk (August, 1981). The cover illustration for that issue was the origin of the baloon logo that is now associated with many Smalltalk products.

Later, Xerox itself formed a subsidiary, ParcPlace, which released a commercial Smalltalk called VisualWorks. ParcPlace no longer exists, but VisualWorks is still alive and well, developed and marketed by Cincom.

Meanwhile, a startup company called Digitalk released a text and menu based Smalltalk called Methods in the mid-1980s, and a full graphical version for MS-DOS called Smalltalk/V in 1987. Given its cost of 99 US dollars, Smalltalk/V did a lot to popularize Smalltalk. In the next several years, Digitalk and ParcPlace released versions for platforms including Unix, Windows, and OS/2, incorporating class libraries for database access, networking, and many other "industrial strength" features. Coupled with Smalltalk's already-strong reputation for rapid development and GUI tools, that made it ideal for developing enterprise-wide client/server applications.

In the mid to late 90s, Smalltalk (along with C++, and all other object languages) was eclipsed by Java, at least in terms of market penetration . Smalltalk is still a viable language, however, with several commercial implementations, and continues to be used in significant applications. An ANSI standard for Smalltalk was finalized in 1998. The latest incarnation of Smalltalk is an implementation called SmallScript, which is aimed at today's dynamic development environment; it can run as a scripting language, and operates as part of Microsoft's .NET platform.


Why use Smalltalk, and how can I try it out?

Smalltalk is the most mature object-oriented language on the market. Most other OO language implementations, ranging from Object COBOL to Java, have drawn inspiration from Smalltalk. (If you're not already familiar with what object-orientation means, see the OO page for a basic tutorial.)

One of the distinctive features of Smalltalk (versus, say, Java) is that it does not require type specifications for variables and arguments. If you look at a typical Java or C++ program listing, you'll see that a great deal of space is taken up by type definitions, and related stuff such as casting (which is required, for example, to use Java collection classes). Some people argue that strong typing makes programs more reliable. Most Smalltalkers believe that the visual clutter necessitated by strong typing, and the fact that it complicates the language syntax, more than offset its advantages. In Smalltalk, the programmer just focuses on the semantics of the problem, writes simpler code faster, and has more time left for user feedback and testing.

Smalltalk development environments have always focused on making the programmer as productive as possible by providing a completely integrated set of editing, code management, and debugging tools; they are still the premier examples. The browser-based IDEs that C++ and Java programmers first began to see in the mid-1990s were based on Smalltalk environments that had been around for more than 20 years.

Programming language discussions often take on the character of religious and political arguments, and I don't want to start one here. The best way to find out whether any particular language is any good, and whether it fits your own cognitive style, is to try it out. Fortunately, that's easy to do with Smalltalk; there are excellent free versions available for most platforms, and the simplicity of the language syntax makes it easy to learn enough to be productive.


Cover of August '81 Byte

Smalltalk goes mainstream:
August, 1981 issue of Byte magazine.















Cover of Chamond's book

Chamond Liu's Smalltalk book

The best book you can get on Smalltalk (or on object-oriented design and programming in general) is Smalltalk, Objects, and Design, written by my friend Chamond Liu. (You can find out more about the book from Amazon.com.)

There are other books and links to various online tutorials on Smalltalk listed in the Links section, below. There is also a brief Smalltalk tutorial on this page.


Links

Links to sources of free Smalltalk

The most active free Smalltalk effort going on is Squeak, originally developed at Apple by Alan Kay and others, now a freestanding open-source project. Ports have been done to many platforms. (The Squeak.org server is often overloaded; if so, try the UCSB/CREATE Squeak page.)

Cincom (through a series of acquisitions) now owns and actively develops the VisualWorks Smalltalk originally produced by ParcPlace. A CD image for their current product set is free for non-commercial use. (The CD image is huge. Go here to download just the Smalltalk files in smaller chunks.) VisualWorks runs on Microsoft Windows, and on most Unix and Linux systems.

At one time ObjectShare, one of the successor companies to ParcPlace-Digitalk, released the 16-bit Windows version of Smalltalk/V for free, under the name Smalltalk Express. It also included a free version of their WindowBuilder product. Smalltalk Express still runs fine on Windows 2000 and XP, but the original download site is gone. You can still find it on the Web though, for example at the University of Helsinki.

You can also get free "try and buy" or beta editions of IBM VisualAge Smalltalk from IBM (runs on many platforms) or Dolphin Smalltalk (runs only on Windows) from Object Arts.

Links to general Smalltalk information


A brief Smalltalk tutorial

This tutorial can be short because the Smalltalk language is very simple and consistent. According to adherents, this is a source of power: If a good programmer writes a complicated program, it's complicated because of what it does, not because of language syntax.

Smalltalk is based entirely on sending messages to objects. In response to every message, some object is returned (often, the returned object is the one to which the message was sent). Every statement has one of three forms:

1. anObject aMessage.

2. anObject firstMessage;
            secondMessage;
            lastMessage.

3. variableName := anObject aMessage.

In (2), semicolons separate a series of messages to the same object. Statements are terminated with periods. (3) is the same as (1), except that the object returned from sending the message is assigned to a variable so it can be used later. Here are examples of these three forms:

aSavingsAccount balance.
aSavingsAccount deposit: 200;
                withDraw: 100;
                balance.
mySavingsAccount := SavingsAccount new.

In the last statement, the object receiving the message is a class. The messages new and balance are unary; that is, they have no arguments. deposit: and withdraw: are keyword messages, taking the numbers 200 and 100 as their arguments. Keyword messages can have any number of arguments:

mySavingsAccount initializeBalance: 100 name: 'Dave Collins'.

Note that this example does not show two messages; it is one message with two keywords and two arguments (the number of arguments always matches the number of keywords, and each argument is preceded by a colon.) The message name is initializeBalance:name:, and its arguments are 100 and 'Dave Collins'. Though the syntax is different, semantically this is the same as a function call with multiple arguments in other languages; for example, in C++, it would be something like

mySavingsAccount.initializeBalanceAndName(100, "Dave Collins").

There is an important difference between

SavingsAccount new initializeBalance: 100 name: 'Dave Collins'.

and the message series in (2) above, even though in both cases multiple messages are sent (in this example two messages are sent, new and initializeBalance:name:). Here the two messages are not going to the same object. new is sent to the class SavingsAccount. initializeBalance:name: is sent to the object that is returned by the expression SavingsAccount new, which is a new instance of SavingsAccount. Parenthesizing the expression may make this clearer:

(SavingsAccount new) initializeBalance: 100 name: 'Dave Collins'

Smalltalk has one other type of message, the binary. Binary messages are named with special characters, are infix operators, and take a single argument. Their purpose is mainly to provide syntactic compatibility with other languages for common operations such as +, *, <, and so forth. An example is

x := 1 + 5

where the object 1 is sent the message +, with the argument 5. Note that even though this looks similar to the use of the + operator in other languages, in Smalltalk there is an asymmetry: The left-hand operand (1 in this case) is the receiver of the message +, and the right-hand operand is an argument to the message. In this particular case, there's really no difference; both

x := 1 + 5

and

x := 5 + 1

produce exactly the same result: x gets the value 6. In general, though, this may not be the case. Messages often have side-effects on the receiver, in which case an apparently symmetrical expression may have a different result, depending on which object is the receiver.

One of the reasons for the simplicity of the Smalltalk language is that control structures, such as conditional execution, are defined as messages to objects. In

(anInteger > 10)
        ifTrue: [ "code for true case" . . . ]
        ifFalse: [ "code for false case" . . . ].

the expression (anInteger > 10) evaluates to a Boolean object, which receives the message ifTrue:ifFalse:. There are two booleans in Smalltalk (instances of the class Boolean), true and false; true responds to ifTrue:ifFalse: with the result of executing the "true" block; false responds with the result from the "false" block. The use of square brackets is a bit of syntactic sugaring; code blocks, like everything else in Smalltalk, are objects (instances of the class Block, similar to the closure in LISP).

Under the covers, a class looks like a data structure definition representing the state that an instance of the class can hold, plus a collection of functions that implement the messages it can respond to. Each data item in the structure is one piece of state held by the object; these data items are called instance variables. Each function takes all the parameters of its corresponding message, plus one extra "hidden" parameter: the particular object the message is being sent to.

This implementation is not visible to the programmer defining classes and writing methods; he or she sees a simpler model. Classes in Smalltalk are defined as in the following example:

BankAccount subclass: #SavingsAccount
            instanceVariableNames: 'balance name'

This says that SavingsAccount is a subclass of BankAccount, with instance variables (data) named balance and name. The # indicates that #SavingsAccount is just a symbol at this point, since it is being defined in this statement. Notice that this is just like any other Smalltalk expression; it is a message to the object BankAccount, telling it to add a subclass named SavingsAccount.

The behavior of objects is defined by methods associated with their classes. Each message has a corresponding method, for example:

initializeBalance: anInteger name: aString
   "Set the balance and account name."
      balance := aninteger.
      name := aString.
      ^self

balance
   "Answer the account balance."
      ^balance

The caret (^) exits the method and returns a result to the message sender. The keyword self means "this object," the receiver of the message. The default object returned is self, so it is not really necessary to specify it. The explicit return is required in the balance method.

The convention for indicating which class a method belongs to is >>, as in BankAccount>>balance. (>> is actually a Smalltalk message that can be sent to a class, which returns the code for the named method.)

In typical Smalltalk systems, the entry and compilation of code for methods is done through an interactive code browser.

You have probably noticed that there are no type declarations in Smalltalk, such as integer, character, etc. Argument names, such as anInteger, are suggestive but not enforced. Type errors are manifested at run time when an object of the wrong type does not understand a message that is sent to it.

Something else that Smalltalk does not have is storage allocation. Storage is dynamically allocated when an object is created and deallocated by a garbage collector when all references to the object have been deleted.

If this brief discussion whetted your appetite, see the links above to sources of free Smalltalk implementations. Download one, and have fun!

For a comparison of corresponding terms and concepts in in Smalltalk, C++, and Java, and pointers to information about other OOPLs, see the OOPL comparison chart.