Swarm futures (LONG)

[Benedikt Stefansson]

Greetings,

After the last issue of our trusted Weekly Pheromone, and due to
some recent experiences in Swarm development, I've been pondering
what would be at the top of my wish list for Swarm.

To explain what I mean I've felt the urge to unleash this humongous
message on the unsuspecting Swarm-Support community. My appologies in
advance (and hopes that someone will find it in his heart to read this
through and tell me that I am full of...)

So what would be item 1.0 on the wishlist? Portability and platform
indepence. Both seem to be crucial for Swarm beginners, power users and
evangelists.

Let me offert two main arguments in support of this.

On one hand, since ancient times one of the strongest selling points of
Swarm has been scalability. Prototyping a simulation with a few hundred
agents on a 16 Mb Linux box is fairly straightforward, running extended
batch jobs on the same box with larger agent populations is very
tedious. Serious simulations demand serious resources, i.e. faster CPUs
& more RAM which means that the Linux box user finds himself migrating
to the Sparc station and the Sparc station user starts worrying about if
he can port his model to the AIX cluster etc.

So you could chalk this reason up as the 'power user imperative'

On the other hand there are numerous users out there that have not had
the chance of getting hands on experience with Swarm because of the
user-unfriendly combination of C/ObjC, GNU Debugger & Emacs as a
development environment. These people would love to be able to learn
Swarm and prototype their models with a  friendlier combination of
compilers and debuggers. Providing a version of Swarm that runs on
Windows95/NT or MacOS, at least to enable proof of concept simulations
would obviously make the potential user base wastly larger. 

Call this the 'SwarmLite imperative'.

Now I am _not_ suggesting a major rewrite of Swarm or abandoning the
current platform. So here goes my suggestion for how we might make Swarm
truly portable. Smarter people than I (read: Swarm developers) should
jump in at this point and tell me if this is farfetched and totally off
the wall:

Firstly, to the untrained eye it seems plausible that the Swarm kernel
(i.e. sans GUI) could  be ported to any Unix architecture which supports
GNU + ObjC, in addition to NT, MacOS and soon Rhapsody (the Mach-kernel
+ NeXT Objects based future MacOS). 

Correct me if I am wrong. 

(As a footnote to this Metrowerks expects to have Objective C support
added to the CodeWarrior C compiler for Mac OS by May 1997.
Interoperability between Objective C objects, and C++ and Object Pascal
objects in will be offered by September. Metrowerks runs on Macs but
compiles code for Macs, Be and Intel) 

The problem remains the GUI, X-Windows dependency & Tk/Tcl + BLT. Again
to the untrained eye this seems to be a source of most of our ever
popular  installation blues (See: Swarm-Support mailinglist
1995-present).

So why not port the GUI to Java? And I mean _only_ the GUI classes, not
the trusted old Kernel.

This would give us the killer combination of executing the ModelSwarm on
the existing SwarmKernel and visualizing the output either on the server
or from a remote kernel. We could of course still have 'SwarmClassic'
running in X-Windows environments, but the Java GUI would be an option
for Unix and these (imagined) versions of Swarm for NT and Rhapsody.

SwarmJavaGUI would also open the door for client/server based
operability in Swarm (publishing simulations through websevers). 

So I guess the bottom line of this tedious message is that 

a) The best way to ensure the future of Swarm is to increase the
potential and actual user base, by offering both high end and low end
users a choice of development platforms and the ability to migrate
resource intensive simulations between high end and low end CPUs 

b) This might be accomplished without sacrificing the current platform
and with a reasonable amount of resources.

There it goes. Perhaps some kind Swarmer can tell me if there are any
glaring holes in this argument.

-Benedikt

------------------
Benedikt Stefansson                 address@hidden
Center for Computable Economics     Tel. (310) 825-1777
Department of Economics, UCLA       Fax. (310) 825-9528
Los Angeles, CA 90095-1477          http://cce.sscnet.ucla.edu