Who keeps a (copy of) that old wrench?

[Sven Thommesen]

I recently suggested that SFI keep a copy of the previous version
of Swarm accessible at all times, and Manor agreed this was a 
good idea.

I think perhaps there is a larger question here for the whole Swarm
community to think about:

Swarm is billed as a new 'toolkit' for doing computer simulations. 
But while last year's hammer can still be used for all the same purposes
it served when new, the same is not true for software.

As we have seen recently, upgrading to a new version of Swarm required
an upgrade to at least two other supporting packages (BLT and libtclobjc.)
Next time, it's likely to be tcl and tk, and perhaps others. 

It also required a rewrite of every Swarm application: a Swarm 
application is dependent on the specific version of Swarm and the
supporting packages it was written under (and, for all we know, 
the version of the unix kernel as well.)

Now imagine the following scenario: I have just finished a dynamite
simulation in Swarm, and send the paper off to the journal of my 
choice (well, of my hope). 3 years from now, someone reads my 
published paper and wishes to REPLICATE my experiment.

I can of course send them the Swarm source itself, assuming I kept it --
but they then face the problem of either re-working my source to run under the
then current version of Swarm and supporting software [in which case
it is not clear whether we have a true replication; at least there is a great
chance of bugs being introduced during conversion], or finding
and installing the versions of Swarm etc. under which my simulation
was written.

If we as a community are serious about making replication of
our experiments possible, then by the nature of the beast old versions
of Swarm, tcl, tk, BLT, libtclobjc etc. must be saved along with every
Swarm simulation, *or* they must be available from some repository.

Since the current beta of Swarm is now good enough to do 'real' work,
this problem is sure to arise. Unless some other person/institution 
volunteers to be  a repository, I guess the natural candidate is SFI ... 

Comments welcome.

Sven Thommesen
UCLA Center for Computable Economics
Auburn University School of Human Sciences