Smalltalk – The Most Important Language You’ve Never Used

In my last two posts I mentioned two programming languages with big ideas (Modula-2 and Prolog) which, however, never ranked among the dominant mainstream languages. Now I want to look at one of the most influential languages ever created – Smalltalk.

It would be hard to overstate the influence of Smalltalk. Without Smalltalk there would have been no Mac and no Windows. In all probability you would not now have a mouse attached to your computer, networking might have come around eventually but not as quickly as it did - and object orientation might never have made it to the mainstream.

This is Smalltalk/V - a Windows based Smalltalk from the 1980s.

Then again, it could be argued that object orientation never did make it to the mainstream. Well, not the sort of beautiful, simple, elegant object orientation at the heart of Smalltalk, anyway. C++ was the first object oriented language to take OOP into the mainstream – and most OOP languages that followed appear to have built on the foundations laid by C++ rather than by Smalltalk. As Alan Kay - the ‘founding father’ of Smalltalk once said: “I invented the term 'object-oriented', and I can tell you I did not have C++ in mind".

Most of the current generation of OOP languages take some bits of Smalltalk (such as classes and methods), miss out other bits (such as data-hiding, a class-browsing IDE, image-saving, the ‘message passing’ paradigm etc.) and add on a few things of their own – such as C++’s multiple inheritance. The end result is that those languages are less simple, consistent and coherent than Smalltalk. One of the proud boasts of the developers’ of Pharo (one of the best modern Smalltalk implementations) is that the entire language syntax can be written on a postcard. Try doing that with C++!

Dolphin Smalltalk - a modern Windows-based implementation

Object Orientation in Smalltalk was an attempt to simplify programming: to make code highly modular (the programmer sent ‘messages’ to objects and it was up to the object to ‘decide’ which methods, if any, it used to respond to those messages) and more easily maintainable. In fact, most modern OOP languages have become more complex and harder to maintain.

When I read programming forums on the Internet these days, the main feature which is praised by enthusiastic programmers is the speed with which they can write programs. In fact, the more programming I do (I’ve been at it since the early ’80s), the more I become convinced that the most important thing is not the speed with which I can write programs but the speed with which I can debug them. The simpler the code, the easier it is to debug.

Debugging is  the partner to maintaining. A great many programmers now think it’s neat to contribute a ‘hack’ to some programming project then move on to something else – leaving some other sucker to try to maintain and fix the increasingly incomprehensible code at some future date. For many programmers, debugging and maintaining are not even activities which register in their minds. Quick and clever coding is all they care about. Long-term reliability isn’t. Well, frankly, you wouldn’t want the control systems of a nuclear power station written by quick-and-clever programmers!

Simplicity and maintainability were ideals that shaped Smalltalk and Modula-2. That’s why Smalltalk worked with inheritance (re-using existing features) and encapsulation. It’s why Modula-2 implemented data-hiding inside hermetically sealed modules.

But maybe the three languages that I’ve highlighted (Smalltalk, Modula-2 and Prolog) were simply too different from the languages that eventually came to dominate the world of programming. Smalltalk was perhaps too insular – there was no separation between the programing language and its environment – and its insistence on simplicity made it hard to change the language to add on significant new features. Prolog programs were too uncontrollable, with their wide-ranging searches for solutions to complex problems. Modula-2 was too restrictively ‘modular’ with its authoritarian insistence on the precise separation of one unit of code from another unit of code.

As a consequence, we now have more mundane languages such as Ruby, Python, Java, C++ and C#, which all mix-and-match ideas from earlier languages but seem to lack any single ‘great idea’ of their own. Perhaps that is what the world really wants – workaday languages that may not be perfect but at least get the job done.

Even so, I refuse to believe that they represent the face of the programming future. One day, surely, someone will have a brilliant idea (and no, I can’t even guess what that might be!) that will dramatically change the way we program. Until then, I can only wonder how different our experience of programming might have been if only Prolog, Smalltalk and Modula-2 had become the big trinity of languages instead of C, C++ and Java.