Re: Robustness Check and "A growing body of ad-hoc analysis solutions"

[glen e. p. ropella]

At 01:50 PM 7/13/99 +0200, you wrote:
>In the short term however we must try to weigh power, standardization
>and flexibility against 'user friendliness'. This is the eternal
>question: is Swarm a tool for the mainstream which includes people which
>don't want to invest hundreds of hours in learning new languages,
>software and operating systems?
>
>Again, in practical terms, the design paradigm should take note of what
>is sound about the ObjectLoader approach. It is admitedly ad hoc and
>incompatible, but couldn't be simpler to use. You have a simple  ASCII
>file format for loading and saving, and the user can drop in a one liner
>to the code which does all the work. 

This point is worthy of alot of thought.  It's granted that ObjectLoader and
the @begin/@end syntax is intuitive and easy to learn; but, don't gloss
too completely over the fact that there are alot of assumptions embedded
in ObjectLoader that it might not be wise to forget.  One thing that was made
painfully clear to me in my recent exercise was that, with ObjectLoader,
I default into providing incomplete parametrizations for whatever object
I'm loading.  E.g. Say I have an object that has instance variables: [X,Y,Z].
With ObjectLoader, I can provide values for [X,Y] and leave out Z and 
it, by default, accepts it and initializes Z via the normal createBegin
createEnd process.  This is *great*; but, it's a hidden assumption.

Imagine if I had intended to initialize all the object's instance variables
with the ascii file; but, was lazy about installing the record in the file
at the same time I installed the instance variable in my object.  (This
isn't that outlandish an error to make, btw. [grin])  I get unexpected 
behavior until I debug it down to the point where I finally remember that
I have to initialize the new variable with a record in the ascii file.

Now, with the setup that Marcus et al have in Swarm, I get a kind of
completeness check by using the Archiver tool.  Swarm actually 
recieves the specification of the object via the lisp (or hdf) that it
takes as input.  (I'm talking in generalities, here; this isn't to be 
interpreted as either the intent of the Archiver nor a purposeful
feature.)

What this made me do was explicitly back off and use the basic 
serialization tools rather than something as abstract as an 
"ObjectLoader".  I can imagine this kind of distinction being useful
in a pedagogical context for explaining what serialization is, why it's
useful, and for launching into some talk about distributed computing.

But, even if one doesn't want to use it in a pedagogical context, it
is certainly important to Swarm's overall purpose of making a Swarm
model into a explicitly clear statement of what one really intends.
ObjectLoader forces upon us an ambiguity in the purpose of an 
initialization (or snapshot) file.  And ambiguity is usually bad in
simulation unless it's a very explicit ambiguity (like the permuted 
list walking).

>Looking ahead to Swarm 2.0; once we introduce a new front end
>programming language (Java) the original point 'let's all talk in terms
>of the same language and objects' is moot. 
>
>This is a Bad Thing, because the intent was to help tear down the Tower
>of Babel which is computational modeling. 

Well, part of the problem, here, is that Java isn't a modeling language.
Neither is Objective C.  Swarm targets  the construction of a tower of babel
in the sense that we want to be able to speak in *some* generic 
modeling language.  Schedules, actions, objects, zones, and swarms
was intended to be the common language.  Whether you use Java 
or Objective C as your medium is irrelevant.

Given, of course, that we accept that a tower of babel is a good idea. 
Apparently, there's been some debate about that. [grin] Obviously,
what we really want is a stigmergic crystalline structure rather than a
tower.  (Ahhh, a "nest"... yeah, that's the ticket.)  Swarm attempted to
build such a beast via abstraction (and then had to come up with the
create-phase customization to get past the run-time hit of general purpose
objects).  So, how about calling it the nest of babel? ... or how about the 
babel deposition? ... sounds like a Robert Ludlum novel.

>However, experience has shown that discussion in the Swarm community is
>usually focused on two widely seperated levels of abstraction. The low
>tech (as in 'help me to install', 'help me to debug this routine') or
>the high tech ('so what is agent based modeling all about?'). 
>
>The reason for this development is perhaps that people are not
>fundamentally interested in looking at actual code, the key is in the
>presentation of both implementation and results at the proper level of
>abstraction. IMA, MAML and the work that the hive is doing on backend
>interfaces to standardized languages and data formats is of course
>instrumental in this effort.

This is true, that people aren't fundamentally interested in looking
at code.  But, I don't think that's because they're really less interested
in the code than they are in the teleological basis for a model.  I think
it's because of the wide chasm between code and purpose.  What we
need is an encoding language that can be as unambiguous as 
programming languages but more directly reflects the purpose of any
one section of the encoding.  In other words, we need to provide a bridge
between those of us who think that the "code is the documentation" and
those of us who think that the code is just the implementation that needs
to be augmented by a description of the code.  This is what Swarm is 
all about.

The fact that our user community exhibits this split between super 
low level tech talk and super high level over-generalization is not 
because of the language we're using (ObjC or Java) nor because of 
the fact that Swarm is rough around the edges.  It's because Swarm
is trying to bridge these two domains: the programmer and the 
modeler.  I think it's a natural and Good Thing to have this kind of 
split personality.  As Steve Railsback pointed out in his talk at the 
last SwarmFest, at the moment, it really does take two personalities
to successfully apply Swarm, a programmer and a modeler.   However,
Swarm, like no other tool I've seen, makes the negotiation between
the programmer and the modeler a much less painful process.  And
to that extent, we're at least headed in the right direction, even if we
have many more miles to go.

glen

--
glen e. p. ropella =><= Feeding the hamster wheel.  Hail Eris!
Home: http://www.trail.com/~gepr/home.html      (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.
                  ==================================