One of the more interesting things I have been playing with recently is Pharo, a modern descendent of Smalltalk. This is a summary of my first impressions after using it on a small (and unfinished) project, for which it might actually turn out to be very helpful.
The first time I read about Smalltalk was in the August 1981 issue of Byte magazine. Back then, I was a high school student and I had just invested my savings into my first home computer with characteristics typical for the time: Z80 processor, 16 KB of memory, Microsoft Basic, data storage on cassette tapes. From that perspective, Smalltalk was a utopia. The revolutionary aspect of Smalltalk was its design as an integrated computing system that combined a language, a huge standard library, a development environment, and perhaps most of all a graphical user interface (GUI), which in fact was the ancestor of all of today’s desktop-style GUIs. As a consequence, it required a high-quality graphics display, a mouse, and plenty of CPU power. None of that was available in commodity hardware.
In 1995, a friend passed me a floppy disk with Smalltalk–80 for the Atari ST family, and I could finally lay my hands on a working Smalltalk system. By then I had an Atari TT with the awesome big high-resolution black-and-white screen that was available for it. Just perfect for Smalltalk. I was very impressed by the system, which in many respects was superior to the Atari’s native TOS/GEM combo, and even to the Unix workstations I had in the lab. But I couldn’t actually use it for anything productive, because Smalltalk lived in a separate universe, unable to access any file on my hard disk. It wasn’t more than an impressive demo of what computing could be like.
I have faint memories of playing with Squeak a couple of years later, but I found its flashy colors and toy-inspired aesthetics so unpleasant that I didn’t go very far. Pharo is actually a fork of Squeak that evolved into a different direction, with a more sober design that is much more to my liking. More importantly, some of the on-going developments in the Pharo community (in particular the Glamorous Toolkit) are much in line with my recent interest in the human-computer interface of computational science. The 2018 session of the Pharo MOOC was thus a good occasion to take a more serious look at this up-to-date incarnation of Smalltalk. The MOOC does a pretty good job at introducing Pharo to people with various interests, and it even includes some explanations of the internal workings of Pharo (look for the “black magic” label).
As a language, Smalltalk was revolutionary in the 1980s, but no longer today because many now better known languages have drawn on it for inspiration. If you know Python, for example, then Pharo won’t surprise you much beyond the obvious and important syntactical differences. On the plus side, that means it is not much effort to do a first project in Pharo when coming from a Python background. But it also means that there isn’t much to be gained from learning Pharo if you look at it as just another programming language. The really interesting part is not the language, but the user interface of Pharo the computing platform.
Pharo belongs to a rare species of computing environments that I think is best described by the label “explorable”. All of Pharo is implemented in Pharo itself, and all the source code is there for you to inspect and modify. But it’s not just the code that is inspectable, it’s all the objects that exist in memory. You can, for example, evaluate
Array instanceCount to find out how many arrays exist at the moment (213464 when I tried). You can then obtain an arbitrarily chosen instance with
Array someInstance and open a graphical inspector using
Array someInstance inspect. You can also modify that array, without any idea of where it is used and for what, and thus wreak havoc with your system. For a more thorough approach to breaking Pharo, one of my favorites is
true become: false, which replaces
false and vice versa everywhere in the system. Pharo reacts much like I’d expect a human logician to react: it freezes instantly.
The complete state of a Pharo system, including all code and all objects, and thus even GUI elements such as open windows, can be saved with a click in what is called an image. This is obviously very convenient, but should not be used as the only strategy for storing code because images are fragile, as my example above illustrates. Consider an image your development environment rather than your code repository. In fact, Pharo supports and encourages storing code in Git repositories.
It is important to understand that explorability is not an accidental feature of Pharo (and other Smalltalk derivates), but has been a design goal from the start. Those interested in the history of this idea should look at Alan Kay’s Dynabook concept and then take another step back in history to Doug Englebart’s “Mother of all Demos”. The motivation behind all these developments is to make computing a tool not for performing tasks, but for augmenting human intellectual abilities. That goal is, unfortunately, very rare. In fact, the only other system I know of that was designed to be explorable is Emacs, also with the goal of maximally empowering users. Once you look beyond superficialities, Pharo and Emacs are actually quite similar. Both are built around a high-level programming language with a rich library, a user-interface framework, and development tools with inspection capabilities. Emacs then comes with a text editor as the default application at startup. Pharo has no such default application, meaning that it is pretty useless before you write some code of your own. That is probably the main reason why Emacs became so much more popular - people use it as a text editor and only later, if ever, discover its empowering features.
Explorability is what interests me most in Pharo, because I believe that computational science sorely needs it, and that existing interactive interfaces such as REPLs or notebooks are far from sufficient. They impose a linear thread of exploration, whereas I want to be able to go off on a tangent, dig in deeper into a model, compare two datasets side-by-side, etc. Notebooks are also rigid exploration environments which can be extended only with major effort, if at all. Pharo offers a much richer exploration environment, and makes it easy to adapt to problem-specific needs (another reference to the Glamorous Toolkit is compulsory here). The snag is that Pharo doesn’t offer much support for working with scientific data or scientific models (though I must admit that I haven’t checked out PolyMath yet). There are people who use Pharo for computational science (see e.g. this epidemiology simulation platform), so I suppose that there are useful tools I simply haven’t looked at yet.
I should perhaps say something about Pharo as a software development environment, but that aspect has been covered before by others in much more depth than I would do it myself. The demos in the Pharo MOOC are a good introduction, but for an overview of the possibilities, nothing beats Aditya Siram’s recent demo aimed at adepts of functional programming languages.
After all that praise, I have to add some caveats. First of all, the Pharo community is tiny compared to, say, Python’s, and therefore the choice in domain-specific libraries is rather small. Next, Pharo development moves on at a rapid pace, with the main consequence that nearly all available documentation is outdated, and what’s left is often an update for insiders rather than an introduction for newcomers. No matter how explorable a system is, you need some higher-level information to use it productively, if only to know the jargon that permits you to start searching for stuff. As an example, when I tried to figure out how package dependency management works, I had to ask on the Pharo user mailing list to learn that the keyword to look for is “baseline”. The three books Pharo by Example, Deep into Pharo, and Enterprise Pharo are probably the best place to start looking for introductory essays, but even they are two versions behind the current one.
Finally, let me anticipate a reaction that I expect regular readers of this blog to have. How is it possible for someone who underlines the importance of reproducibility in every second post to say something positive about a system that relies on persistent state to the point that it cannot even be bootstrapped from its own source code? There are a couple of replies. Most importantly, reproducibility is not what I am looking for in Pharo. Every system has its good and bad sides, and I am turning to Pharo for its good sides, explorability and user interfaces. Second, the Pharo developers are working on this. And finally, decades of dealing with persistent yet fragile system images have lead the Smalltalk community to figure out ways to cope with the resulting problems (e.g. changesets) that may be worth studying for inspiration. Computational science suffers from a fundamental tension between the short-term need for interactivity and the long-term need for reproducibility. So far, no one has found a satisfying answer, so it’s worth looking for inspiration in unusual places.