Over the past few months I've had several requests for an old project of mine, one that I did a long time ago on the University of Groningen: The Beehive Simulator.

In this article I share with you some considerations on resurrecting the project, a very interesting and, I think, very useful thing to do.

The Beehive Simulator, just to recap, is a software application that does three things:

1. Build a complete apiary with beehives
2. Simulate the apiary, as in a game: the bees will collect food, the queen will lay eggs, etc. All that you can monitor in the program. It even simulates infections with the varroa mite!
3. Part of the system is a knowledge system with diagnostic capabilities: you answer several questions about an apiary and the bees, and problems that you have found, and the system will tell you what may have caused these problems and how you should deal with them.

The original ambition of the project was to use the program to help in monitoring the biological environment, because bees (as we are currently learning to our detriment) are very sensitive to disturbances, especially the use of chemicals.

However, the combination of elements of the simulator should make the product very interesting as well for beekeepers around the world as an educational aid.

Porting the software to another programming language would be possible, but for several reasons I would not like it it or even advise it. The software was written in Smalltalk, using a very sophisticated (because written by me :-)) simulation framework, and the same for a backward inferencing knowledge system. Rebuilding that in say C# would be a very large and complex project. The Beehive Simulator consists of more than 100.000 lines of code, and most of that code can be used in modern Smalltalk environments. Remember: Smalltalk is not dead, on the contrary! It has evolved and as I recently re-tweeted from a tweet by Grady Booch, still the environment in which it all happens (to be seen later in the mainstream languages such as Java or C#). Think of Refactoring, Test-Driven-Development, DDD to name just a few.

So yes I would consider resurrecting the project. But it must be in Smalltalk.

I'll keep you posted. Now I'm out looking for sponsors…

Three years ago Smalltalkers were somewhat worried about the drop-out from the TIOBE index of Smalltalk. http://bpieber.wordpress.com/2010/08/27/bad-news-smalltalk-falls-off-top-50-of-tiobe-index/

However this years' index show Smalltalk is back at a reasonable 37th place. From the ranking it is not clear what the move is, and I was unable to find the TIOBE index of last year to compare with:

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Interestingly enough btw is the first place of C (yes: C)! And with the rising of Objective-C and C++, and the lowering of Java I wouldn't be surprised if next year we would see the top three occupied by the C language family.

How do you create a deployment process that automatically creates packages to deliver to your users for all supported platforms with as little fuss as possible?

The content of this guide has been created with version 7.9 of VisualWorks.

Introduction

This article tries to provide a concise guide for standalone VisualWorks application developers. If you, like me, are building standalone apps that need to deploy on all supported platforms, you will encounter some interesting challenges. I have reached a strategy that works reasonably well, and I would like to share that strategy, hopefully benefiting others.

I invite VisualWorks developers to participate in making this article better. Files used in the article will be provided as downloads in a .zip archive.

Credits

I have used some (sparse) material already available on the internet. I try to give due credits:

• James Robertson created several video’s describing parts of the process
• Emiliano Pérez has an article at http://cag.lifia.info.unlp.edu.ar/cag/Wiki/05.+Tutorials/Deploying+with+VisualWorks
• There has been a discussion on the VisualWorks mailing list, instigated by me: http://forum.world.st/Installing-end-user-applications-on-Windows-and-ACL-td1599163.html

VisualWorks image preparation

The image you want to deploy has to be ready for deployment. This chapter summarises a few reminders.

Window icons

If your application has windows (that is, it is not headless) you will want to have those windows show your nicely designed icons. This is not applicable for all platforms (on the Mac your windows do not have icons) but it is on Windows.

For that you use the Assets packages. There are two of them, one (Assets) is loaded by default in the image (7.7 up), and one (Assets-IDE) needs to be loaded.

Read the doc. I usually create an application assets class, LogSimAssets for example. Create a folder containing the artwork in the form of png files you want to use, including the image you want to use as your window icon, and sync your assets class with this folder.

VisualWorks will ask you for the folder you want your assets class to sync with, and it will import all readable image files in that folder. The result is a set of class methods in the protocol category png imports

Now you have all the images from that folder available in your image as Smalltalk objects, that you can reach by sending messages to the class like:

LogSimAssets applicationWindowIcon

The icon you want to be your application window icon can be installed in two locations:

1. the application window
2. all windows (the default icon to replace the one from Cincom) — this is handy since you do not need to do this manually for every application window in your application, and also it modifies the icon in any standard windows you want to reuse, such as the directory browser.

The first way is simple. Go to your application class’ postOpenWith: method:

LogSimApplication>>postOpenWith: aBuilder

  super postOpenWith: aBuilder.
  aBuilder window application: self.
  "Your own initialisation code."
  aBuilder window icon: self class windowIcon

Create the windowIcon method in your application class and let it refer to your pretty icon in the assets you imported.

Building your image

My strategy is rather straightforward: after I have checked-in my sources into Store, with a comment like “Released version LogSim 4.2”, I file-out my sources into one or more special directories.
Let us say that for my LogSim application I need three components:

1. General code that I keep in a folder called Reflektis (my company’s name)
2. A framework for simulations in a folder called Simulations
3. The application-specific code in a folder called LogSim

All folders have the same structure:

1. all packages/bundles in .st files
2. a fileIn.st file that loads the .st files in the directory in the correct order.

Now if I want to create my runtime image I only need to file in the fileIn.st file in the application-specific directory, which will call all dependent file-ins.
There are a few extra’s:

1. I create a method prepareForDeployment in my application class. This method will be sent when deploying to prepare my class for deployment. More on that later.

Runtime Packager

This chapter describes the use of Runtime Packager to prepare a minimal image for deployment.

1. Load Runtime Packager

The Simple Approach

This chapter describes an image preparation strategy that does not use Runtime Packager, and (almost) no stripping of the image. This is useful for simple applications, that do not profit much from stripping.

Setup

For successfully deploying your VisualWorks application I am assuming the following:

1. You have a deployment image, created by using Runtime Packager or any other means.
2. You have a Windows icon for your application, in the form of a .ico file with several icon sizes (for Vista and later make sure you include a 256x256 size)
3. You are able to use VisualStudio 2010 Professional, to create the setup project in (probably need to chart a deployment strategy without the need of VisualStudio as well). Our approach here will elaborate on using the standard Windows Installer for your application, and not the VisualWorks Install framework. I have never been able to understand how I could use that.

Summary

Preparation involves some one-time actions. Note: to be able to do everything described below you need a Mac with XCode and a Windows PC with VisualStudio. Both OS’s can run inside a virtual machine of course (my setup is a Mac with Windows running in a vm).

1. Create a standard folder structure.
   The buildscripts folder will contain the .cmd files I talk about later. The messages directory will contain all the message folders/files you need for multilanguage projects. The uploads directory will contain the files you want to deliver to your users. You will notice I used the same naming convention Cincom uses for the platform folders.

Now we will go through the following steps.

1. Create your runtime image. I name it specific for the application I am creating: logsim.im.
2. Run the ImageWriter from any VisualWorks image to convert the 32-bit image to a 64 bit one. For simplicity in the build scripts this one is now named resource64.im
3. Now run the build script for the application, in this case it will be buildLogSim.cmd. It will perform the following tasks:
   1. compress the image with ImageCompress, and rename the 32-bit image to resource.im
   2. it will call all platform-specific build command files, including the Windows build command files buildwin and buildwin64. These platform builds all do the following:
      1. copy resource.im or resource64.im into the platform-specific target platform folder. For example for the *nix targets I place the image together with the executable into a folder system. However for Windows this is different, since the VisualStudio Installer project will place these files in the correct destination. So for Windows all build artefacts will be placed in one target folder (win and win64 in my case). The Windows Installer project in VisualStudio will reference these files later. For Mac OS X this is also different since the image (and some other artefacts) need to be placed inside a hidden .app folder. More on Mac OS X in a separate chapter.
      2. copy the platform-specific runtime into the target folder
      3. copy other resources into the correct location in the target folder, such as readme files or anything you want to deploy with your application.
      4. I will mention separately the messages directory, containing all message files you may want to deploy if you are delivering a multilanguage solution. This messages directory in my case is always placed in the same folder as the image.
      5. For Mac OS X the builder placed the output artefacts directly into the application package, here LogSim.app. On creating the correct layout for Mac OS X, and how to create a user-friendly installer for Mac users I will add a special chapter later.
      6. the Windows builder does a few more things:
         1. it uses ResHacker to add the following files as a resource to the executable:
            1. the image file (resource.im or resource64.im)
            2. the icon for your application, which I always call app.ico
            3. an application name as resource 325
            4. a version from a Windows resource file version.rc that is compiled with the Windows resource compiler
            5. the logsim.exe.manifest file which is compiled with the Windows resource compiler as well
         2. For the 32-bit runtime that is the result of the previous steps I use upx to compress the runtime exe as much as possible. Since upx is not yet able to do this for 64-bit Windows executables this is omitted for the 64-bit Windows target.
         3. I sign the resulting executable with signtool. For this, I realise, you will need to have a developer certificate. However you can ignore this, and tell your users that the install may warn for the unsigned installer.
   3. it will package the results from the build phase and place the files you will going to provide to your users in a special directory called uploads. Packaging will do the following:
      1. For the *nix platforms it will use 7-zip to create a .tar file with the folder you want to provide to your user, and gzip that .tar file.
      2. For Windows this phase does nothing, since packaging, resulting in a Windows Installer .msi file, will be done by VisualStudio.
   4. Finally some cleanup, to remove all intermediate files. The result is an uploads directory containing all deployments, except for Windows and Mac OS X. This is described next.
4. Go to VisualStudio on your Windows machine and build the installer using the setup I describe below.
5. Go to XCode on the Mac and build the application using the setup I describe below.
6. Finally for the Mac installer you want to build a nice-looking .dmg file, more on that also below.

Creating the Windows Installer

For this you need Microsoft VisualStudio. The examples in this chapter are created in VisualStudio Professional 10.

Creating the Mac OS X Installer

For Mac OS X you might deliver the .tar.gz file produced by the packaging phase described above, but your users will appreciate the common .dmg installer strategy. The file they download is a .dmg file, which is nothing more than a disc image. They can open the file which results in mounting the image on their desktop as a disk. This will open and create a window which shows what you have seen above for the MijnGeldConverter installer. Installation on a Mac involves nothing else than dragging the application to a folder, usually the Applications folder which is mounted as well but as an alias so that users can drag there instead of the “real” application folder on their desktop.
For building the actual application you will need to lay out a specific folder structure, and I have found it easiest to do this in XCode.

The XCode application project

As I mentioned above you will need a Macintosh, either a real one or one running inside a VM, and XCode, the Apple development environment.
This chapter is work-in-progress.

Building the dmg installer

I use DMG Canvas for that, but there are several ways to create a Macintosh disk image.
Here is a screen grab from the result of that for one of my applications, MijnGeldConverter:

This chapter is work-in-progress.

Build Scripts

I am using build scripts. These are .cmd files containing scripts that do the following:

1. Compress the image
2. Build the various platform deployment structures
   1. For Windows, this phase uses ResHacker (which is part of the VisualWorks installation, in the folder /packaging/win) to create an .exe that contains the image and possibly some resources like the nice icons you have created for your application). Also it creates a resource for the manifest file you need on modern versions of Windows for the ACL (Access Control List).
   2. This phase fills a series of output folders for each platform you want to support (i.e. hpux11, etc.).
3. Package the the produced output into a folder called uploads in the form of zipped archives or (for the Mac) .dmg disk images. These archives are the ones you deliver to your users, for Windows users this will be a Windows Installer .msi file, or a setup.exe.

You might implement the same functionality in some Smalltalk classes, and I may be doing that in the near future myself, but the build script strategy is the one I am using for the moment, also because I want easy command line access to some command-line utilities such as ResHacker, the Windows resource compiler, etc.
For the application name I am using MyApp.

build.cmd

set vwhome=x:Cincomvw7.9
set messages=x:Cincomvw7.9messagesvisualworks
call compress
call buildHPUX11
call buildLinux86
call buildLinuxPPC
call buildLinux86_64
call buildMacX
call buildMacX11
call buildSolaris
call buildSolarisx86
call buildSolarisx86_64
call buildWin
call buildWin64
call package
set vwhome=

compress.cmd

"%vwhome%packagingwinimageCompress" "%vwhome%imagemyapp.im" ..winmyapp.imcopy "%vwhome%imagemyapp.im" ..winmyapp.im

buildWindows.cmd

set sdktools=C:Program Files (x86)Microsoft SDKsWindowsv7.0ABin
set tools=Z:DevelopmentTools

cd ..win
"%VWHOME%packagingwinResHackResHacker" -addoverwrite "%VWHOME%binwinvisual.exe", myapp.exe, mgc.im, 332, 332,
"%VWHOME%packagingwinResHackResHacker" -addoverwrite myapp.exe, myapp.exe, "splash.bmp", bitmap, 324,
"%VWHOME%packagingwinResHackResHacker" -addoverwrite myapp.exe, myapp.exe, "myapp.ico", icon, 323,0
"%VWHOME%packagingwinResHackResHacker" -addoverwrite myapp.exe, myapp.exe, myapp.txt, 325,325,

"%sdktools%rc.exe" version.rc
"%VWHOME%packagingwinResHackResHacker" -addoverwrite myapp.exe, myapp.exe, version.RES, ,,
"%sdktools%rc.exe" manifest.rc
"%VWHOME%packagingwinResHackResHacker" -addoverwrite myapp.exe, myapp.exe, manifest.RES, ,,
"%tools%upx304wupx" --best myapp.exe
"%sdktools%signtool" sign /a myapp.exe
cd ..buildscripts

package.cmd

rem Set version number for myapp
set vn=4.00.00
cd ..
rem create compressed files from the source folders

"C:Program Files7-Zip7z" a -ttar linuxPPC-%vn%.tar linuxPPC -r0
"C:Program Files7-Zip7z" a -tgzip uploadslinuxPPC-%vn%.tar.gz linuxPPC-%vn%.tar -aoa
del linuxPPC-%vn%.tar

"C:Program Files7-Zip7z" a -ttar linux86-%vn%.tar linux86 -r0
"C:Program Files7-Zip7z" a -tgzip uploadslinux86-%vn%.tar.gz linux86-%vn%.tar -aoa
del linux86-%vn%.tar

"C:Program Files7-Zip7z" a -ttar solaris-%vn%.tar solaris -r0
"C:Program Files7-Zip7z" a -tgzip uploadssolaris-%vn%.tar.gz solaris-%vn%.tar -aoa
del solaris-%vn%.tar

"C:Program Files7-Zip7z" a -ttar hpux11-%vn%.tar hpux11 -r0
"C:Program Files7-Zip7z" a -tgzip uploadshpux11-%vn%.tar.gz hpux11-%vn%.tar -aoa
del hpux11-%vn%.tar

del uploadsmacx-%vn%.zip
"C:Program Files7-Zip7z" a -tzip uploadsmacx-%vn%.zip macx -r0 -aoa

move myapp.exe ..

set vn=

rem delete copied files from the packaging folders
cd buildscripts
call cleanfolders
rem DONE PACKAGING

cleanFolders.cmd

rem delete copied files from the platform folders
rem hpux11
del hpux11*.rtf
del hpux11help* /s /q
del hpux11messages* /s /q
del hpux11system* /s /q

This article is work-in-progress, I welcome suggestions and input.

(article was never fleshed out, included here for completeness)

Domain Driven Design has become, to my great joy, a mainstream practice. Various excellent books have appeared on the subject, but for some reason I have constantly felt I missed something essential - or at least essential for me. So I decided to write on the subject myself.
This article attempts to bring something entirely new into the subject of software development, or at least something that is, in my view, severely lacking from almost every book on the subject. We are living in a time when software is becoming increasingly essential in our society. The essence of software however is not lying in its technical applications, or the expertise needed to write software in programming languages designed for technical purposes. In fact, to remain focussed on that aspect of software will prove to be detrimental to further evolution. It will, even more than it is already doing, slow progress in a way that to me is unacceptable. I do not claim to have invented new thoughts or to have the copyright on the ideas you will encounter in this book. On the contrary: I am convinced most if not everything you will read here has been said in some form or another by other people. I will even endeavour to give honour where honour is due. My ambition will be to mix these various thoughts into a new amalgam, and by doing this in a way that while exposing them they will immediately be applied in practice, so they will win in power and impact.
Enough on the introduction. Let's commence.

Typographical conventions

Footnotes are numbered with a closing bracket: 1). These can be found at the bottom of the page and relate more to the content of the story.

Smalltalk source code is in syntax coloured sans-serif font (not fixed-sized as in most other programming languages examples in other books - this has been the custom with Smalltalk code since the publication of the Smalltalk books by Adele Goldberg). I have added the custom as introduced by Pugh and Wilff to print the names of methods in bold.

Introduction of the MijnGeld case study

For the practical aspect of this article, one case study will be used: that of a bookkeeping program. While read this program will grow to a fully functional (and of course freely downloadable from my website 1) piece of software.

So what will this bookkeeping program do?
At first I want to keep things as simple as possible, but not too simple. It would be too simple to make a program that would record my bank transactions, and offer reports on my income and spending. Why would this be too simple? Because it would lead to a piece of software that is dead from the start: it does nothing, it only records and playbacks.
It would not be software as I define it – it would be hardware, a video recorder, a phone. There is nothing more pathetic than software trying to be hardware.
So the bookkeeping program will not be a recorder. What then? An essential characteristic of living software is that it moves by itself. It will have a goal in life, it will take decisions and change itself by doing that. In a way, but this will be elaborated upon much more later in the book, software writes itself. It should not be the programmer writing it.
The goal of the bookkeeping software will be simple in the beginning: it will do its utmost best to keep the balance of the account zero. Not positive (I will not yet want to save), not negative (I will not yet want to have debits). In the course of writing the book this functionality will grow, and we will pay special attention to the way in which this kind of growth is managed.
Because the software is a living entity, or will be, the name “bookkeeping” is no longer appropriate. We will use another name for this software, one I think is very appropriate indeed: My Money, or, in Dutch: MijnGeld. This name is more appropriate because it designates the piece of evolutionary software we are going to work on as an entity in its own right that mirrors another entity in the outside world: my financial assets. And I guess many of you will agree that money is in itself already an almost living entity with very interesting biological characteristics.
The theory of mirroring is introduced in the main text in the first chapter, The essence of software.

The essence of software

I cannot really take off without making a best effort at conveying my thoughts on what comprises the essence of software. This chapter will contain a fair amount of philosophy, and I have done my best to write it in such a way that, if you so choose, you can skip this chapter without being unable to appreciate the following one, and later return to it in order to appreciate the approach even better.

The biological metaphor

We’ll say it again: software is not a technical thing. The closest metaphor could be the one Kevin Kelly uses 2 in defining technology as a new life form. Maybe it is true as he says that the biological metaphor for technology has become a cliché, but in my experience the consequences of thinking in this metaphor are seldom applied. Software is a complex, moving thing, never at rest, constantly adapting, morphing itself to work better or to offer more functionality. It is the spirit in the machine, itself it cannot be grasped, and it resists manipulation. We may devise as much controlling mechanisms as we want, in our software factories, assembly lines, software design methodologies or project management, but all will be in vain: software cannot be controlled. The only thing we will accomplish is a piece of software that consists mainly of controlling routines, and only an almost negligible portion of end-user functionality.
The impossibility of control in complex systems is systematically denied in modern culture. We live in an age where we prefer to live convinced of our power over life and nature. We are in control, and if and when we are not, it is only a matter of time until we are.
An example of the consequences of this mindset is the recent economic events leading to the worldwide collapse of financial systems in 2008. For years a economic belief system has ruled which declared economic processes to be completely controllable, and in fact even dared call itself “the final economic theory”. Economical systems are interesting examples of complex systems. And as such cannot be controlled or steered.
Another example is the weather, for which we spend millions to set up better prediction models. It will be in vain, as meteorological scientist should be the first to admit. Were it not they have a vested interest in those funds…
Gregory Bateson in his book (or rather a compilation of a series of papers) called “Steps to an Ecology of Mind” applied the biological metaphor to the area of thinking and mind. I often refer to the writings of Gregory Bateson, because his research is of special interest to people attempting to make computers to be actually useful. The whole area of Cybernetics was built on the groundbreaking work of Bateson and Norbert Wiener, and has been a first incarnation of the field of computers and software. To see the mind as a complex system avoids the vague and emotion-loaded notion of consciousness, but nevertheless succeeds in creating a wonderful and rich image of the uniqueness of our mind.
The extent to which the ecological system is a complex system is one I want to give a little extra attention to.

Mirroring

The biological metaphor is one common thread in the approach in this book. Another important one is mirroring. Some recent scientific theories claim than humans started to make use of language to communicate about a million years ago, and that the very process of employing language in a specific way that differs in a fundamental way from how animals communicate, has defined our physical as well our mental layout. Another research has shown that our brains, not only our brains but brains in general in all animals, contain specific neurones called “mirror neurones”. One can see these neurones as specialised devices to aid the organism in connecting with the surrounding world.
In fact a whole scientific discipline has evolved around this theory, linking several scientific disciplines in an effort to understand more about what it is to be human, with interesting results in areas like autism therapy.
A mirror is a device that reflects. Our mind is in essence a mirroring device: we are able to constantly reflect the outside world in our inner, mental world.
This inner world is not a “perfect” reflection, that is it is not merely a replica of the outside world. It is in a sense more than that: for example our brains seem to be constantly at work “predicting” the future .
One of the most intriguing writers that moulded my thoughts on the subject, is a Dutch psychiatrist, professor J.H. van den Berg. He became rather famous (in fact more famous internationally than in The Netherlands) with his first book, Metabletics, translated in English as The Changing Nature of Man . Jan Hendrik van den Berg introduced me to one of the purest phenomenological approaches to philosophical issues similar to the early Husserl. His writings showed me how intricately our observations are connected to our thoughts, our image of the world. This image is nothing else but the mirror of the world we create in ourselves.
This book is a mirror in several senses:

1. it mirrors my thoughts on the subject of computers and software
2. it mirrors in itself the theoretical aspects of those thoughts into the practical application of MijnGeld
3. it mirrors, as you read it, your own view of the world, and hopefully introduces some few gateways to enrich that view or that world

An important characteristic of a mirror is that it is not an exact replica of the real world and should not attempt to be. I will not go deeply into this aspect here, except from mentioning that a mirror reflects the real world, and in reflecting will change a few things. It is easy to overlook, but a real mirror for example will exchange left and right: the face that looks at you in the mirror is not the face other people see! In a similar vein the software mirror of the thing is different in small but important ways. This will be referred to and further elaborated upon later in the two main patterns:

1. The Time Reversal Pattern
2. The Active-Passive Pattern

Software turns things around!

Quickening

We have talked about objects that are reflections of outside world concepts or things. We have tried to start describing these objects by defining them to be living entities, doing things on their own, and collaborating with a great deal of other objects to do their thing in an appropriate way. I will repeatedly come back to this image, this way of looking at software. Whenever you think of your problem domain, and how to morph it into a software program, you should try to think of this swarm of objects, this ant-hill of ant-like software components, each on its own so simple, but al together able to move mountains.
But especially for those of you (which unfortunately will probably also be most of you…) already polluted by the machine-metaphor which is prevalent in computer science, this metaphor may sound interesting and even alluring, but impossible to understand in a way that is concrete enough to apply in practice.
So let’s start play.
What does a “living” object look like?
One way of exploring this is by comparing “dead” objects (which, unfortunately, are the objects most of us software programmers are accustomed to) with “living” objects.
An example of a dead object is a bank account like this:

Entries into the account are made by Account::addEntry(newEntry).
Why is this a “dead” domain? You can easily detect this property by noticing that things are done to the objects, not by the objects. They are passive themselves, they do not act on their own. They are, so to say, passive victims of whoever fancies to send them certain messages like addEntry().

An example of a domain which is a bit more alive is the next one:

In this model a bit more behaviour is introduced. The Transaction has two entries (a so-called two-legged transaction). The behaviour is in this class Transaction. It “executes itself”, that is:

• it is told some things (passive: amount, from account and to account)
• it does some things (active: do some things with the accounts)

This can be further explained by the code of method fromTo (in Smalltalk, which has keyword syntax for multi-argument methods, this becomes from:to:)3:

from: firstAccount to: secondAccount withAmount: anAmount
“Create the entries in both accounts for both legs of the transaction.”

| firstEntry secondEntry |
firstEntry := Entry amount: anAmount negated.
secondEntry := Entry amount: anAmount.
firstAccount addEntry: firstEntry.
secondAccount addEntry: secondEntry

You may have noticed that the complete passivity of objects in our first attempt has improved. Not much, I agree, but some.
This may not seem much but there is actually quite some improvement. An important aspect of object-orientation is encapsulation. A transaction is told some basic things, but the manner in which it will subsequently perform its responsibilities is invisible from the outside. This can for example be illustrated by the necessity to deduct some transaction fees for each transaction. This could be implemented by adding one line to the previous method: 4

from: firstAccount to: secondAccount withAmount: anAmount
“Create the entries in both accounts for both legs of the transaction.”

| firstEntry secondEntry |
firstEntry := Entry amount: anAmount negated.
secondEntry := Entry amount: anAmount.
firstAccount addEntry: firstEntry.
secondAccount addEntry: secondEntry.
self deductTransactionFee

You may now appreciate this one level of added indirection since we can now change behaviour in one place, and all originally involved parties will not need to change in any way.
But is this one step enough? Can we take our metaphor of living objects further? Because you may observe that although the second solution is a little better, it is still far removed from being “alive”, whatever that may mean.
We will take a bold step here, of which I will hope that you are willing to follow me here.
I will introduce time. And memory. Something living entities possess.

Living in time

Living objects have memory, an essential attribute to learn.
Introducing time into the story can be very simple:
timeLine <SortedCollection of: Event>

Smalltalk Syntax

This is a short chapter, as it should be. Programming is difficult enough even with a minimally complex language. With thanks to Travis Griggs.
There is actually two parts to Smalltalk code:

• The language syntax
• The structure of the code base (classes, packages, etc.)

Language Syntax

As many have said before, the Smalltalk language syntax is almost ascetic. Everything you encounter (well, almost everything ;-)) is messages sent to receivers.

Code structure

Different Smalltalk dialects have decided on different approaches to structure the Smalltalk class library. Depending on your dialect of choice you may encounter packages like in Java, Namespaces like in .NET, bundles, parcels, categories and what not.
For this book we can discard these differences for the most part. The important thing is classes containing:

• Methods
• Attributes, called Instance Variables in Smalltalk

Bibliography

Goldberg, A. and D. Robson, Smalltalk-80 : the language and its implementation. Addison-Wesley series in computer science. 1983, Reading, Mass.: Addison-Wesley. xx, 714 p.

Bateson, G., Steps to an ecology of mind; collected essays in anthropology, psychiatry, evolution, and epistemology. Chandler publications for health sciences. 1972, San Francisco,: Chandler Pub. Co. xxviii, 545 p.

Waldrop, M.M., Complexity: the emerging science at the edge of order and chaos. 1992, New York: Simon & Schuster. 380 p.

Deacon, T.W., The symbolic species : the co-evolution of language and the brain. 1st ed. 1997, New York: W.W. Norton. 527 p.

Nehaniv, C.L. and K. Dautenhahn, Imitation in animals and artifacts. Complex adaptive systems. 2002, Cambridge, Mass.: MIT Press. xv, 607 p.

Hawkins, J. and S. Blakeslee, On intelligence. 1st ed. 2004, New York: Times Books. 261 p.

Berg, J.H.v.d., The changing nature of man; introduction to a historical psychology, Metabletica. 1st ed. 1961, New York,: Norton. 252 p.

Fowler, M., Analysis patterns : reusable object models. The Addison-Wesley series in object-oriented software engineering. 1997, Menlo Park, Calif.: Addison Wesley. xxi, 357 p.

Footnotes

• 1 The download link is on my website: http://www.robvens.nl but note there are two versions of the software: one that is and has been used in production for many years, and the other which is from this book and very much evolutionary. The first one can be found on another site: http://www.sepher.nl
• 2 http://www.ted.com/index.php/talks/kevin_kelly_on_how_technology_evolves.html
• 3 For those unfamiliar with Smalltalk syntax, take a short trip to 5: Smalltalk Syntax
• 4 I will briefly mention an important pattern here which I explicitly did not apply, namely the Add, Don’t Modify pattern. That is, if this code would have been in production I would refrain from modifying the code in way I did it here, but create a wrapper solution that would leave the original code untouched but added the desired behaviour elsewhere. More about this pattern later.

Op 7 februari heb ik op EngineeringWorld 2009 een presentatie gegeven over Smalltalk en Seaside, genaamd "Back to the Future with Smalltalk", met vooral een focus op de lessen van het verleden. De dia's van deze presentatie zijn hieronder als video te bekijken. De video's van Apple zijn ingekorte versies – bij het afspelen is geluid wel handig.

Adriaan van Os heeft wat foto's gemaakt. Het publiek bestond uit een aantal Smalltalkers, maar ook tenminste voor een derde uit mensen die volkomen onbekend waren met Smalltalk en Seaside.

Hieronder de directe links naar de video's in de presentatie. Geheel onderin de dia's van mijn eigen presentatie.

Just wondering: what would you think would be the Slashdot response to an announcement like the following. Note that this is an imaginary post.

A new open platform for devices is in the making.

A group of several tens of developers are working hard on a new open platform that is an alternative for Android.

But while Android is targeting mobile devices and will include an operating system, middleware and key applications, the MOSQ project is actually delivering a system that is targeting mobile devices, smartphones, ultra-light computers, laptops, desktops, mainframes, set-top boxes and what not. And it includes more: a complete embedded development environment is part of the system, making it much more open than the Android system which needs an SDK, usable only on a developer machine, and requires knowledge of Java, C, and C++ to develop applications in. The project is well under way to be deployable on the Apple iPhone as well, completely replacing the Apple software, or behaving like a more adaptable citizen by running on the iPhone operating system.

The system is not only open, but free of costs and licensing as well. The development community behind MOSQ is betting its business case on the selling of services and applications, comparable to the AppStore on the iPhone.

Fictional Slashdot announcement

Though not called WALL•S by Michael Haupt who posted this blog, the little NXT robot in the picture immediately reminded me of WALL•E. So meet WALL•S, the first robot that actually speaks and understands Smalltalk!

Some of you may know that Smalltalk originally was quite popular in the embedded world. Tektronix for example ran Smalltalk as their software for the oscilloscopes, running entirely in its own universe without an operating system to handicap the power of Smalltalk.

We also know that hardware power has evolved exponentially according to Moore''s Law. It is generally understood that software power does not follow this law at all, lagging behind so much that we still feel our computers are too slow. But few realise that Smalltalk has hardly grown to become slow and unwieldy!

So using Smalltalk as the semantic system of a robot to me feels almost inevitable: of course this should be done! (and, by the way, on the iPhone and GooglePhone as well!). Nice research project by Martin Beck!

• 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.

The Java story has many parallels to learn from, and is currently experiencing problems that may well be signalling its downfall. But one thing Java has been able to survive, is the immense growth curve in 1995 and following years. Java did not crumble, and the main reason for this was that two (and this is important: not one) large companies, namely IBM and Sun, were massively pouring their assets into Java. Interestingly enough did IBM, while having declared allegiance to Smalltalk only a few years before (which resulted in the VisualAge suite of IBM products, all Smalltalk applications!) make this move on the corporate level already at the beginning of 1994, when Java was only in the design stage at Sun! Now I am not saying that unless we can find two large companies to pour assets into Smalltalk we will not survive the next growth spurt. In fact I will actively resist such an effort, because I think there is a better way. A 21st century way. A new way.

Smalltalk has reinvented computing, many times in fact. Smalltalk can also, in a way, reinvent the computing business. Aspects of this can be found in secondary properties of the Smalltalk experience, from which we have in the computing community as a whole, received agile processes, test-driven development, empowered teams, object oriented programming and design, to name a few. Smalltalk bigots may complain that test driven development in Java is crippled because it is not Smalltalk, but in fact it cannot be denied that the Java programming effort has immensely benefited from these Smalltalk-originated practices that are not a direct part of Smalltalk as a programming language. Which is why I name this the Smalltalk experience.

Now let's raise this experience on to a different level: the business level. Aspects of this can be found in the Google business model. They provided a service for free that the customer wanted. They founded their financial model on the secondary aspects, the advertisement world. The search engine was the carrier wave, the advertisements income the modulation on it. In a way this is what the internet has been doing all the time. Money cannot be made by the infrastructure itself, and in fact I will advocate providing this to the world for free. But the services on it are making the difference and paying the bills. Smalltalk as an experience has for some reason attracted empowered teams, which exhibited many of the behaviours of empowered teams that result in success, often exceptional success. Alan Kay has talked about how 5-person teams like these can produce the equivalent of 500 person teams that do not have this empowerment. A business model can be harvested from Smalltalk, and in fact, although this cannot be directly traced to Smalltalk (I think this can more properly be attributed to what might be called Zeitgeist), we are already seeing this business model gathering successes all over the world.

Examples of this model can be found in the Joomla world. Joomla itself is an open source and free tool to build web sites, built itself in a dynamic (and standardised) language, PHP. Around this base (the carrier wave) has sprung up a whole ecosystem of add-ons and services (the modulation), where the money is made. But this is not a company-concentrated, multi-million dollar multinational bully making this money and driving the effort. It is a community-driven effort.

An equally valid example of this new business model is the Toyota community structure. It has been some years ago I encountered a report about the turn-over sums in the software industry, which showed that that the total of small companies made more money than the total of the large companies like Microsoft, Sun, Oracle and such. I think this distributed but massive business model should be adopted for the Smalltalk business model. We do not see this now. Smalltalkers consistently contribute "goodies" to the community for free. But these goodies have a bad track record of being maintained. By providing a business model for "goodies" we can improve this track record.

Infect the Smalltalk community

The Smalltalk community has always been very strong. The spirit of sharing, so contrasting with the C world of reinventing the wheel and the not-invented-here syndrome, has been permeating the community from the start and still is one of its main driving forces, from the start of the Smalltalk Archives hosted on the University of Urbana-Champain, one of the Smalltalk centres in the world. But the community as a whole is totally unequipped to manage the coming deluge of success.

The fact that it is fragmented is not the main flaw I think. The various mailing lists have some overlap, although not enough, and keeping up with the Squeak and the VisualWorks mailing lists alone may be asking too much from your average working day. We may certainly benefit from some kind of syndicating effort, separating environment-specific communications from Smalltalk-general stuff. But the main flaw is that there is no concertation. I want to introduce a proposal for this thing I call concertation. It is an appropriate term I think, because what we want to do is make music to rock the planet. But we will create pandemonium if there is no concertation. The only effort remotely resembling this at this moment is STIC, the Smalltalk Industry Council. But, and this should have been a sign on the wall, STIC has been stubbornly ignored by the Smalltalk community as a whole (and maybe vice-versa as well…). It has been more like a clique of Smalltalk companies, and the influx of success in these companies now and in the near future will create politic unrest in STIC that might be its downfall. And if that may not kill STIC, the lack of community support will. For this to change nothing less than a massive infection is needed. An infection with a common belief in the future, the power that Smalltalk can provide, an infectious enthusiasm that will create a synthesis where we direly need one.

The tone of voice

For a while I considered changing the tone of voice in this blog, because I usually detest cheap tricks to draw attention to blog articles by employing threatening or negative language. It is so easy to criticise and predict disasters. I decided to keep my original approach, but I want to postscript that by emphasising, yes, the problems we are facing as the Smalltalk community are quite serious, the opportunities are equally amazing. We are moving into an interesting future. Let's be part of it.

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.

It will of course be called the Stablet. It will contain a multi touch screen, which by the way will be running with probably no modifications on the iPhone and the Google Phone (or any other mobile device for that matter).

The ease of third party extensions should be a prime goal for this system. This will create a massive community of developers making money with services or small shareware applications licensed for a few dollars per user. No need to learn code and compile, just play around with your ideas, see it in action as you go, tweak it here and there, in a language that is simple by design.

What we really need for this is an unbiased comparison of the two platforms, Smalltalk and Linux. What are the various advantages/disadvantages, and even disadvantages that viewing at it from another angle can be advantages (like the old complaint "programmers do not understand the Smalltalk syntax because it is too different").

We need centralised coordination of the effort, but the effort itself should be distributed to the max, making use of the vast potential of Smalltalk programmers out there, old or new.

We also need investment resources, someting which I am confident we will be able to get once we get our story straight. We can show that what we can do with Smalltalk can never be matched by any other environment!

Let's rise to the challenge!