Improving Smalltalk’s Image
Smalltalk has an image problem. No, not that kind of image, although Smalltalk has been fighting a bit of a PR problem for years.
No, I’m talking about Smalltalk’s concept of an application “image,” which is a file that contains both the code and the execution state of the program, including the application data (the actual objects). A Smalltalk image is not unlike the system image in OS virtualization software such as VirtualBox or VMWare. The only difference is that the “OS” is the Smalltalk system, which is not organized as files and folders, but as objects.
The Smalltalk image usually contains all the tools you need to develop your software, including a text editor, a debugger, a class browser, an object inspector, a workspace or “playground,” etc. In other words, the image contains the IDE, the same kind of IDE as Visual Studio, Eclipse, IntelliJ, and Xcode. Where it differs, however, is in the following:
- The image does not have a file explorer because Smalltalk is an object-based tool, not a file-based tool.
- Since the image contains the execution state of the program, when you exit the IDE, you can save the state (other IDEs save the state of open files only). You can then resume execution when you return to the IDE! This is incredibly powerful and convenient.
- The Smalltalk IDE directly supports “live coding,” something that other IDEs have tried to emulate to varying degrees of success. None of them, however, are as elegant as Smalltalk.
- Like the language itself, the Smalltalk IDE is incredibly clean and simple with none of the screen/menu clutter that you find in conventional IDEs. This makes it feel light and airy, freeing you from the cognitive overload of complex IDEs. My eyes glaze over every time I open Visual Studio or Xcode.
Once you’ve completed the application and you’ve thoroughly tested and debugged it, it’s easy to deploy the application. You can strip out all unnecessary classes from the image to minimize its footprint. The only requirement is to install the Smalltalk VM on the target machine so that you can execute the image. This is very similar to how Java (JVM) and JavaScript (V8) work.
The problem with the Smalltalk image is that it’s misunderstood. It’s really not that different from the usual tools most people are familiar with, unless you absolutely cannot let go of thinking in terms of files and folders. Remember, the concept of files is as ancient as the hills. It hangs around stubbornly like QWERTY keyboards and steering wheels. There have been attempts in the past to replace file systems with object-based systems (e.g., Microsoft’s WinFS and Apple/IBM’s Taligent), but the world has refused to budge. Nevertheless, there are huge benefits to thinking exclusively in terms of objects. It simplifies the development workflow. It simplifies the IDE. In conjunction with Smalltalk’s clarity and simplicity, it dramatically increases the velocity of development. This is the secret to Smalltalk’s proven productivity.
The future for the Smalltalk image is bright. There are remarkable new innovations afoot. One notable project is the Glamorous Toolkit, which I find very exciting. Despite the concept of an application image being as old as Smalltalk, it is actually still fresh and powerful, still forward-looking with respect to object orientation, ease of software creation, and future innovations.
This is a follow-on article to “Why Smalltalk Failed to Dominate the World.”
