Introduction to the Smalltalk Programming Language

A tip for learning object-oriented programming using a language best-suited for this purpose

What is Smalltalk?

Smalltalk is an object-oriented programming language with a rich history and a storied legacy. It was born at Xerox PARC in the 1970s, created by the brilliant and visionary team of Alan Kay, Dan Ingalls, and Adele Goldberg. Smalltalk was created to investigate teaching programming to children. Understandably, it's a very small and simple language, the simplest of the major programming languages.

Smalltalk is a recursion on the notion of computer itself. Instead of dividing “computer stuff” into things each less strong than the whole — like data structures, procedures, and functions which are the usual paraphernalia of programming languages — each Smalltalk object is a recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands and thousands of computers all hooked together by a very fast network.

and

Quote:

Smalltalk’s contribution is a new design paradigm — which I called object-oriented — for attacking large problems of the professional programmer, and making small ones possible for the novice user. Object-oriented design is a successful attempt to qualitatively improve the efficiency of modeling the ever more complex dynamic systems and user relationships made possible by the silicon explosion.

Here were some of Smalltalk's greatest achievements:

Smalltalk introduced the world to the language virtual machine, on which Java and Ruby are based, as well.

Smalltalk pioneered JIT (just-in-time) compilation.

From Smalltalk came the first modern IDE (integrated development environment), which included a text editor, a class browser, an object inspector, and a debugger.

Smalltalk was the first graphical language tool to support live programming and advanced debugging techniques such as on-the-fly inspection and code changes during execution in a very user-friendly format.

Since Smalltalk-80 (in 1980), it has had first-class functions and closures which, oddly enough, make Smalltalk quite good for functional programming.

Smalltalk was once a very popular language. It made its debut in August of 1981 on the cover of BYTE magazine:

Since then, Smalltalk directly inspired a generation of other OOP languages including Objective-C, Erlang, CLOS, Ruby, Python, Perl, PHP, Dart, Java, Groovy, and Scala. Apple even created a Smalltalk for the Macintosh.

Smalltalk’s popularity peaked in the 1990s when it was the most popular OOP language after C++. According to a 1995 IDC report, OOP language market shares were:

C++ — 71.3%

Smalltalk — 15.1%

Objective-C — 5.7%

Object Pascal — 4.2%

CLOS — 2.5%

Eiffel — 1.1%

all others — 0.2%

Here’s a page from Computerworld, November 6, 1995, showing Smalltalk and C++ duking it out:

Smalltalk was so good for business use that in the 1990s, IBM chose Smalltalk as the centrepiece of their VisualAge enterprise initiative to replace COBOL:

In the early 2000s, the U.S. joint military used Smalltalk to write a million-line battle simulation program called JWARS. It actually outperformed a similar simulation called STORM written in C++ by the U.S. Air Force. That by itself was an astonishing testament to the capabilities of the language.

Today, Smalltalk is still used by enterprises around the globe. Among its more prominent users are:

Just to name a few. In my home country, Smalltalk is used by Communications Security Establishment (CSE), Canada’s national cryptologic agency.

Cincom, Instantiations, and GemTalk Systems are major Smalltalk vendors.

Smalltalk is the most productive of all the major programming languages, according to this Namcook Analytics study (Table 16, measured by “economic productivity” in terms of number of work hours to deliver 1,000 function points):

Demystifying Object-Oriented Programming

Smalltalk is a Software Internet

There are only objects (objects are made from objects, the network is made from objects, etc.)

(No applications, no file system, just synergies of the virtual computers)

The language is the language of messages between objects

Some objects act as places for making combinations of objects

Objects may be viewed at a place and be integrated with each other

This idea also directly inspired the design of the Erlang language, which can rightly be called "object-oriented" according to Alan Kay's conception.

An object is very much like a computer with its own private internal state and a communications protocol. You communicate with an object by sending it messages. You ask an object to do something for you by sending it a message and it responds, just as a real computer server in a network might do. And just like in a real computer server, you are not privy to its internal state.

An object is not an Abstract Data Type

…where Abstract Data Type is a highfalutin term for a type of data structure.

OOP languages like Java and C++ are a bastardization of Alan Kay’s OOP conception. They make OOP harder than it has to be, and are an endless source of confusion for many. As Robert C. Martin says in “OOP vs FP,” objects are bags of functions, not bags of data. Objects are not data structures.

Inheritance is not mandatory in Smalltalk. You may use composition or aggregation as appropriate for your programming solution. Any hysteria over the "flaws" of inheritance is just that: hysteria...and ignorance. As a tool, inheritance is certainly applicable and appropriate in many situations, for example, GUI programming. Especially if you employ inheritance as a means of specialization and not code reuse.

Getting Started with Pharo

There are many different flavours of Smalltalk. The one I'll be discussing here is called Pharo. It's an open source variant of Smalltalk modernized for the Twenty-First Century.

The Pharo Consortium helps to make the language enterprise-ready. Some notable Consortium members are:

JPMorgan Chase, a major American banking and financial services company

Thales, a giant French engineering firm specializing in aerospace, defence and security

GemTalk Systems, a leading vendor in object-oriented DBMS

Inria, the French Institute for Research in Computer Science and Automation

ESUG (European Smalltalk User Group)

Installing Pharo

From http://pharo.org/web/download, you can find downloads for Windows, macOS, and Linux. What you are actually downloading is the Pharo Launcher, a powerful tool that allows you to create a variety of Pharo images. You can then launch any of those images as you like.

For Linux, you need to change directory to where the Pharo Launcher was downloaded to and execute the script:

cd pharo-location-folder
./pharo

You can put this into a shell script (I called mine start) and run it as a program by setting the permission (see the properties of the script file).

Launching the Pharo Image

When you start up the Pharo Launcher, you see two sections: Templates and Existing images (which is initially empty). From the Templates side, pick the latest stable official distribution (Pharo 6.1 at the time of writing). Right-click and choose “Create image”.

To launch any of the Existing images, right-click and choose “Launch”. Easy-peasy.

Getting Acquainted with the Pharo IDE

Pharo’s System Browser is the main interface to the Pharo programming system. It’s much like today’s IDEs such as Eclipse and IntelliJ IDEA, only much simpler and more elegant. To open the System Browser, left-click on open space to bring up the World menu, then select System Browser.

The System Browser consists of several panes:

the Packages pane is where you see all the logical groupings of classes

the Classes pane is where you see all the classes for a particular package

the Protocols pane is where you see the logical groupings of methods for a particular class

the Methods pane is where you see the methods for a particular protocol

the Edit pane is where you can view, edit, or create new methods and classes

the Quality Assistant pane is where you can see helpful hints and tips for whatever you are currently editing

Now, you shall create the canonical Hello World program. First, you need to create a package and class for it. You shall name the class 'Greeter' and the package ‘HelloWorld’. Edit or type the following in the Edit pane:

Now, you need to create a method or function for your Greeter class. The standard first method is ‘initialize’ which is invoked when the Greeter class is instantiated. For simplicity, skip this.

Create a method called ‘sayIt’ and print “Hello World” in this method.

Select “no messages” in the Protocols pane so that the IDE knows you are working with methods. Edit or type the following in the Edit pane:

sayIt
Transcript show: 'Hello World'

And save.

Your Hello World program prints to the Transcript (similar to a console). To open the Transcript, left-click on open space to bring up the World menu, select Tools, and then select Transcript.

Finally, to run your program, you need to open the Playground. To open the Playground, left-click on open space to bring up the World menu, then select Playground. In Playground, enter the following text:

Greeter new sayIt

Select the text, right-click and choose “Do it”. You should immediate see “Hello World” in the Transcript window.

Congratulations! You’ve created your first Pharo program.

Features and Syntax

Smalltalk's syntax is based almost entirely on message passing: sending messages to objects. Even its control structures like conditionals and loops are implemented using messages. This makes the language so simple that its complete syntax fits on a post card!

There are three kinds of messages: unary, binary, and keyword (which takes arguments). The object is specified first, followed by the message. Examples:

Date today. "unary message, which requires no other information"
1 + 3. "binary message, which sits between the receiver object and argument object"
window alert: 'hello world!'. "keyword message, which takes one or more arguments"

By the way, in Smalltalk, comments are delineated by double quotes.

The precedence rule says unary messages are performed first, then binary, then keyword. Otherwise, operations are performed from left to right. This can make arithmetic look slightly odd:

Smalltalk is dynamically typed

Smalltalk is reflective

This means that a Smalltalk program is able to inspect its own structure and computation at runtime. This confers enormous power allowing programs to extend themselves with new classes and methods or ask “who sent this message to me?”

Computational reflection is used to implement a powerful way to handle errors. When an object is sent a message it doesn’t implement, it receives a doesNotUnderstand: message, along with a reification of the original message. There are many things that the program can do with the doesNotUnderstand: message, including extending itself with new functionality!

Smalltalk is image-based

The Smalltalk image allows you to save the execution state of your program at any time and resume execution later on from exactly where you left off! This is very similar to how the system image in OS virtualization software like VMware and VirtualBox works. This is also similar to how the web browser’s DOM or Excel spreadsheet works.

Image persistence can be used as a kind of database where all the data in your program is persisted to hard drive. There’s no need to futz around with an ORM or third-party database product.

Smalltalk has a live coding IDE

You can alter your program while it's running! Live coding and debugging is a powerful way to program and is the principal reason for Smalltalk's tremendous productivity.

Smalltalk has lambdas

Summary

After two decades since Smalltalk peaked in popularity, it is high time we gave this language a second look. It's the ideal way to learn object-oriented programming. It's a fantastic way to amplify your programming productivity. And it's the most fun you can have with programming.

Comments and Discussions

I enjoyed your article very much and read the linked documentation first.
I played around with 'A Little Smalltalk' many years ago - a real system being out of the question at that time. I have VisualWorks now and have just starting experimenting with it along with Kotlin! (From one extreme to the other)

Having programmed in Smalltalk (Tektronix, Lisa, etc.) and implemented a version of it on the Z-80, I can say that Smalltalk was certainly a breath of fresh air for its time (esp. for the MVC GUI programming environment, the programming interface, etc.) -- however, it is *not* a good example of OO programming. It is also related to the actor style programming, though not the best example there either. We have leaned a lot about OO since Smalltalk (including recently when not to over-use it or use it at all, thank goodness) and almost all mainstream statically-typed languages these days have better OO support than Smalltalk. Smalltalk is also a mess when it comes to coding-in-the-large, as it uses a "patch" model of implementation override, encourages run-time state image saving/loading rather than sane module installation, allows "become:" and catch-all monkey-patching method overrides, etc. Basically Javascript or Python or Ruby give you much of the ad-hoc OO of Smalltalk -- having "everything look like a message" doesn't really amount to that much, and single-dispatch semantics and lack of static typing can make the receiver of messages count when it needn't.
Again, ST is totally cool for its time and there are still things about it that we should be trying to emulate -- it's one of the languages that everyone should have exposure to, like Lisp, FORTH, etc., but it's certainly not "best suited" for OO programming any longer.

I was introduced to Smalltalk in the late 80's as a part of learning OOP, we quickly moved to the brand new (then) C++. Since then I have moved onto C# and I continue to prefer it over all it's competitors. I can optimize well enough so far that I have not had to resort to using C++ or C.

Therefore, I agree that Smalltalk was far enough ahead of it's time to totally miss out on the reality of OOP today. Most people are using C# for OOP, there is a good reason for that, high quality compilers and debuggers, paired with a highly structured language makes it very easy to use. I recommend it to new programmers to reduce the drop-out rate I would see if I pushed them into Java or C first.

After 20 years programming for a financial project in Smalltalk and after 5 years porting Smalltalk Code to Java i love Smalltalks features, but it is a mess to refactor or to port to another language.

If you use clear visual names for properties like "name" or "length" or "size" you only can search for senders of these properties accessors. You will get a mess of senders and amess of implementers implementers. In a company with a large library you cant refactor on a secured base.

Even if Smalltalk was a breakthrough in object oriented programming languages where even classes and the development system are objects and mutable, the lack of secure refactoring is the most problematic point of using Smalltalk im my eyes.

Our company tries to leave Smalltalk but we have to implement urging features in that language, because we cant port our code fast enough.

Meanwhile we have no tools to port code from Smalltalk to Java, we cant get the old stuff automatically converted, every feature has to be ported manually.

You have no namespaces, your classnames must represent namespaces.

It was a great start, but in my eyes it ended because it is not really working in big projects.

As a language to test something to prototype something, really nice. Nice Idea to expand Objective C with Smalltalk features.

It took 8 generations of java to implement lambdas. Smalltalk started with it. But the type security is a reason to use modern lambdas not Smalltalks.

Thanks for your response. Suffice it to say, Smalltalk is not a perfect programming language. Perfection does not exist.

But I can find more things to complain about in other languages like Java, Python, JavaScript, C++, C#, and Ruby. All things considered, Smalltalk still comes up smelling like roses.

For decades, Smalltalk has been used very successfully to write large enterprise applications. I mentioned the U.S. military's JWARS program as an outstanding example. I mentioned OOCL's IRIS-2 as another.

I would use Smalltalk's lambdas over Java's any day of the week. Java's implementation is rather retarded.

Well, people can shake the air with all those "hey, we made military stuff!", but where IN REALITY you can apply ST? I didn't see even one application on ST! No editors, no file management, trading systems, accounting, painting, movies, archivers, mail, browsing... where smalltalk is? That's the point! I never believe that "language is good and strong", but... nobody uses it! ))) Even horrible Python is more usable (hey, "Mercurial"!) than Smalltalk.

Military area is the worst example of software, because it never was "fair". Do you wanna select proper language for some task - PUBLISH IT. And surprisingly NOBODY will mention sht like Smalltalk, Oberon or Ada, whatever. Language which doesn't evolve is dead. IT is too fast moving environment to allow yourself sit on the same principles. Now even Java(or better say Kotlin) has more chances to "raise" than ST.

The fact that large financial companies and military uses smalltalk is that new programs must fit their old large libraries and architectures, that cant be ported to other languages fast enough.

I mentioned this problem at our company. We still have projects realized in Smalltalk, because they base on large libraries we could not port until now.

Code analyzing and code refactoring tools are based on informations that are extractable directly from the code itself. Any lack of information there can not be an advantage of a language. If you do not need tools to analyze or automatically rewrite your code, if you never have to rename a property like 'name', if you never need to see the exact call hierarchy of a method - Smalltalk may fit your purposes.

I did not say that smalltalk is not used in big projects. I said it is not suitable for big projects. That is a difference and the reason we port to Java.

Are there any bootstrapped new projects without any history that use smalltalk?

After thinking a bit about the usage of Smalltalk today, i remembered a mathematical simulation i had programed in Smalltalk and had to port it to Java. Exact number manipulation is a true advantage of Smalltalk. If a SmallInteger Operation leaves its range, the result becomes a LargeIntger.

I remember a port from Smalltalk to Java, with a binomial tree with exponential terms, that underflew or overflew the range of doubles with hard runtime exceptions in Java but worked fine in Smalltalk. That was definitely better in Smalltalk.

Are there any bootstrapped new projects without any history that use smalltalk?

Well, I've been retired for several years, but did you know one the first if not the first real commercial effort of a pen-based tablet was the Momenta which used a modified form of Smalltalk as the device OS? This happened about the time Windows was starting to break out for the first time as a serious OS.

They added a true matrix transform based graphics spine in order to do the graphics. It used a OO business-oriented paper paradigm for the display media.

The project failed, but not for reasons that anyone generally knew about, and the failure had absolutely nothing to do with Smalltalk. The show stopper was that the idiot battery designer for the hardware designed the power supply wrong. At the time the well-known method of allowing the individual cells in lap-top batteries to be independently charged was well known, but the idiot battery designer screwed the pooch because his shrink-wrapped series-connected batteries were guaranteed to become unbalanced over time since charging one battery to be fully charged would inhibit further charging of batteries not charged yet.... over a relatively short time leakage current monotonically destroyed the battery pack balance and usage life.

Anyway, the device was actually very nice and would have been wonderful if the software had not been thrown together quite so quickly.

Using Smalltalk made the system quite powerful. I had no problem designing a widget wrapper than enabled me to drag, drop, rotate, and size text and fields for the little application I built for the Momenta. My little application allowed us to fax in any paper form using the paper paradigm, and then drag, drop, place, rotate. or size all the text and fields to exactly fit whatever we wanted on the form, and then immediately use it interactively.

What most traditional programmers don't understand that by being systematic as possible in all regards, causes great gobs of code to disappear, simply because most code that is written in a more traditional environment is there to handle unnecessary special cases. What is more, many system programmers and even Smalltalk programmers don't understand how overridingly important it is to be fastidiously systematic in order to get the real benefits of a language like Smalltalk. If one does this, then the benefits of Smalltalk will in almost every case, leave the competition in the dust.

For example, in the little app I told you about, I took it to the chief engineer of the Momenta Project, he took a look at it and noticed that what I had systematically done in the application, would very likely work on the system level. So we fired up an image and tried it, and it worked. It turned out that we could drag, drop, place, rotate or size any of the widgets that were already being used in all the system and user applications for the Momenta.

Try that in your less than Smalltalk environments and see what happens.

I agree with your key idea "ST is not suitable for large projects", but moving to Java?? Java is an old hat, which lags for years from modern approaches! And of course Java team has no resources even to be behind languages like C#. So my advice (until it's too late) move to C# (but not Core!). Nowadays C#+VS offers more than enough for "huge" development and language itself has proven features.

You know... stone and hammer also "differs not much", but for nails you prefer hammer, right? THAT's the difference - thousands small "advantages", which in common makes your life a LOT easier. Above "for", "if", "while" language consists of properties, lambdas, tuples, tens of syntactic sugars - after C# you hardly move to Java by own wish! Sorry for your company where people do not understand it.

> It was a great start, but in my eyes it ended because it is not really working in big projects.

Not really working in big projects? That would be a huge surprise to JPMorgan who developed the Kapital system, or the US military who developed JWARS, or Orient Overseas Container Lines who developed the IRIS-2 system.

I really don't understand why you're having so much difficulty refactoring Smalltalk. Smalltalk has always had excellent refactoring tools. It practically invented them! See http://wiki.c2.com/?RefactoringBrowser.

Are you using VisualWorks? A refactoring browser is built into its IDE.

We are using Visual Age Smalltalk now, before we used Visual Smalltalk Enterprises implementation both have refactoring tools, who where state of the art until refactoring became a topic in languages like Java or C#.

The usual parameter names aMemberofAGroup or aCollectionOfGroupMembers is good practice to call arguments, but which refactoring method should interprete names instead of typed informations.

If you delete a function in a class in Java that is used, you get compile errors in the interface or in every class that uses this method. In Smalltalk you get a message if no other class implements that method.

Strong type informations gives you security to delete unused functions or unused classes and the convenience in lambda expressions, that a compiler knows the types and code completion shows you which methods are available for the type.

So basically, you don't have an issue with Smalltalk. You have an issue with dynamically typed languages, since you seem to obsess over static typing. This is a completely different debate and one that is beyond the scope of this article.

There are strong advocates on both sides of the dynamic/static typing debate. This debate will likely rage on forever and won't be settled here.