From the Mist

Smalltalk programmers have, for a long time, looked at their Smalltalk image with mixed feelings. They were happy to immerse themselves in the world of objects and learned to live in it like a dolphin in the ocean (which, as you know, was originally a land animal, turning to the sea), and make grateful use of the facilities it offered because code, applications, and objects lived in the same space happily together.

They were also slightly envious of other, less productive languages, where you could start anew with something like:

   main()     {

… and then the world of possibilities would be endless… until of course the world of problems created by exponential complexity would overwhelm you…

While there is a Smalltalk focussing more on scripting abilities ( GNU Smalltalk ) and doing a great job of it too, as a rule Smalltalk adheres to the “object world” structure.

The question rose to my mind: is this such a problem? Can it not be that this is a good thing?

The Smalltalk image as a miniature world of objects, residing on what might be called a Smalltalk node, may very well be precisely the concept that can transform the web into something useful and propel it into the “next phase”. As can be seen in cloud computing, the web is gradually moving toward a distributed model, in which even things like backups become things of the past because everything is everywhere. The original model of redundancy of the Internet, put into it by requirements from the US DoD which funded the ARPANET, the precursor to the Internet that specified it should be able to survive a nuclear attack, can easily be recognised in this.

However, what is running at the moment on these many nodes realising the Google File System or Amazon S3 , is code. Not objects. Properly recognised as a requisite for these clouds, the code is written in dynamic languages, but still: the code is not the thing. It needs writing, compiling, testing, and deploying. What is worse: it needs to do this outside the runtime environment. It needs rigorous processes to keep them under control – it needs control in the first place.

What if we had Smalltalk images running on thousands, millions of nodes? What if we had to think about communicating between worlds of objects instead of between ip addresses, interfaces, service connectors? Can we not envision an object cloud as much more efficient, much more scalable, and most importantly: with many more capabilities? It is alive at the higher and at the lower levels of abstraction.

Smalltalk systems have already been built using a network of Smalltalk images. Some of them even quite large ¹.

The important thing to realise is that with Smalltalk we have a technology that can scale up as well as down: Smalltalk images, including all tools needed to access the objects in it, can be created to fit in a 5 MB memory space or even much smaller, with room for applications. This may have been large 20 years ago, but has now become a commodity on the smallest mobile devices.

An issue that we may need to tackle as Smalltalkers is the operating systems. Smalltalk has originally been conceived as operating system, development environment and application environment in one. More and more I begin to realise that, if we want to get Smalltalk to as many devices as we can, we must consider the option of what I call hijacking the hardware : to offer users the possibility of running Smalltalk directly on the hardware. This also raises all kinds of issues with licences and such – vendors may not be particularly enamoured with the fact that their software is thrown in the garbage bin (take Nokia or Apple), but then of course the Linuxes have taken this path before.
Already we are seeing moves in this direction ². And I am convinced these are only the first signs of a greater change. Watch Smalltalk!