In this series of articles, I will highlight the advantages of using Squeak/Smalltalk to develop educational software. At some point and based on my experience, I will compare with other development languages. The focus of this article is for educators and developers interested in software programming education applications. In these articles, don't expect to learn about Smalltalk/Squeak programming, my goal is simply to give an overall picture, based on real experience. Feedback is of course very welcome. In this article I will discuss about the Smalltalk image concept and its consequences.
previous article - next article
The Smalltalk image
Smalltalk comes in two pieces. A binary program specific to the host architecture and the Smalltalk codes.
The Virtual machine
The virtual machine (VM) is a program specific to a physical machine and an operating system. It is in charge of transforming the code produced by the Smalltalk compiler into native machine language, so it can be executed. The great advantage of this system is to make the Smalltalk code completely portable to any machine the virtual machine was ported to. The Smalltalk compiler produces byte code, a specific machine language to the virtual machine.
The virtual machine itself is written with Squeak and recoded in C. For access to resources local to the machine (library, hardware access) or to accelerate some critical parts of Squeak, C language plug-ins are developed for the VM.
There are three files: the
squeak.changes the and
squeak.sourcescontains the standard source code of the Squeak classes. This source is available through the Squeak development tools.
squeak.changescontains the source modifications and additions done by the user in the development environment. All user modifications in the code are immediately recorded in this file, in the form of subsequent changes. All versions are kept, so it is possible to come back to earlier code versions.
squeak.image, this file is the strangest one for people used to file based programming. This file is a dump of the virtual machine memory. It contains all the used objects of the environments at a given moment. These objects are the windows, compiled classes, running processes, loaded classes, any kind of object in memory, and even debugging sessions. It is possible to save the image through the world menu (click on the background). Therefore it is possible to save the state of the working environment, and to restore it at any time, and even restore it on a different host with a different virtual machine.
Why an educator will care about that?
The educator willing to develop educational software will gain productivity, both for writing code and porting their applications to several platforms.
Thanks to the virtual machine and
squeak.image pair, porting an application is easy and safe. To port your application, you just need to make your
squeak.image file available to the target host.
If you developed your application on host A, you were using a virtual machine for host A and you were using your standard
squeak.image (or maybe your renamed it
MyGreatApplication.image. To port to host B, you just need to pack virtual machine B with your
MyGreatApplication.image image file, and that's it.
From the working environment, the developer can save at any moment the state of their work:
- They can use a tool called the workspace to write down code snippets to remember specific code examples, or to instantiate quickly objects. I very often use this to write down specific sequences of code or notes. To execute this code, I select it then type Alt+d (or Alt+p to get a printed result). When I save my image, the workspace and its content is saved as well. In the right bottom of the picture below, you can see a workspace with some snipped code I used while developing DrGeoII.
- When debugging an application, the working environment can be saved with the opened debugger. The picture below shows a working environment where I introduced a bug in DrGeoII, the debugger is opened, When I saved the environment (therefore, a memory dump in the image file), the debugging session is saved as well.
When you are writing code, and especially while improving the quality of your software, your are working within a specific context of your software. The bug does not show up immediately after you start your application. You need it to be in a given state after you performed a series of interactions with it. It can be very time consuming to do so.
Now I guess you start to understand how Squeak can save you a lot of time when you are improving the quality of your application:
- You can save in the image the specific context which lead to bugs in your application and you can decide to come back quickly to this context as often as you need it to fix the bugs. It is a big time saver.
- While your application is running you can fix your code, you don't need to restart your application (and recover from the bug context). This an additional time saver.
Don't search for these features in other languages, you won't find them.
In the next article about the IDE, I will develop some of the concepts presented here, for example the debugger and the possibility to fix code in running applications.