Mar 01 Online
Volume Number: 17 (2001)
Issue Number: 3
Column Tag: The Column Tag
MacTech Online
by Jeff Clites <online@mactech.com>
Smalltalk
I recently ran across a paper which describes a study comparing the productivity and efficiency of several programming languages. While it's difficult to draw concrete conclusions from such a comparison, the paper did make an interesting observation: programmers of scripting languages (such as Perl, Python, and Tcl) tend to use language features differently than programmers of non-scripting languages (such as C, C++, and Java). Specifically, they noted that the former group used data structures (such as arrays and dictionaries) which are built into the language, where as the latter group consistently implemented their own data structures from scratch rather than using those provided by their languages' standard libraries. This reminded me of an observation that I had made of my own programming practices - namely, that learning a new programming language influences how I program in other languages. For example, after learning Perl I tended to use associative arrays (also known as hashes, dictionaries or maps) more frequently in other languages, and implemented custom objects and data structures less often. In fact, this makes a lot of sense when you start to think about it - different languages have different design goals and cultures, and lead you to thinking about programming from different perspectives. As a developer, I view a programming language as a tool - albeit a rather important one. Like most other tools, people tend to have a favorite, but you are always better off having a variety to call upon to tackle different problems. And with programming languages in particular, I would argue that knowing a variety of languages can make you a better programmer in your language of choice.
So in the spirit of broadening our horizons, this month we are going to talk about the programming language Smalltalk. The goal here isn't to convince you to use Smalltalk for your next project, but rather to encourage you to read up on, and play with, a new language, as an incubator for new ideas and because, frankly, it's fun.
What Makes Smalltalk Special
Smalltalk has been around for quite a while, and in fact its genesis dates back to Alan Kay's Dynabook project at Xerox PARC, the same project which lead to the development of the graphical user interface (GUI). It was one of the things shown to Steve Jobs on his famous trip to the research center, and according to the story Xerox was more worried about letting Smalltalk out of the bag than they were about revealing the GUI.
Smalltalk was arguably the first pure object-oriented language; everything in Smalltalk is an object - there are no primitive types. It will look a bit familiar to Objective-C programmers - the message-passing syntax (as well as the object model) of Objective-C was based on Smalltalk, the most obvious difference being that Smalltalk does not enclose its message sends in brackets. (So, the Objective-C statement "[dog fetch:stick]" would be just "dog fetch:stick" in Smalltalk.) Smalltalk was a language ahead of its time in many ways. For instance, inherent to all Smalltalk development systems is a class browser. You've probably seen class browsers before, either in connection with Java, or in Apple's Project Builder, or in some other IDE. What sets the Smalltalk Browser apart is that all development is done there - Smalltalk source code does not live in separate text files. The plus side of this is that the programmer doesn't have to worry about how source code should be organized, or about what classes and methods live in what files - this is taken care of by the development environment, freeing the programmer of all of the mundane details. This approach also simplifies the language: for instance, there is no syntax for declaring a new class, because none is needed - you simply use the "new class" command in the browser GUI. (On the other hand, one of the down sides of this is that it is awkward to print out Smalltalk code, or to include it in email messages.)
Another seemingly strange detail you will notice is that there is no "main" entry point to a Smalltalk program, or even clear distinctions between programs. To run some code, you simply select it in the Browser and choose "do it" from the menu. This melding of the development environment into an integral part of the language may feel uncomfortable to programmers who are used to a strict separation between the two, but if you give it a chance you may find it refreshing. Although Smalltalk is not new, somehow this approach feels like progress over the predominant "programs == text" paradigm.
A must-read for anyone interested in Smalltalk is Design Principles Behind Smalltalk, a high-level overview of the philosophy behind the language, originally printed in the August 1981 edition of Byte Magazine, which marked the first public appearance of Smalltalk. A brief, no-nonsense description can also be found in the TUNES Project's Review of Existing Languages. Also, you'll want to refer to either the Google Web Directory or the Open Directory pages on Smalltalk for links to numerous other resources, and to both of the major FAQs for answers to many common questions. Finally, the online version of AOKI Atsushi's book Smalltalk Idioms is a fair-sized tutorial which has a nice introductory section to set the conceptual stage.
The Smalltalk Language and Object-Oriented Design
As I said at the beginning of this article, I see Smalltalk in part as a jumping off point to learn about object-oriented programming in general, to be applied to programming in other languages as well. And Smalltalk is the perfect playground for this. It is a pure object-oriented language - there are no primitive types, and almost everything is handled through messages sent to objects. This in itself simplifies the learning of the language, as there is a consistent semantics to all variables, a feature lacked by hybrid languages such as Java, C++, C#, and even Objective-C. (Take a look at the interesting article Primitive Types Considered Harmful on IBM's web site for a discussion of this, in the context of Java.) Continuing the same theme, Smalltalk is completely dynamically typed - variables do not have type declarations, so that all type-related information is contained in the objects themselves, and is accessed at run time rather than at compile time. Also, there are only five reserved words (self, super, nil, true, and false), and minimal syntax. In fact, there are actually no flow-control structures in the language (such as "if", "for", or "while") - flow control is also handled via messages to objects. This will seem strange to programmers of other languages, as almost every language contains the same basic branching and looping constructs (think of C, Java, Perl, and Python). Overall, the clean design of the language promotes a focus on the design of the programs you write with it, as there is minimal syntax to get in the way of learning and using the language. Although Smalltalk was originally designed to be usable by children, its simplicity makes it deep and abstract as well.
So how does Smalltalk handle situations that call for an "if" or a loop? The language has a construct called a block - some other languages, such as Perl, have similar constructs, but they are not typically used in the same manner that blocks are used in Smalltalk. A block is just, well, a block of code (enclosed in square brackets), and it can be passed as a parameter to a method just like other objects. Conceptually, passing a block to a method is like passing a function pointer in other languages, except that rather than defining a function in one place and then passing the function pointer, you just put the code right where you are going to use it. In practice, blocks are used extensively in Smalltalk (more extensively than function pointers are used in other languages). Using this construct, a loop is implemented by sending to a collection a message (usually "do:") with a block as a parameter - in effect, the message asks the collection (such as a list) to execute the block for each object the collection contains (passing each object to the block as an argument). Similarly, conditionals are implemented by sending the "ifTrue:" message to an expression which evaluates to a boolean, again passing a block as a parameter - so the "true" object knows that it should evaluate the block, and the "false" object knows that it shouldn't. The syntax (as well as the idea) takes a bit of getting used to, but in addition to simplifying the semantics of the language, this approach makes it natural for the programmer to define his own looping and conditional constructs, giving the language a great flexibility while maintaining its clarity. Take a look at the Smalltalk Industry Council's An Intro to Smalltalk for an example illustrating this syntax, as well as a brief sketch of Smalltalk's history, and UIUC's VisualWorks: Smalltalk basics page for a pithy overview of the most important and interesting features of the language.
Once you've become familiar with the basics of Smalltalk, you can move on to some of the discussions of object-oriented programming which fit naturally with the language. Topics include the concept of "super" and whether accessor methods are a good idea. On the web, three good places to start are articles on the Bytesmiths, Instantiations, and UIUC sites. You'll also find many interesting articles in the book Kent Beck's Guide to Better Smalltalk: A Sorted Collection (ISBN: 0521644372).
Squeak
Because Smalltalk blurs the lines between IDE, source code, and runtime, a Smalltalk development environment is almost like an operating system unto itself - in fact, early Smalltalk implementations ran on the bare hardware, without an operating system in between. Today, there are several Smalltalk implementations available (some commercial and some free), and each varies from the others in the details of the IDE and even the language itself. One of the more interesting environments is Squeak, a free, open-source, cross-platform, evolving Smalltalk. It is the perfect environment to play with as you begin to experiment (which does not imply that it is a "toy" implementation). Squeak actually originated at Apple, with a group of developers who wanted a non-commercial Smalltalk to use in a project they were working on - a group which in fact included Alan Kay, the driving force behind the original Smalltalk. Its development continued after some of the team moved to Disney, and Squeak is now open-source, with an active community behind it; there is even a newly published book, Squeak: Object-Oriented Design with Multimedia Applications (ISBN: 0130280283).
Part of its success undoubtedly stems from its unique openness - it is in fact open and accessible on a number of levels. First, as mentioned above, it's open-source. Secondly, it is cross platform and highly portable - one if the features of Smalltalk (and Squeak in particular) is that it defines its own notion of a GUI. Consequently, the development environment itself, as well as the programs written in it, share a unified notion of a GUI, and Squeak looks pixel-for-pixel identical on all platforms. (In case it isn't clear, the entirety of the Squeak environment is itself implemented in Squeak Smalltalk.) The upside to this is that porting the environment is simplified, and Squeak now runs on a wide range of platforms, including the Macintosh (where it was developed), Windows, various Unix platforms, and even a few PDAs. The downside is that Squeak can look, well, somewhat ugly and unsophisticated, and menus and windows in Squeak don't behave exactly the way a Macintosh user would expect. The next degree of openness of Squeak stems from its implementation: the Squeak interpreter is itself written in Smalltalk. As the story goes, the developers of Squeak, naturally, wanted to do all of their development in Smalltalk, but writing an interpreter on top of an interpreter would be unacceptably slow. So, they wrote their Smalltalk interpreter in a subset of Smalltalk, and they wrote a Smalltalk-to-C translator, also in Smalltalk. Running the translator against the source of their interpreter gave them, finally, an independent Smalltalk interpreter, written in C, but without requiring them to ever actually program in C. (Whew!) In the end, this "translation" gave their interpreter a 450-fold speed increase. You'll want to read the full story on how Squeak was bootstrapped, and on how its runtime achieves high performance, in Back to the Future: The Story of Squeak; it's actually quite clever and interesting, and a testament to what can be achieved by sticking to a good idea. The importance of this is that a competent Squeak programmer is automatically qualified to play around with the internals of the Squeak environment. Contrast this to most other languages: a Perl programmer needs to know C in order to modify the Perl interpreter, and users of compiled languages have even less access to the internals of their environment. The Squeak community as a whole is thus uniquely equipped to drive its own evolution.
For an overview of Squeak and what makes it unique, start with the Squeak Swiki. (A "wiki" is a web site where readers can contribute by adding to, and editing, the actual content.; a "swiki" is a wiki implemented in Squeak.). Of particular interest are the sections Place in the Universe and The History of Squeak, as well as the FAQ.
There are several tutorials available as well, either specifically aimed at Squeak, or written using another Smalltalk implementation but still mostly relevant. You may want to try them all as you get up and running.
For further references on Squeak, the Phaidros Software web site has collected together several pieces of documentation into an online book, and you can find links to further references in the Squeak section of the Open Directory or on the Learning to Squeak page. Also of interest will be the Squeak Smalltalk Quick Reference, which will come in handy as you begin to program. Finally, for an interesting application take a look at the Squeak Web Server, an http server implemented entirely within Squeak.
The Model-View-Controller Pattern
The UI of Squeak leads us to another recurring topic in Smalltalk - design patterns. Once again, Smalltalk's pure object orientation make it the natural forum for the discussion of design topics. One of the earliest design patterns, and possibly the most famous, is the Model-View-Controller (MVC) pattern, which originated as the paradigm for the user interface of Smalltalk programs. In brief, the MVC pattern is a strategy for separating the user interface of an application from its core logic, in part to promote code reuse and to insulate the different logical layers of an application from changes in other layers. In MVC, the Model is an object which contains the "business logic", devoid of any concept of how it might be displayed. The View implements the display of information - the actual windows and buttons of the user interface. Finally, the Controller handles user input (such as keyboard presses and mouse clicks) and triggers state changes in the Model and the View; it is where much of the code which is specific to a single application will live, and hence it tends to be the least likely to be reused in other applications. There are numerous variations on MVC, tailoring it to better fit different situations. Apple's Application Architecture documentation discusses it in connection with application design within the Cocoa frameworks. Java's Swing frameworks are also based on a variation of MVC. (See Sun's web site for more on this, in an article entitled A Swing Architecture Overview.) In truth, MVC is probably best thought of as an application of several different design patterns, and although it seems straightforward on the surface it becomes more complex and subtle as you think about it more deeply and begin to apply it in different situations, and it can serve as a practical, if not simple, introduction to the patterns literature. Squeak in particular is moving toward a different model for its GUI, called Morphic, and Squeak users will want to learn about this as well, as an alternative to MVC.
For a brief explanation of MVC and its terminology, as well as some of its shortcomings, check out Object Arts' page on the subject, and for alternative high-level descriptions see CERN's web site and Michael Callaghan's notes. If you want to delve deeper into MVC, the foundational paper How to use Model-View-Controller provides a thorough treatment. Finally, IBM's web site has an extensive example of the pattern's application in a Java program (which, to continue our theme, is informative even if you do not program in Java).
If you discover that Smalltalk's development environment is just what you have been looking for, you should take a look at ActiveDeveloper, which provides a similar environment for developing Cocoa applications, with a focus on rapid prototyping, debugging, and API exploration. Currently they do not have a version announced for the new Mac OS X, but if we are lucky they have one under development.
Enjoy your foray into Smalltalk development. It is a fascinating language, with recurring ties to Apple and the Macintosh - from the origins of the GUI at Xerox PARC, to Objective-C, to Squeak. There are many languages and development environments which are pleasant to work with, but the very culture of Smalltalk seems to be focused on fun and experimentation - it is unique and was designed from the start to genuinely be a joy to use, without compromising functionality or purity of design.
