Smalltalk: Requiem or Resurgence?

The grandaddy of the object-oriented world, Smalltalk has fascinated developers since it appeared on the programming scene. Is Smalltalk now in resurgence?


May 11, 2006
URL:http://www.drdobbs.com/parallel/smalltalk-requiem-or-resurgence/187200914

The August 1978 issue of BYTE magazine had a language feature that included a small picture of the "Land Of Small Talk," perched on a tower amid Fortran Ocean, to the south of Pascal's Triangle, North of Lisp Jungle, and East of the Basic Sea. The following text, associated with a description of the language, uncannily describes the state of Smalltalk both past and present.

"Traveling upward through heavy seas, we come to pinnacle, a snow white island rising like an ivory tower out of the surrounding shark infested waters. Here we find the fantastic kingdom of Smalltalk, where great and magical things happen. But alas...the craggy aloofness of the kingdom of Smalltalk keeps it out of the mainstream of things."

— Carl Helmers, BYTE Magazine, August 1978.

At the recent Smalltalk Solutions Conference, Georg Heeg organized a talk around what he termed "The Smalltalk Paradox," as enumerated in the quotation above. Nostalgic as always for the full-force return of Smalltalk to the fore of modern object-oriented software development, I listened attentively.

He began with a short history of the language. Object-oriented theories such as encapsulation and dynamic dispatch first came to the fore in 1976, which coincided with the first modern implementation of Smalltalk — Smalltalk-76. A series of 11 articles about Smalltalk were published in BYTE in 1981.

However, it was the landmark publication of Smalltalk-80: The Language and its Implementation by Adele Goldberg and David Robson in 1983 — and the subsequent release of the Digitalk graphical Smalltalk environment in the same year — that heralded the beginning of an illustrious history of mainstream Smalltalk development. The ParcPlace, VisualAge, and Dolphin implementations followed on in 1988, 1994, and 1996, respectively. For perspective, the first two editions of the Kernighan and Ritchie bible The C Programming Language, appeared in 1978 and 1988.

Heeg described what he considers the three main time periods of Smalltalk in industry:

Though I can't confirm the resurgence, I can attest to the timing and content of the first two periods (I concede that my relative distance from the community over the last seven years or so may be the reason). Still, I've yet to detect an appetite for Smalltalk from any of our company's customer requests, most of whom have standardized on Java for the enterprise.

Functional and logical languages have their basis in mathematics, a science far more adept at modeling static systems than dynamic ones. Heeg contends that these kinds of languages lack the ability to model time, and must undergo awkward machinations to allow the systems built with them to change through time (this seems similar to the pain one experiences when modeling time in relational databases — an area of research also steeped in mathematics). He likens traditional, functional languages to a pair of polarizing lenses, in which the model for real-world phenomena are first separated into their constituent states and processes, programmed, compiled, and (re)linked by a linker to create the program. By contrast, object-oriented languages make it much easier to build dynamic systems, because they map concepts much more directly into software. There is a one-to-one mapping between the model (Class) and the phenomena being modelled. Instead of "programming," you simply "model."

The grandaddy of the object-oriented world, Smalltalk has fascinated developers since it appeared on the programming scene. I was inducted in 1988, having succeeded in creating a small visual mapping application in about two weeks (my previous feats had included programs marginally more complex than those of the "10 print 'hello'; 20 goto 10" variety). I was hooked. Though I'd just graduated from Biology, I signed up for a four-year compsci degree at Carleton University, a hotbed for Smalltalk education at the time.

That Smalltalk is an object-oriented language, however, doesn't really explain why it might be a better choice than other OO languages like C# or Java, and if so superior, why it has been supplanted by them as a language of choice for the enterprise in the last 10 years. This is the essence of the Smalltalk Paradox.

Heeg had some good answers for the first question. He began with solid material: a quote from the Goldberg/Robson Smalltalk bible:

"Smalltalk is based on a small number of concepts, but defined by unusual terminology. Due to the uniformity with which the object-message orientation is carried out in the system, there are very few new programming concepts to learn in order to understand Smalltalk...These concepts are presented by defining the five words...that make up the vocabulary of Smalltalk — object, message, class, instance, and method. These five words are defined in terms of each other, so it is almost as though the reader must know everything before knowing anything."

— Goldberg and Robson, Smalltalk-80: The Language and its Implementation, 1983.

In other words, the internal consistency of the language is at once beautiful and somewhat unsettling. As such, developers may find the concepts difficult to relate it to something else they already know.

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.

Programs like these (and the environment itself) are part of the reason Heeg waxes poetic, asserting that Smalltalk is a "vision of the ways people might effectively and joyfully use computing power" and further that "Smalltalk is an addiction. There is Joy associated with Smalltalk programming." Only programmers can understand comments like these. Having worked with Smalltalk, I do. I can also attest to the power of the environment- — full dynamic polymorphism on the class side; portable parameterized blocks; a rich collections hierarchy; extensive standard (cross-vendor) class libraries; the list goes on.

So Smalltalk must be incredibly popular, right? I don't know how many people will attend the 2006 JavaOne conference this year, but I would guess it will be in the high thousands. By comparison, I'd hazard that less than 200 attended the Smalltalk track at the Smalltalk Solutions/Linux World conference. Why? I believe the answer comes down to outreach.

First, universities tend not focus on Smalltalk-based curricula. Though Smalltalk is an excellent system for teaching OO concepts, its relative obscurity in industry may drive course developers to go with more prevalent alternatives in order to attract enrollment. Though one might argue that universities shouldn't have to worry about these things, one might also be wrong.

Let's say you've been able to surmount that hurdle and have managed to become a Smalltalk convert all on your own. You've spelunked around with the code browser and have become enamored with the power of the language and the overall system. Do you then make an honest effort to turn someone else on? Generalizing heavily, I've noticed that many Smalltalk developers carry a larger-than-life chip on their shoulders with respect to the superiority of the language over any possible alternative. In addition, they become defensive at discussing things that Smalltalk is perhaps not as good at (they may even tell you there is no such thing).

For example, Java came to prevalence when applets started appearing on the web. The Java VM alowed the loading of classes over the network, on an as-needed basis. There was thus a mechanism built into the virtual machine to discover and load only those classes that happened to be used by that instance of the application. By comparison, the Smalltalk image is monolithic (it is noteworthy that most running Smalltalk processes will fit in less memory than an equivalent Java process, but at the very least it is a valid point of discussion). There are other examples, of course.

The seeming inability of some developers (Smalltalk or otherwise) who really love some construct is to assume a defensive posture about any and everything associated with it — more than a bit of a turn-off for would-be converts. In the Smalltalk world, instead of focusing on the features of the system that attracted them in the first place, engaging in measured envangelism, and spreading the word by example, developers almost seem to berate those who haven't yet discovered it, e.g. "You've never tried Smalltalk? Then you've never programmed!" This is geekdom at its worst. To the listener, attitudes like this beg the question "If it's so great, why aren't more people using it?", which of course quickly descends into a circular conversation.

Another major reason is surely that Smalltalk has never had a large industry backer to provide the marketing might required to bring the language to the mainstream. Sun sure knew how to reach out: by engaging big-name vendors such as IBM, Microsoft, Netscape, and BEA to implement their specifications; by giving developers access to a general-purpose language for executing programs in a web page; by providing a familiar syntax for C++ developers to get their feet wet with easy call-by-reference, garbage collection, platform independence, socket programming; and by marketing, marketing, marketing. Java has enjoyed a gargantuan marketing effort headed up by Sun, who positioned itself as a leader in open-source development (or if not open source, at least "free"). They were the mighty mouse in opposition to evil Redmond empire, and they were fairly successful at it. A huge number of third-party libraries, middleware products, and frameworks sprung up from the mainstream as a result. Ironically, it's precisely this mainstream bloat that makes Java development today so cumbersome.

Smalltalk has never had such a partner. It looked like IBM might provide the required muscle when they purchased Object Technologies Incorporated, a company who had developed the industry-leading Envy Smalltalk suite of tools. IBM still supports Visual Age today, but they haven't exactly been the rabid envangelists that Sun is for Java. Perhaps they realize that they can make just as much money implementing Java middleware on AIX or Linux as they can with Smalltalk middleware.

At the Heeg talk, a rep from Cincom systems (purveyors of the VisualWorks Smalltalk suite of tools) pointed out that the community will see a much bigger marketing push from Cincom for the Smalltalk Solutions conference next year. I think the conference organizers have made a great move by aligning themselves with Linux World conference. The Smalltalk community needs to attract outsiders and start talking about how they can work together. The Open Source/Community Development/Linux communities worldwide are teeming with energy; becoming a part of one or more standard Linux distributions (I hear Ubuntu is already participating) will definitely increase penetration.

Other bandwagons that might provide some sheen — "Simplifed Web Development"? AJAX? RIA? All are hot today. At the conference, I learned of a community who is building a Web application framework called "Seaside" for Squeak (an open source implementation of Smalltalk) at the conference. As we speak, they are feverishly implementing support for Scriptaculous — an open-source library which promises to help developers implement dynamic user interfaces using AJAX and DHTML. This is the kind of outreach the community needs to overcome their own "craggy aloofness". The major Smalltalk vendors might do well to host a Smalltalk development competition. Add a few iPods and Playstations to the mix and I might even enter. Perhaps they might throw their hats into the "Pet Store" wars and show just how consistent, elegant, and nimble they can be in comparison to their competition. I'll know they've succeeded when my clients start asking "So I've been hearing that Smalltalk might be an option as a development language for us. Do you know anything about it?" I'll have a lot to say to them at that point.


Jeremy Chan is a Principal Consultant at the Jonah Group and a Technical Architect with over 10 years of experience in object-oriented software engineering.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.