Sunday, July 18, 2010

Smalltalk portability: Sport and Grease

There are many dialects of Smalltalk. The implementation of the language is very similar in them all (partly thanks to the ANSI standard), but it's not exactly the same. The differences mean that a library or application written using one Smalltalk dialect can not simply be loaded/compiled and run in another.

Let's say you developed an application using Visual Smalltalk and you now want to deploy it using Pharo. Most of the code will work fine in both Visual Smalltalk and Pharo, for example "OrderedCollection new" will do the same thing in both, but things like sockets, files, times and string parsing classes and methods are different in the two dialects. To get the application working in Pharo you'll need to go through all the code in the system checking for things which don't work the same way and fixing them. Changing code to run on another platform is called porting, and the result of a porting exercise is a second implementation of the subject system. A second body of code which will need to be maintained separately, so if you extend or fix a bug in the Pharo version you'll need to remember to make the same effective change (perhaps implemented a bit differently) in the Visual Smalltalk version. It is quite likely that such code bases will diverge over time. The cost of porting a system and then maintaing multiple versions of a system and them keeping then in step can be high; you may end up having to support them as distinct systems with separate lives.

Fear not. There is a better way.

Portability libraries are used to minimise the cost of porting an application. Portability libraries place the platform specific things behind a defined API. If a Smalltalk application is written to use only portability API(s) and 'standard' features it can be moved unaltered between Smalltalk dialects. Some applications have to use features which are peculiar to a platform, such as a GUI library, and such portions of a system must be ported and maintained the hard way, but many systems today can be, and are, written in such a way that they are completely portable between dialects using portability libraries.

Two such libraries are Sport and Grease. Both of these libraries emerged from the process of porting code between Smalltalk dialects, but each addresses a different segment of the differences between dialects, with surprisingly little overlap between them.

Sport was created during the development of OpenSkills applications such as the SkillsBase and Membership Management System. These applications are developed exclusively in VisualWorks and are deployed to run exclusively in GemStone. The work to get the applications to run in GemStone resulted in the creation of the OpenSkills portability library in early 2004, renamed to Sport (for Smalltalk Portability) in 2006.

Similarly, the Grease library came out of the desire to run the Seaside web application library on a variety of dialects. Initially the portability code was called simply Platform and was a part of the Seaside library from about 2005 triggered by the desire to run Seaside in VisualWorks. The Grease name was applied to the portability library in the latter part of 2009 when it became a shared library used by packages related to Seaside, such as Pier and Magritte.

Sport and Grease cover different areas with their portability APIs. Sport covers Sockets, Files, Time, Exception handling and utilities such as being able to explicitly test in which Smalltalk dialect code is being run in. Grease covers utilities for parsing, printing, encoding & decoding strings, delayed sends, common exceptions, utilities such as secure hash. There is some overlap, but not much. For example, Seaside expects the underlying HTTP server to deal with socket issues so Grease does not deal with sockets. Sport in turn does not have the extensive parsing and printing facilities found in Grease.

The longer term goals for both Sport and Grease are that they should go away to be replaced with standardised implementations of the various areas, e.g. sockets. But Julian Fitzell (the Grease maintainer) and I both expect that to take quite some time. Today, Sport and Grease together provide a mechanism where Smalltalk applications can be developed in a truly portable way.

To emphasise this, because it's quite a big deal, the exact same Smalltalk code for applications may run in many different Smalltalk dialects completely unaltered with the help of Sport and Grease.