The Swarm space (was RePast (another agent toolkit) released)

[glen e. p. ropella]

At 01:52 PM 1/31/00 -0500, you wrote:
> been avoiding it for the same reason.) I think the community needed a more 
> traditional swarm like all java solution--I've been a little surprised 
> that swarm hasn't been more anxious to provide it, though I can totally 
> understand their choices given limited resources.

I realize you didn't intend to broadcast this, but felt I should
pursue it anyway.  What evidence of anxiety haven't we shown about
a pure-java version of Swarm that you would have expected to see?

What the hive has been doing is *both* maintaining the old interface
(which is ObjC) and opening up access to new interfaces (Java and
Scheme as well as R and HDF).  Backwards compatability and the
pursuit of a stable API is *very* important.  Granted they could
have forked the code and re-written the API in Java.  Or they could
have re-written the whole thing, including the API.  But, that is
near-sighted and counter productive.  A tool that is intended to be
used for large and long-term projects has to show stamina as well
as open-mindedness.  Using the latest technological fad (like Java)
is a *good* idea because it allows you to navigate which parts of the
solution space that fad helps you build.  But, dedicating your
entire project to a fad that's less than 4 years old is *not*
necessarily a good idea, because it doesn't allow you the synoptic
perspective that taking an open approach allows.

A modeler can now build her models, using Swarm, with Java, ObjC, Scheme,
and XML.  (Though I wouldn't count on the usability of the last two, yet.)
Granted, those of us who have requirements for pure Java are not yet
satisfied; just like there are many others with requirements that prevent
them from using Swarm (like an underlying mathematical formalism).
But, as for pursuing Java (and even pure-Java), I think the hive has
done a remarkable job of being able to take advantage of new technologies
without risking the usefulness or existence of the project on those
new technologies.

Tools like aScape and RePast are wonderful pieces of our community
and, I hope, we'll be able to integrate them completely.  But, being
targeted for smaller purposes, both of those pieces have much more
freedom than the hive has.  The hive has as its charter to support and
develop a community that is larger than any one tool or technology.

For example, take Cody's aforementioned problem, that Swarm is on
too ethereal a footing for Ford to seriously consider investing
in it.  Ford is right! (Though we're steadily whittling away at that
argument!) Swarm isn't a traditional package or project.  It uses an
iffy proposition for distribution and licensing.  It has publicly
supported resources.  It's a grass roots project, meaning that the
requirements are emergent, rather than a designed-for-a-purpose (e.g.
Linux) project.  Etc.  All these are very good reasons for a technical
consultant to advise a corporation against doing any kind of sole-
sourcing based on Swarm.

This is why Chris, Doug, and I started SwarmCorp.  This is why,
Chris, Irene, Marcus, et. al. formed the SDG.  In order for a
device (in the widest sense of the term) like Swarm to survive the
due diligence process implemented by a software integration guy at
a company that's at a higher than CMM level 1, we're going to have
to *prove* that Swarm will survive fads, integrate with new technologies
that turn out to be more than fads, evolve with changing use-case
requirements, and, most of all, save the company some money.

So, I apologize if I seem like I'm ranting, here.  [grin]  But, I'd
like to know what more the hive should be doing to ensure this end goal
(proof of survivability, integration, adaptability, and efficiency) with
respect to Java?  I'm really asking, here, not just being rhetorical.  Give
us some feedback for what we should be doing!  Believe me, we'll listen.
We may argue beyond your patience[grin]; but we'll try extremely hard to
fold your requirements into the community's as a whole.

glen


--
glen e. p. ropella =><= Feeding the hamster wheel.  Hail Eris!
Home: http://www.swarm.com/gepr                (505) 424-0448
Work: http://www.swarm.com                      (505) 995-0818


                 ==================================
  Swarm-Modelling is for discussion of Simulation and Modelling techniques
  esp. using Swarm.  For list administration needs (esp. [un]subscribing),
  please send a message to <address@hidden> with "help" in the
  body of the message.
                 ==================================