Nice blog by Cees de Groot about the SqueakNOS project that has been revitalised. This project has my special interest since it clearly demonstrates some features of Smalltalk in the sense of it's completeness. We are not talking programming language. We are talking system.

• Smalltalk's fundamental flaw
• Smalltalk's blessing - or curse?

The writing is on the wall. The signs are unmistakeable. Smalltalk is back, on the beginning of a new success journey. I will not write about why I think this is so in this blog. I want to concentrate on my opinion that, unless as a Smalltalk community we make some radical moves, this success spiral will be a spiral into death. Not hibernation, which more or less defines what happened to Smalltalk in 1995. Death. Final and irrevocable. Let me first recap the main points I want to talk about:

1. we cannot currently survive a greater than 10% increase in cash flow into the Smalltalk development effort
2. the Smalltalk community is it's greatest strength and it's greatest flaw

The price of success

Companies are feeling it, individual Smalltalk programmers, especially those with some reputation are finding out they are suddenly dramatically increasing in value. Nothing wrong with that, how could there be? Growth is the holy grail in business, success is what we all dream about. Dynamic languages, metaprogramming and reflection — suddenly our treasured properties of the Smalltalk experience have gained status on corporate and mainstream computing. We knew we had the best thing in computing, and it is getting recognised (again...). A new generation of bright and creative programmers is bringing the cool back into Smalltalk, taking it away from Java. And even Ruby. But, as many start-up and even larger companies have found out to their peril, success can kill you. And there are several factors in the Smalltalk world that will guarantee death unless they are dealt with, and dealt with now, by a concerted and combined effort that is supported by the community as a whole, individual Smalltalkers and big and small Smalltalk companies.

Smalltalk is not one thing. There are several Smalltalk dialects and development environments. In itself this is not a bad thing, but it is crippling the community to have an open source Smalltalk in Squeak, and a commercial environment in VisualWorks from Cincom, to name the two in my view most important Smalltalks around. It is crippling the community that efforts to improve interoperability, like Sport, are consistently ignored and not utilised when interoperability (such as in Seaside) is needed. I see it as a sign on the wall that well-meant efforts are bubbling up again and again to create a new Smalltalk environment (for example Syx).

I feel this must change: the Smalltalk kernel, that is the Smalltalk VM and the base Smalltalk syntax and metalevel definitions, should be placed under the umbrella of a small, preferable community-driven, group. Squeak had this group for a while, Squeak Central, with recognised leaders like Alan Kay and Dan Ingalls. While the existence of such a group in itself opens the door to politics, this cannot and should not be avoided. In the wake of success, politics will make attempts to strangle the blooming anyway, you can count on it. If greed is your motivating force, poverty will be your harvest. I will later on write on some of my ideas on how this may be managed, but I want to mention here that I think there are ways to manage politics.

Michael Arrington has created a little buzz with his blog post We Want A Dead Simple Web Tablet For $200. Help Us Build It.

We can do better.

Instead of Linux and Firefox, the Smalltalk system will provide an open-access environment on this thing, even for many end-users because the development environment will be part of the system.

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!

Attributes of Smalltalk

As many of the Smalltalk community know, Smalltalk was originally designed to be a multi-headed beast for the Xerox Alto and other personal computers incubated at the Learning Research Group at Xerox:

• operating system
• development environment
• applications

But, of course since it all was Smalltalk, there were quite a few differences with "modern" operating systems and all such, no matter if we are talking Microsoft Windows here or Linux. The entire environment consisted of objects that were (and still are on modern Smalltalk environments, though most run as good citizens on top of operating systems) OPEN.
Open in the Smalltalk sense has quite a different meaning than what developers usually see as "open". Since the Smalltalk object space includes the entire and mature development environment, open here really means open : all objects can be accessed through a full meta-layer, viewed (inspected) and modified from within the inspectors or browsers. Which themselves are objects and accessible as such. Opening a browser on an object can be as simple as opening a text editor and typing:

    object browse

This would open up access to the class definition and method definitions of the object, while viewing objects from the inspectors would give access to the inner structure of the object.

Apart from a set of so-called primitives, which access the vm layer that connects the Smalltalk world of objects with the OS or the hardware, all these objects can be accessed in a trivial way, without leaving the environment, using fully integrated tools, and open for play and experiment.

Smalltalk as a language is, though much criticised by "real" computer programmers because it is so different from the esoteric syntax they have gotten used to, simple to the extreme. So simple in fact that children (as long as they have not been polluted by Basic or such) have no problems mastering it.

MVC Heresy

(via Cincom Smalltalk)

Arden Thomas shares with us what he learned from someone “who was there”, Dianna Merry Shapiro, about the origins of MVC.

One story I found interesting, was one about the MVC framework (Model View Controller). MVC is one of those basic frameworks that you usually learn along with Smalltalk, when you first cut your teeth on using ST. What I learned was that MVC was added nearer the end of the decade of Smalltalk development (after Alan Kay had left iirc), and its addition was even controversial.

I heard it a bit differently: my recollection is that Xerox had planned a demo of the project at the Xerox World Conference in November 1977. They wanted to show off a screen with several windows on it, all synchronously responding to changing the value of a counter in one of the screens. The Counter MVC demo. For this a professor from Norway, Trygve Reenskaug, was asked during a sabbatical he spent with Xerox PARC, to provide a framework that could do this elegantly, and he came up with MVC. This is recorded in Dealers of Lightning: Xerox Parc and the Dawn of the Computer Age, and maybe I should check with Stephen Pope who shared this information when he was in the Netherlands with my company, Cibit.

Object Arts | Future development of Dolphin discontinued.

(via http://www.object-arts.com)

This shocking announcement by Andy Bower, one of the founders of Dolphin Smalltalk, made me realise a grave mistake: I have taken the Open Source movement too much for granted.

It is a bit the same as with my opinions about the antiglobalism movement. I have always taken pride in my innate desire to ask questions, to move by my insatiable curiosity, only to realise that too often I, as many people I criticise, I am entertaining half formed opinions that never have been scrutinised. Only after reading the book by David Korten When Corporations Rule the World did I realise that there was too much about the issue of globalism I never investigated, that my opinions were manipulated by what Korzybsky would call "thalamic" thinking. Much of that influenced no doubt by careful public relations work by the pro-globalists.