Tag Archives: Smalltalk

Digital Nostalgia

Some time in 1992, the inspirational Bruce Anderson told me I needed to learn Smalltalk. The web was in its infancy and with little information in the University of Essex library my only resources on this quest were a 720Kb 3.5″ disk with Smalltalk/V on it and a videotape. Being an impoverished student I first had to borrow a video recorder and then my introduction to a programming language still more advanced than most of what is out there began.

The video is only twenty minutes long but I had to watch it in two parts due to the headache induced by the lack of vertical sync between the video camera and screen. Bruce tells me the video was made in 1985 at Queen Mary College, London on a Tektronix 4400 series.

Many thanks to Bruce for giving me permission to publish this small but pivotal part of my programming history

Is force.com the new Smalltalk?

Possibly a question that you never thought would (or should?) be asked and one to which the one-word answer has to be “no”. But its “no” with some interesting caveats.

I’m an engineer by background, not a computer scientist. I have a passing interest in language design but I’m much more interested in what a language allows you to deliver and how: does it make delivery quicker, is it easy to maintain, how easy is it to hire people with these skills, and so on? I’ve developed seriously in assembly language, C, Smalltalk and Java and have dabbled with Fortran, Javascript, C# and Ruby. Of these Smalltalk was the first I really felt at home in: I could quickly and easily build powerful, performant, scalable systems and, at the time, its was still accepted that Smalltalk was a viable choice for enterprise systems so there was a good community of people with real experience to talk to and learn from. In many ways, moving to Java was a step back initially but as the Eclipse IDE got better, Java gained the ability to remote debug, and the library and component support got richer, I began to feel at home with it too.

Dabbling with force.com reminded me of my experiences with Smalltalk. The most striking thing about it is the thing I really loved about Smalltalk: you develop in the same environment the user uses. This is an incredibly powerful concept that allows programmer and customer to literally work side by side in developing a solution (Dave Thomas called this a ‘super pairing’ in a conversation a couple of years ago). 

The next most interesting thing is how quick and easy it is to do what you want. In Smalltalk/GemStone, adding a new field to the database was a simple as adding a member to a class. No SQL to generate and run and no object-relational mapping layer to define. In DST (the Smalltalk CORBA product if you remember CORBA), making a method available remotely was a simple as including it in the IDL; no stubs and skeletons to generate and tailor. In force.com you add a new field to an object and there it is available in your forms, reports, via the REST API, and so on. Ruby/Rails may be a step forward from J2EE but its still not as easy as this.

These two combined means its very easy to work with your user to thrash out ambiguity, explore difficult concepts and making small change without having to resort to mock-ups or smoke-and-mirrors ‘rapid prototypes’. It might not be the way you want to do everything but its great for many of those features that are really important to the user.

Like Smalltalk, everything in force.com – including, tabs, object definitions, classes, pages and workflow tasks – is an object, a degree of simplicity that Java can never hope to achieve regardless of how much autoboxing and annotation you put in it. Everything the user uses in force.com has state, relationships and behaviour that are easily accessible by the developer in a single technology. Simple and powerful.

There are a number of rough edges, the such as atrocious support for debugging (back to the days of printf(“You are here”) again!) and the Apex language is, shall we say, pragmatic rather than elegant (as I said, I do have a passing interest in language design) but I can see those being smoothed off quite quickly as the developer community grows and the force.com developers have to start supporting this community.

Clearly force.com is a product delivered as a service run by a for-profit company where as Smalltalk is a general purpose language supported by a community of enthusiasts and commercial organisations so there is no direct comparison. But some of the old ‘Smalltalkness’ that Java never really gained despite trying very hard is very much present.