ceronio.net

Getting into Smalltalk (not a tutorial, just some ramblings)

While I am waiting for the Red language to mature (which, based on the regularity of releases, may not be for a good number of years), I decided to take (yet another) look at Smalltalk.

Before I talk about anything else, I just need to get something out of the way: I see on many blogs and elsewhere on the internet, that people brazenly declare Smalltalk to the be the first object-oriented programming language. This is patently untrue! The honour of “first OO programming language” actually goes to Simula. (Google “Simula” and read up on it).

I’ve been hearing about Smalltalk for many years and on several occasions I downloaded Squeak, opened it, decided it looked like a child’s toy (there is actually an educational version called Etoys based on it) and deleted it again. This time, however, I decided that all the hype surely warrants a bit more effort and commitment to try and acquaint myself better with it.

The thing to understand about Smalltalk is that the original Smalltalk implementation, and generally what people mean when they talk about it, is not just a language with an interpreter or a compiler, but a whole (graphical) environment. There are Smalltalk implementations (like GNU ST) with which you can write a script and run it from the command line, but that is not “classic” Smalltalk. Smalltalk, what most people think of when they hear the word, is this:

It is very hard to describe what the Smalltalk environment is. Basically it is a running system, written in Smalltalk, which also serves as a development environment and live coding environment rolled into one. It’s like the blind men and the elephant; there are many different angles from which to look at it, and not one really captures the essence.

If you are familiar with dynamic languages, then the idea is probably not foreign to you: you have a running VM in which the statements you issue, like the definitions of functions, classes etc., modify the running environment. (Unlike compiled code which tends to be static).

Because the environment is graphical, it provides a (supposedly) easier way to look at the system. As you add classes and methods (or messages in Smalltalk parlance), you are modifying the system, and you can see the changes you make (and make them) in a kind of system browser. To me, the concept is not too different from the ABAP repository in an SAP system, where the workbench (development) objects you create are persisted and accessible globally. Of course, that’s just a conceptual similarity.

In the case of a Smalltalk environment, you can save the running image and when you start it up again, you carry on where you left off the last time. This is somewhat different to how you normally program. Granted, when you close your IDE and open it again, your projects with their files are there as they were before. The difference between this traditional, file-based way of coding and Smalltalk  is that you constantly write the code, then start up the VM to interpret your script, which builds and modifies a running environment, but when the program ends, it’s gone. In a REPL (like IRB), you are also modifying the environment, but there is no persistence; when you exit it, your changes are gone. The Smalltalk environment provides the best of both worlds. And as I normally code with an editor in one screen and a REPL in another, the environment provided by Smalltalk offers a tantalizing alternative way to develop.

In Smalltalk, the development environment is also the running system.

I must be honest that I never managed to spend enough time with Squeak to even scratch the surface of its capabilities. When you open Squeak or Pharo (which I will look at in a moment), it is a very daunting experience because you honestly don’t know where to start. And while there is lots of documentation, it’s all just as confusing to begin with. (To misquote an old adage: “With great power comes a lot of confusion”).

After having dismissed Squeak (very wrongly) for looking like a child’s toy, I was pleasantly surprised by Pharo. Pharo is a spin-off of Squeak and it turns out this came along with a split in the community. Pharo, does a very decent job of looking very smart and (dare I say it) professional. It’s not full of garish widgets, choosing instead a lean and polished look. It turns out, talking about professionalism, that many professional tools have in fact been written using Pharo, such as Moose Technology.

Here is what Pharo looks like:

One of the things I have struggled with as a newcomer to Smalltalk is the steep learning curve, which I believe is due to environments such as the two shown above. I think most programmers would have a much easier time using GNU Smalltalk, if only because it provides a familiar development experience. That is not to say that newcomers to programming would find it easier to program in Smalltalk. The constructs of operating systems that we are familiar with are so ubiquitous that I believe it is much easier to teach someone programming with a text editor and the command line; not because it’s better, but because it’s what we’ve become accustomed to.

In my next post, I hope to share my experiences in getting started in Pharo in the form of a short tutorial. I’m picking it over Squeak, for now, because it seems more accessible and less bewildering. What I do miss is a real step-by-step example-based tutorial. There is a free book called “Pharo By Example” available from the Pharo website, but it spends a lot of time trying to teach you the concepts of the environment and less on actual practical examples.

There are other free implementations of Smalltalk. I downloaded Dolphin Smalltalk, which is a Windows-based Smalltalk implementation. Like the other two, it provides the same immersive development experience, with the difference that it is better integrated into the OS (windows are actual Windows windows) and of course, it is only for Windows. The installation comes with a nice tutorial, and by all accounts, it looks very alluring.