Computing - Languages - Smalltalk


1. Introduction

I had briefly seen Smalltalk somewhere in the late 1980ies, and was much impressed, both by what seemed possible with it, and by its price, that was not affordable to me at all, so I did not know much about it, and had no real experience with it until 2001, when I found Squeak on the internet, which was then a five year old ongoing project of the original developers of Smalltalk.

Squeak impressed me a lot, especially because it was so different from anything else I had programmed in; because, like standard Smalltalk, it comes with its own environment in a so-called image, and that environment, although odd and quirky for those who are not used to it, is very powerful; because Squeak and Smalltalk had some features I had dreamt up myself as desirable, but had not found in other programming languages or environments (an example: executing bits of code in the editor one writes it in on the fly - which gives a very much more powerful text-editor); because the programming language Smalltalk is very well-designed, clear and readable; and because coding and debugging the Smalltalk way - and Smalltalk is an interpreted language, which gives special possibilities for debugging - is quite pleasant and easy, if one knows the Smalltalk system.

And another reason to take an interest in Smalltalk is that much of OOP - "Object Oriented Programming" - and also much of the graphical user interface later adopted by Apple and Microsoft Windows was originated by the developers of Smalltalk, and was and is incorporated in the language and the environment from the inception of Smalltalk onwards.

Since then I have spend rather a lot of attention and time on Smalltalk and Squeak, with mixed results, of which more below.

2. About Smalltalk

Here is first a description of what I tried out in Smalltalkland.

There are quite a number of different Smalltalks, but they all go back to the original Smalltalk released in 1980 and developed at Xerox, and they all still seem to contain some of the code written for Smalltalk 80 (or earlier, as Smalltalk was in development since 1972). Also, they all are similar in their facilities and their feel, even though they may be different in details.

The currently best developed and best documented Smalltalk system is Visual Works, that is a commercial product, for which a free non-commercial edition is available. This also is the fastest Smalltalk, which may be a concern for those developing applications - say: large databases - which take a lot of processing.

If you want to learn Smalltalk, Visual Works seems the best, for it has the most facilities and the best documentation.

There are several commercial alternatives that also have a free non-commercial version that are good. The one I have most experience with is Dolphin. This is well-documented, and rather a lot simpler than Visual Works, but for learning the Smalltalk language and the basic environment the relative simplicity may very well be a strength rather than a weakness.

There are two problems with Visual Works and Dolphin that should be noted before moving on to other Smalltalks:

  • In either case, one finds oneself inside an environment that is very powerful, and that is much like an Operating System, but which does not have all or most of the facilities of Windows (or Linux, or Mac).
  • In either case, these being commercial products, one does not get the source code of the basic program, that is called the Virtual Machine or VM among Smalltalkers.

The first problem cannot be solved without leaving Smalltalk, for the Smalltalk environment derives from the image, and that is essential for Smalltalk, and the image takes the place of the Operating System.

So - and this holds for all Smalltalks - one programs in and for the Smalltalk environment, rather than in or for the OS on which Smalltalk runs. This has considerable  advantages, but one considerable disadvantage is that the Smalltalk environment is less rich than a good modern OS ("Operating System").

Thus even in Visual Works a number of things that are common in modern OSs - Linux, Mac, Windows - are impossible or very difficult to achieve in the Smalltalk-environment.

And it should be noted with some care - I did myself miss this point in the beginning - that all Smalltalks to this day are effectively their own OS (working in another OS, such as Windows, Apple or Linux, that is rather a lot more powerful), which means that one can not do quite a number of things (graphics programming, using the Windows Api, compiling independent executables or dlls) one can and does do with other programming languages, like C or Delphi or Pascal.

The reverse side to this is that in a Smalltalk environment many things are easily and quickly possible that are difficult to do in Windows and other OS-s without a lot of programming in some other programming language. (This is especially true and striking with regards to database-like programming.)

The second problem - hidden source of the VM - cannot be solved without Visual Smalltalk and Dolphin ceasing to be commercial.

3. Some Smalltalks

Next, there are a number of Smalltalks that do come with source-code for the VM, of which the three most important seem to be GNU Smalltalk, Self and Squeak. There are a lot more, by the way, for which see the Wikipedia entry on Smalltalk.

The GNU Smalltalk that I saw - some years ago - is an implementation of Smalltalk 80, and little more, and without a proper documentation. It may be good and useful for those who know Smalltalk, but is not recommended for those who are naive about Smalltalk.

Self is a variant of Smalltalk that was developed by SUN. If you are interested in the theoretical basis of Smalltalk or OOP this is certainly worthwile looking at, for SUN has released the code after not developing it any longer for ten years, and on Linux there was - some years ago - a working Self developed from that release. But again, this is not recommended for those who are naive about Smalltalk.

Squeak was first released in 1996, and was then essentially Smalltalk 80, that was taken up again by the original developers of Smalltalk - Alan Kay, Dan Ingalls, Ted Kaehler, Scott Wallace  - to develop a Smalltalk "for the new Millenium" and "for multimedia applications", all under the banner "Back to the Future".

It was rapidly developed the first 5 years, essentially by grafting a lot of code, called Morphic, on top of Smalltalk 80, which enabled one to do many kinds of graphical things with arbitrary shapes on the screen.

In 2001-2002 the original developers ceased developing Squeak, and started another project on top of Squeak, called Croquet, which is a kind of Squeak in 3D (or rather: what looks like 3D on a flat screen), while Squeak has since been further developed by others.

The basic problem with Squeak, which makes it not recommended for those who are naive about Smalltalk, is that - indeed like Smalltalk 80 - it is very badly documented (even though this seems otherwise to seasoned Smalltalkers): Great parts are not documented at all (so you get all the source code, but no explanations whatsoever what it was intended to do); the parts that are documented are often documented in a quaint anthropomorphic English (Smalltalkers often like to pretend, believe or at least speak as if Smalltalk programs are animated, living things, for which reason one can find a lot of documentation for Smalltalk-programs on the pattern of "I am a foobar that knows how to fee, but I desire to fizz if fummed"); and there just is no good documentation that explains to newbies to Smalltalk or Squeak how to become a proficient programmer in Squeak.

Hence, Squeak is not recommended for those who are naive about Smalltalk or about programming - though I should add in fairness that (i) there seems to be an effort going on by the present (2007) developers of Squeak to write a decent documentation, but also that (ii) it is sensible to be skeptical about this, since in fact Smalltalk has been very badly documented since its inception.

In any case, if you are interested in programming, and know something about it, but are naive about Smalltalk and its later incarnations (inbitations?) you should take a serious look at what's possible in it.

If you are not already quite familiar with Smalltalk, the currently best way to learn it seems to be by way of Dolphin or Visual Works, since these have the best documentation and - speaking only about Smalltalks for the Windows OS - according to many the best look, since they use the Windows API.

And Squeak doesn't use the Windows API and may initially look quaint or primitive. It isn't, but it needs getting used to if you have only programmed in, say, Delphi or Java.

On the other hand: Much of what Squeak was nominally designed for in 1996 - multimedia - seems to be these days better possible through other means, such as JavaScript, which also is a pleasant programming language, and is far better with browsers and html than Squeak can be and is.

4. On Smalltalk in 2009

In 2007 I wrote two rather long pieces on Smalltalk and Squeak, namely About Smalltalk and About Squeak, with some follow-ups, and my present position on Smalltalk is similar, but more negative:

I think Smalltalk is dead - or at least dying, for it still has its users and its  uses and it still is quite good for some things, provided you know the language and an environment for it well, and my reasons are fundamentally these:

  • Essentially, every existing Smalltalk is its own OS, that is a precursor of Windows, Apple's and Linux, that were essentially derived from it, but have been developed much further (and in other directions, as well) than Smalltalk, in which one can do considerably less than in any modern OS it is running on - but these modern OS's can not be programmed with Smalltalk (which only can program for its own OS).
  • In addition, every existing Smalltalk is not only locked up in its own OS, but also in its own image, which is a depository for its code-base and present stat, which is one monolithic block of code and what is associated with it, that in consequence contains loads of code that is very much entangled with other loads of code.
  • What one learns when learning Smalltalk (that tends to be very badly documented, also) does not concern learning about computing or computers as such, but comes down to learning about Smalltalk and a Smalltalk image. And nearly everything one then learns (not to speak of the prose it is often written in) is non-transferable: it only holds within Smalltalk, often also only within a particular environment and image.

So I have decided to give up on Smalltalk (though I probably will keep using it for some ends), for I do not believe the Smalltalk-world as is will be able to overcome these problems.

Also, I will not recommend learning it, basically because (i) it still is not at all well-documented (ii) it is difficult to learn (iii) it teaches almost only non-transferable knowledge and skills (iv) the Smalltalk environments / images / OSs / implementations (choose your preferred term) are not by far as powerful as modern OSs are, which collectively may be summed up as (v) if one only knows Smalltalk, one effectively is in a cul de sac as regards computing, computers and modern OSs.

Actually, this may be - indeed: no doubt is - quite fine for professional people who are making money with it or doing research with it (Smalltalk is not fit for rather a lot that modern OS-s are fit for - such as graphics programming, a funky modern Api, or such elementary things as html, that turns out to be problematic for Smalltalk - but it is quite fit for some tasks, and once you can code in it, coding in it is easy and fast), but not as an educational tool to program in for non-professional people or to learn about computing and about computers.

This is basically why I gave up on it.

last update: Nov 6, 2009