A Sobre Reflection

I saw this at c2.com:

Why Is Smalltalk Dead

(Author unknown)

Smalltalk Died because Of Greed, Speed, Mis-Development, and Hype.

Adele Goldberg’s greed killed it early on three ways: 1) High licensing fees in thousands of dollars contrasting Microsoft’s $100 market. 2) Profit share fees — attempted to get a share of a company’s benefit from using Smalltalk. 3) Stopping development by other licensees such as Tektronix. These items resulted in diverse competitors such as Digitalk, Apple, etc. causing incompatibilities instead of a strong unified language, eventually resulting in other languages such as C++ adopting objects.

Speed was always a problem because it is an interpreted language instead of a compiled language — everything that isn’t in the Virtual Machine is evaluated during execution. Early pauses for garbage collection were annoying. A painfully slow example was Digitalk’s Goodies code to train Neural Networks. As a rule of thumb, applications that can tolerate relative slowness are those where the human doesn’t use it rapidly. A bank teller’s terminal is used more slowly than an insurance claim operator’s faster data entry to get through many claims per hour. Real-time applications require more speed — a self-driving car is likely to crash with a 100 millisecond delay at the wrong time. Thus Python’s ability to disable garbage collection can make it a safer choice.

Mis-Development has been a plague on Smalltalk’s usability. The earliest item is calling a bit copy function a bit block transfer. There is no good reason to make things that much harder to understand, especially when you’re trying for self-documenting code. A big misstep was Smalltalk’s early inability to deliver working applications for sale by developers — one had to sell a Smalltalk platform along with the application, leaving little profit. Another misstep was the Patterns fad. Many books were written pretending to show the form of best practices in writing algorithms with zero algorithm content, making them unusable by programmers who need algorithms. Had the efforts of these misguided authors gone into making advanced application libraries as one finds by searching “Free Open Source” which finds projects like OpenCV and Tesseract, Smalltalk would not be so dead. A similar fad was pursued by people trying to make object analysis a more complicated “paradigm” even in the name of simplicity. CRC cards became another excuse to keep ideas on paper instead of writing Smalltalk code. Contrasting these mis-Developments is the development of languages which focus more on practical usable objects which make real work go faster and easier for programmers.

A motivation for mis-development is Smalltalk idolatry, putting Smalltalk on a balloon instead of on the ground where people live. The thought that Smalltalk was in itself the next big thing instead of applications that people use. For example, web browsers are probably the single most used computer program — yet Smalltalk doesn’t have a built in browser that most newbies can find. List all the other programs people use or want to use from a sound recorder to Pixar quality animation and Smalltalk may have tools to build it but Smalltalk doesn’t come with built-in highly useful applications beyond demonstration toys that go nowhere. Nor is there much of an external library. You can find lots of free open source software in C++ that does useful things but you can’t even buy a library of Smalltalk goodies that will get you far toward your goal — the demo apps remind me of a math teacher’s statement that in the USA roads are mostly all connected, they go somewhere — but in Russia most of them are dead ends. Smalltalk’s core may have been connected internally but applications suffer the lack of a unifying vision. The original vision of Smalltalk as a replacement for the operating system got lost. You could only address 2GB files, not 2TB files and many other peripherals were unsupported. Some versions had lack of attention to keeping things simple.

A more recent path of mis-development has been attempts to make Smalltalk tools for kids such as Etoys to try to hook them at an early age on a platform that has not adequately kept up with state-of-the-art application development, failing to make it easy to control hardware so it could have been used for microprocessor work, and failing to include it in educational projects like Raspberry Pi. To be useful a tool must continue extending the state of the art instead of doing it once.

Reduced Hype, i.e., social death is a natural consequence of all these problems but it must be mentioned in light of Sun’s super star burst hype promoting Java as the best computer language ever. Although Sun died, the hype did get Java into many places Smalltalk should have been in. Had anyone bothered to rewrite Smalltalk from an interpreted language into a compiled language then counter advertised that Smalltalk was the best, it might have regained market momentum. Of course there is lots of false hype such as promoting the need for profiling before deciding on another language in a real-time application like self-driving vehicles where simple math proves Smalltalk is literally deadly.

There are several interesting things still going on in Smalltalk and derivatives but some see Smalltalk as a place to develop thought objects into new stand alone languages such as Scratch. Smalltalk needs a new vision that includes full support of all peripheral hardware and applications that sell computers with simplicity so kids can use all of it plus speed that makes it safe for real time. If anyone wants to revive Smalltalk, start looking at what cutting-edge scientists use for Artificial Intelligence such as Scala, R, Hadoop, and how people are extending Smalltalk to develop a free clean powerful do-all language.


The Author mentions having a web browser (and other kinds of applications) within the Smalltalk environment, which predated the web by more than a decade. This is only reasonable if you had intended for Smalltalk to be a replacement operating system. Perhaps this was a possibility 35 years ago, but today it’s not. Today, Smalltalk is simply a development tool hosted on Linux, macOS, or Windows, all of which provide web browsers such as Firefox, Safari, Chrome, and Internet Explorer.

CRC cards became another excuse to keep ideas on paper instead of writing Smalltalk code.

CRC cards were an aid for helping you design OO software. They weren’t particular to Smalltalk and they didn’t make OOD more complicated. I’m reading a book by Chamond Liu called “Smalltalk, Objects, and Design” which deals with this very subject and it’s very clarifying. I highly recommend the book.

Had anyone bothered to rewrite Smalltalk from an interpreted language into a compiled language then counter advertised that Smalltalk was the best, it might have regained market momentum.

Being able to compile Smalltalk is irrelevant. Both Java and Smalltalk run on bytecodes in a virtual machine. In principle, Smalltalk can execute just as quickly as Java, though admittedly the JVM is extremely well-optimized for performance.

Of course there is lots of false hype such as promoting the need for profiling before deciding on another language in a real-time application like self-driving vehicles where simple math proves Smalltalk is literally deadly.

Smalltalk was never designed for real-time application. Nevertheless, it can be used in embedded and IoT devices. Interfacing to C/C++ from other languages is a common practice.

Today, Smalltalk can be used for microprocessor work and, in fact, is available for the Raspberry Pi.

I agree that Etoys was a bit of a distraction for educational purposes. Today, we encourage beginners to learn Smalltalk directly, and there are plenty of excellent online resources for doing so.

The Author otherwise provides a good historical synopsis and makes many valid points. I am sanguine about using Smalltalk for Artificial Intelligence (or machine learning) work, and I hope to see progress in this area in the near future.