July 2007


Jul 29, 2007: 11.  About Smalltalk


Maarten Maartensz

Between 2002 and 2007 I spend considerable time on Smalltalk. I tried quite a few versions, but spend most time on VisualWorks , Dolphin and in particular Squeak (and some of its derivatives, like Croquet and Tweak).

I learned a lot from this, and Smalltalk and Squeak are cleverly designed and interesting systems, but Smalltalk did not give me the leverage it promises people who use it, and most of the things I learned with and from it are in the nature of "don'ts" rather than "do's".

Let me try to explain why this is so.

I will start with the good things, and gradually arrive at the not so good things, but I should first say that, like all of BitsAndPieces, my readers are supposed to be able to program at least fairly well in at least one programming language, and to be reasonably knowledgeable about computers and the standard terminologies for discussing these rationally.

Smalltalk started in 1972 at Xerox, where a research group had gathered around Alan Kay, who thought up its fundamental ideas and purpose, and who has ever since been the main character and ideas man in Smalltalkland, and in quite a few ways also its leading ideologist.

The most notable persons working with him were Dan Ingalls and Ted Kaehler, of whom Ingalls designed the basics, which were concerned with implementing objects and a graphical user-interface in the nineteen-seventies, and Kaehler designed important add-ons to these (some of which later formed the basis of Apple's well-known Hypercard-system).

For its time, Smalltalk was radically innovative and original, as it was one of the first object-oriented programming languages, and as its graphical environment, with windows and a mouse, was soon copied by Apple and later by Microsoft for Windows. (Interestingly, both of these firms did not use Smalltalk itself, nor the language, but only some of the ideas that were the basis of its environment. Also neither firm seems to have paid Xerox as much as a single cent for this copying, that they would call piracy if it concerned their own ideas or products.)

Object-oriented programming was not as rapidly picked up and copied (or re-implemented) as were the salient characteristics of a Smalltalk environment, but in the end these programming ideas also took hold, albeit it again in another form, in most programming languages.

Hence originally, say from 1972 to 1980, Smalltalk was a very original research product, that embodied and pioneered very much of what became of central importance to computers between 1980 and 2000: Graphical interface; overlapping windows; mouse oriented interface; and object-oriented programming were the most important of these ideas.

Apart from this, much of Smalltalk and Smalltalkers at the time (and also later) were much motivated by two other ideas of Kay, that were more of an educational and social nature:

  • Programming is for everyone, including and in fact especially for children, and "Smalltalk is for all children of all ages, from 8 to 80".
  • The computer hardware industry should develop - note this was an idea of Kay around 1972, mostly based on the previous point and on Moore's Law - a DynaBook, say effectively what we in 2007 call a Notebook computer.

As I indicated, the Dynabook-idea eventually also got implemented and got quite successful, but this probably had less to do with Kay's ideas and with Smalltalk than with the general rapid evolution of computing hardware. Even so, it is true that in 1972 this was quite a visionary idea, like many of Kay's other ideas.

The first point above, that programming is and should be fit for children (who, according to Kay, are its best and most gifted audience because they still are free from prejudice and full of interest and curiosity), also had quite a few influences on Smalltalk, and on social events relating to it, notably in the efforts spend at making the programming language Smalltalk as clear as could be, and also as close to English as was feasible.

Between 1972 and 1980 Smalltalk was repeatedly overhauled and at least once redesigned, but the basic ideas worked, and in 1980-1981 Smalltalk was launched publicly, and marketed by Xerox in the form of licenses, and for profit.

Around 1980 Kay and his group dispersed, and indeed left Xerox (that seems to have had a quite bureaucratical and blind managerial staff), for which reason Smalltalk itself was not much developed until the 1990-ies, though it was also implemented by various firms, like IBM.

Also, in 1980 Smalltalk was at the forefront of technology; it clearly was far more capable and easy and pleasant to work with than any other programming language; it could do and did have what few if any programming environments or computers had at the time (a graphical environment, for one example, and a very smooth and pleasant programming environment in and for that very environment for another); and indeed the licenses that Xerox sold for the right to use a copy of Smalltalk cost a lot of money. (I saw Smalltalk first ca. 1987 and was much impressed both by what it seemed capable of and what it should cost.)

So far, so good. Meanwhile, one other thing had happened, that in my opinion was not so good.

In order to make Smalltalk a great success, and to explain it to people - "children of all ages, from 8 to 80" - naive or completely ignorant about programming, a considerable documentation effort had been made, that had resulted in four books that documented Smalltalk in most of its aspects, of which the most important and central one was "Smalltalk 80" by Goldberg and Robson, also known as The Smalltalk Bible or Blue Book (because of the color of its cover).

This had taken the form - I do not really know or understand why - of explaining Smalltalk in a very strange anthropomorphical English, in which the basic building bricks of Smalltalk, objects, were supposed and said (over hundreds of pages, again and again, relentlessly) to know and desire things - as if a box made by drawing a square on a screen was an animated entity (called "Joe the Box" by Goldberg and Robson) that wanted things, and knew things ("Joe knows how to move around. Joe knows his own name and class. You can ask him by typing...") - and so on and on for this whole bible of Smalltalk.

When I first read this - in 2002, after considerable effort to locate a copy somewhere in the Dutch university library system - I initially thought it was a joke, then that it was pure Monty Python, then thought of Heidegger, and in the end returned my copy since I am unable to read such categorical insanity, since have a strong distaste for semantical nonsense, however well-intended. (It turned out later that Edsger Dijkstra felt much the same way, so I am not the only one with this reaction - and in good company too.)

Even so, Smalltalk was - especially in 1980 and until 1995, with the arrival of Windows, that was a graphical OS, and not merely a graphical programming environment - an extra-ordinarily capable and well-designed environment and language, though it was "explained", on what was claimed to be a fundamental level, in terms of a kind of theological or metaphysical language I could only liken to Heidegger at its worst, or post-modernism (antedated 10 years or so) in its most pretentious forms.

And it is true that, comparatively speaking, and with reference to the documentation of other programming languages at that time, Smalltalk had an extensive, if decidely anthropomorphical paper documentation, that also was read, consumed, believed and practiced by quite a few converts to programming in Smalltalk, if only because until Borland's compilers and IDEs for Pascal of the late 1980ies, Smalltalk was unparalleled for programming ease.

Indeed, the most important reason Smalltalk did not get much more popular than it did between 1980 and 1990 was its license fee, that was not really affordable for private persons, and only realistic and fair for firms. And also Xerox soon got into trouble because of mismanagement, while the computer-revolution did not really explode until 1995 with the arrivals of Windows 95 (graphical computing for the masses at last!) and the internet, that potentially connected every computer-user with every computer-user.

To return to Smalltalk and its documentation:

While there was a considerable if ill-written paper documentation in 1980, Smalltalk running on a computer was not at all well-documented - one got all the source-code (if one had signed and paid the license), but it came with very few comments, and those often on the pattern of "I am a foobar that knows how to fuss but desires to fee if fummed", for which reasons one mostly had to puzzle things out with the help of the paper documentation, or with the help of others, who had managed to learn the system - or rather: a part of it, sufficient for their own programming purposes, for it seems that very few Smalltalkers ever got to comprehend or use all or indeed most of the system.

There was another reason for this, next to its ill-conceived anthropomorphic paper explanation and poor programming documentation: The Virtual Machine - which is the Smalltalk name for the executable that runs a Smalltalk system on a computer.

This was not documented by Xerox, and in fact secret, and indeed the result of quite a few years of work by Ingalls, Kay and others when working for Xerox. It was (and is) this Virtual Machine that generates and runs the graphical environment of Smalltalk, and that does the fundamental processing for its environment, though it also enables that this environment may be mostly written in Smalltalk, that can be compiled in the environment, that works like an interpreter for Smalltalk.

Again - and this will be important below - (1) this Virtual Machine gets its information by means of what Smalltalkers call an image, which is in fact a repository of what has been done before (with that image, when working with Smalltalk) and (2) the Virtual Machine + image take over from the operating system.

Thus, every Smalltalk-system in fact consists of three items: A virtual machine, to load and run an image, that produces from it the Smalltalk environment in which one works, that is in fact much like an Operating System (OS) in that the code written for and in it only works for and in a Smalltalk environment with a Virtual Machine; an image, that is a repository of what has been done with it, more or less as a text on disk is a repository of what has been done with the editor to it; and a so-called resources file, that is a repository for all the Smalltalk code of the system.

The reason this set-up is important is what it implies:

First, in 1980 and the next 10 years, this enabled a Smalltalk-system to have an environment that was much more powerful than anything else on a PC - because these were not graphical, and either were an OS without programs, or a program running on the OS that only used a small percentage of the power of the OS.

By contrast, Smalltalk presented its user with a total environment, that was graphical, powerful, easy to program for anyone who got the hang of Smalltalk, and far more capable than anything running under DOS. Indeed, the only thing like it in the early late 80-ies were the early Apples, for these too had a graphical interface, that in fact was derived from Smalltalk, but re-implemented as an OS, and without an embedded programming language.

Second, although this set-up provided great benefits for Smalltalk, both as regards power and esthetics, again when compared with what was possible under DOS, this also implied an important limitation:

  • Everything Smalltalk was part of an image, to be run by a Virtual Machine, to result in what was effectively its own OS when running, and everything Smalltalkish had to be part of an image and to be run by a Smalltalk Virtual Machine.

Third, the OS a Smalltalk was hosted on was hardly used other than to enable Smalltalk to start. After all, Smalltalk's environment comes from its image + VM, and one can do without an OS once it is running - whereas one cannot use the OS's resources, except in very limited ways, that again are intertwined with the Virtual Machine, that was not programmed to use the OS's resources but to run apart from it.

It would seem to me that this situation did not matter much until 1995, when Windows 95 was introduced, and everybody who computed, not just the small group of Apple-users and Smalltalk-programmers, got a graphical interface as a matter of course, and supplied by the OS.

My reasons for this diagnosis are two:

A. Until 1995, Smalltalk was in quite a few respects more capable, more flexible, and easier to program (when one knew the language) than almost any other programming language or environment.

It is true that, being interpreted, it was a lot slower than code produced by C, by a good programmer, but for many purposes this did not matter at all, and Smalltalk was fast enough in practice, and far easier to learn and work with than C.

B. The reasons for this relative excellence were in fact the combination of Smalltalk's Virtual Machine and Image, together with the graphical user interface this made possible, and in conjunction with the clear, well-crafted and easy to read Smalltalk-language.

By now we have arrived - in this potted history - around 1995-1996, when two or three important things happened for computing:

1. Windows 95 made graphical interfaces the standard.
2. The internet was created.
3. Alan Kay and group came together again, to develop Smalltalk

The first was quite a revolution, and indeed gave the user of a PC with Windows, up to then working with a text-based interface, in one full swoop a graphical interface that was much better than anything Smalltalk had to offer (or indeed any other programming language).

The second was an even larger revolution, for it almost immediately created far more interrelations, connections and communication across the globe than existed before, and put, again in one move, far more knowledge and information at the fingertips of any computer-user when connected with the internet than any person had ever had before - and this included enormously increased access to all manner of mostly free programming languages and environments (and also the beginning of an ever increasing morass of spam addressed to the lowly gifted, always in vast majority, who also got connected when this became feasible for them, "plug and play" style, and that contributed much to the traffic in porn and miracle cures).

The third was only important to lovers and cognoscenti of Smalltalk, and although Kay and his team were financed at the time by Disney, and although they advertised their renewed activities as a development team, with Disney's help, as "Back To The Future", "Multi-Media Computing", "For children of all ages, from 8 to 80" etc., their efforts, which they called Squeak (possibly after Disney's mouse, since Disney financed them), did not get widely known or popular.

In fact, what happened was this.

What Kay and team started with in 1996 was in fact a copy of Smalltalk 80, from 1980, that - I believe - Disney bought for them from what remained of Xerox (that had mostly gone to pieces after 1980) and that also involved (and still involves) some copyrights by Apple.

This Smalltalk 80 system they got running, first on a Mac, and soon after on Windows, and they started developing it by adding things to it that were mostly related to graphics, and also to programming sound and music, and 3D. These additions, which much extended the capacities of Smalltalk 80, but were grafted onto it with few changes, they called Morphic.

Their efforts soon got a considerable following from existing Smalltalkers, and they developed Squeak for a little over 5 years, as Open Source (though plagued by obscure license-problems), moving from version 1.0 in 1996 which was essentially Smalltalk 80, to version 3.0 in 2001, that I first saw in July of that year, and found impressive, quaint, interesting, and unlike anything I had seen until then on a PC or Mac.

I shall say more about Squeak below, but first want to straighten out a little more Smalltalk history, for Squeak was not the only Smalltalk that was developed.

In fact, there were quite a few other Smalltalks, mostly from the days before the internet, and mostly commercial. These were all developed like Squeak, from Smalltalk 80, and many had been considerably improved over Smalltalk 80 in the intervening years.

The most important of these was VisualWorks, that was (and is) commercial, though it also provides a non-commercial version for free. This was indeed far further developed than Smalltalk 80, a lot faster, and a lot more powerful, and also, unlike Squeak and many other Smalltalks, it used part of the power of the Windows OS, by extending the Virtual Machine that way.

Another, implementation of Smalltalk, considerably simpler (and cheaper)  than Visual Works was Dolphin, that also used parts of the Windows OS to get a nicer graphical interface than Smalltalk 80 had or could provide. This also came (and comes) with a free version for private persons.

Both Visual Works and Dolphin are quite well-developed, stable, and pleasant to work with, and at present (2007) - for a Smalltalk system - reasonably documented.

As for Squeak, Kay and his team left it in 2002 and started a new effort, not funded by Disney or Apple, called Croquet, which in effect is Squeak with an added amount of code for 3D. This has been under development since 2002, but doesn't have a great following, because it still is a rather buggy affair, that is also only understandable by seasoned Smalltalkers who are willing and able to spend a considerable time on it.

Squeak since 2002 has been further developed by several groups, and is at present at version 3.10 (or 3.9 - this depends on how you wish to see it). In fact, in my assessment, it isn't far beyond where it was in 2002, and indeed lost rather a lot that was interesting, that was developed by Squeak Central (the original developers) but not maintained afterwards.

It also has considerable problems, though its users and developers see it otherwise. These are mostly the following four (though there are more):

  • Squeak is effectively very badly documented, and
  • where documented, Squeak is documented very partially, incompletely and in bad anthropomorphical English.
  • Squeak (like all Smalltalks) is effectively locked up in a virtual machine + image, that replaces the OS, but that is far less powerful than a good modern OS, and that makes the use of the OS difficult or impossible.
  • Squeak has great amounts of spaghetti-code (and see the two first points).

The first two points make it very hard to learn for those who don't know Smalltalk already.

The third point gives Squeak an interface that looks quaint, and is far less powerful than is possible when one had all the resources of a modern graphical OS - but this is impossible to undo without a major rewrite of the VM, which is a difficult and time-consuming task, that is not within the programming abilities of most Smalltalkers (since it requires rather a lot of knowledge of C, in which the VM is written).

The fourth point is mostly a side-effect or artefact from image-based computing: Anything in the system can be connected to anything in virtually any way - with the results that (1) much calls on much (that is mostly undocumented), and (2) the whole image is entangled in many ways, which makes it almost impossible to disentangle or to modularize the system (into independently loadable and unloadable chunks).

A further problem for the development of Smalltalk and Squeak is that most who code in Smalltalk seem to really know little else as far as programming is concerned than Smalltalk, at least in terms of experience (or possibly Java, that in fact has some similar problems). Few seem to know C well, which is necessary to develop the VM.

And besides, Squeak has several irritating features, at least for me. One is that Kay, and consequently most Smalltalkers, still talks as if Squeak and Smalltalk is fit to teach programming to children.

Now, underdocumented as Squeak is, there are few adults, including many who know quite well how to program in other languages, who can master and understand Squeak in a reasonable time - and  many have tried, and many have failed.

Indeed, speaking as a psychologist, IF I wanted to teach children to program (but since I am a psychologist, and since I *know* Piaget I know that what Piaget really thought - though Alan Kay says he did or should have thought otherwise, on the Squeakland-site - is that one can not teach ordinary children programming, or higher mathematics, or abstract algebra before they reach puberty, unless they are very special to start with), THEN I would use Delphi, tweaked for their mother-tongue, and never-ever Squeak, very badly documented as that is. So - teaching children to program in Squeak seems to me just a (well-intended) illusion. (And playing with it is something else: That indeed may be quite instructive.)

Also, after 5 years of efforts around Squeak and Smalltalk, my judgement on both is that they seem to be less capable, less finished, less well  documented than what most of the competition - such as Java, C#, Delphi, FreeBasic, Visual Prolog, or RosAsm - have at present to offer, in terms of programming environment, interface and documentation.

Squeak just is not in the class of those mentioned, in these terms, and while VisualWorks is decent - compared with Visual Prolog or FreeBasic, that is, and perhaps Java, but not compared with C#, Delphi or RosAsm, that are better - VisualWorks too has considerable difficulties with its interface (as witnessed by the protracted birth-pangs of Pollock, its graphical extension, that aims at a better graphical interface, and the many things one cannot do decently graphically speaking in VW).

Consequently, the honest approach to Smalltalk, as far as I am concerned, is that it is interesting, clever, and worth studying, but that if you want to do some real programming, of a non-trivial application, there is Delphi - for ease of reading, interface-building, maintaining and extensive, clear and well-written documentation, or some other HLL, but not Smalltalk, except if you want to do something involving extensive databases, and then VisualWorks is the tool of choice (if you don't want any fancy graphics, and can live with an app of say 25 MB, for that is the size of a Smalltalk image for any somewhat complicated application).

Also, although there was no apparent other way to go for Kay, Ingalls and team in the 1970ies to do and achieve what they did and achieved, it seems to me to be in the present corcumstances, with excellent graphical OSs available to everyone, a mistake to code on top a VM that hardly uses the graphical resources available in the OS, which it does not have the power to emulate.

So, personally I have learned rather a lot from Squeak and Smalltalk over the last 6 years (almost precisely now), but in fact they are mostly in the nature of "don'ts", and also of a psychological and sociological nature, about groups, attitudes, and how fairly to very intelligent people can deceive themselves by wishful thinking and blind abuse of language.

And it seems to me that Smalltalk and Squeak have painted themselves into a corner with the use of the VM+image, that makes it very difficult or impossible to produce an interface that is like or better than what modern graphical OS-s offer as a matter of course for applications coded by other programming languages, and that also makes it practically almost impossible to develop a modular system.

Note this is a serious problem, and that VM+image hang together: The VM is not at all as powerful as Windows or Mac or Linux, but together with the image embodies Smalltalk and Smalltalk coding as is and was since 1980. It may be possible - with a lot of effort and expertise - to create a Smalltalk-VM that embodies much of the API of a modern graphical OS, but if one wants to port it to existing Smalltalk programmers a considerable part of what is in modern Smalltalk images must be somehow ported - and Smalltalk images are notoriously hard to disentagle into modules or independent chunks of code.

In brief: The VM+image was a great idea and tool in 1980, but it is a stone around the neck of Smalltalk developers in 2007. It may be that Smalltalkers find a way out of it, perhaps in the form of Strongtalk or the Coke and Pepsi plans of Kay's present group, called Viewpoints, but I have to see it before I believe it. (Effectively, what Viewpoints proposes is a new OS, with Smalltalk as the system's language.)

Anyway - I wanted to explain some of my present notions about Smalltalk and Squeak, and why these have not really given me "the leverage" they promised to its users, and I think I have done so.

One final reason for this judgement is that I consider Smalltalk to be - and I quote Steele and Raymond's excellent Jargon-files - a

"bondage-and-discipline language: n.
A language (such as
Pascal, Ada, APL, or Prolog) that, though ostensibly general-purpose, is designed so as to enforce an author's theory of ‘right programming’ even though said theory is demonstrably inadequate for systems hacking or even vanilla general-purpose programming. Often abbreviated ‘B&D’; thus, one may speak of things “having the B&D nature”. "

But this may be more a matter of taste, and such a language may be quite useful for some purposes.

Another time I hope to write about this category of programming language - which is indeed the category to which most programming languages belong, which is a fact that also, whatever their merits as languages, happens to partially blind many of their users about what does in real fact happen in their computer, because they believe that the conceptual abstraction that is at the basis of their HLL (High Level Language) concerns the real thing, instead of a manufactured illusion to make programming easier for them.

Like most theologians and philosophers, they confuse words or concepts with the reality they are supposed to be about. They confuse the menu with the diner...

But as I said, that is not my theme now, with which I am done.


        home - index - top -