Re: Swarm on Mac OS X? Anybody?

[Marcus G. Daniels]

>>>>> "WN" == W Northcott <address@hidden> writes:

WN> Of course what is really wanted is an Aqua/Quartz implementation
WN> of tk and BLT, or Swarm to go the whole hog to a Java GUI, but I
WN> think the latter is probably further off than the former.

Whole hog to me means a tightly-integrated cross-platform browser
environment.  Such an environment will be able to host web
applications that share information over the internet and are smart
about manipulating, displaying, and running agent-based models. 
(Swing is one technology that could serve this end, but it is far from clear
to me it is the optimal technology.)

I want to see a system in which domain-experts, non-programmers, can
independently and collaboratively evolve tight, specific and minimal
languages to describe the topics of their interest.  To evolve these
languages, modelers need be able to fool around in an easy-to-use
and responsive scripting languages like JavaScript or Python to find
how the mechanistic nitty gritty of agent rules need to work
(i.e. without compilation).  As parts of the puzzle start to fall in
to place, these insights need to be easy to move into the
architectural elements of the simulation, adding to whatever basic
initial structural assumptions the modeler decides to make.
Alternatively, a capability for decreasing confidence in model
components is needed, by `melting' them into mutable code, say.

For example, I can't see any reason why descriptions like "N agents
with distributed preferences for temperature living on a heat
diffusion space" needs to be described with a general-purpose
programming language.  You use a general-purpose programming language
when you don't know what else to do!  (Same goes for agent-based
modeling..)

A special modeling language, say IMA, can do many of these things in a
concise way.  IMA's design has semantics that make notions like "live
on", "populate", and "seek attribute in environment", etc. easier to
nail-down so that modelers don't have to recode them over and over again.

[Btw, in the e-commerce world, there's a popular server-side product
that combines the notion of cleanly-parameterized high-level
declarative XML description with nitty-gritty-coding-around-the-edges:
Java Server Pages.  This kind of incremental factoring is hardly a new
idea...]

And I _don't_ want to see `shortcuts' taken which preclude moving
these prototypes into high-performances chunks of native code, which
are _necessary_ for doing realistic models.  Along these lines, I want
to see a system in which modelers can easily bring in all the tools
they are familiar with if they so please.  Many of these applications
will probably be Windows based, and in case you hadn't heard Microsoft
won't be going out of their way to make Java easy for people.

As for cross-platform graphics go, I think in SVG will proliferate.
There's W3 candidate recommendation, a good implementation from Adobe
(with best-of-the-breed applications behind it), and the likely
realization of a completely open-sourced and DOM3/CSS2 integrated
implementation from Mozilla.  Factoring vector graphics off into a
declarative system like this is just an obvious way to improve the
quality and availability of dynamic graphical content on the WWW.

Really, if you have a second, grab the Adobe SVG 2.0 beta and take a
look at those URLs I posted.  That's just slow, interpreted JavaScript
moving the `agents' around but after you get rid of the graphics
overhead, it's pretty snappy..

The GUI stuff I'm working on now is based on Document Object Model
(DOM) browser technology.  In the first stages, it will complement
(via COM) the usual Tk-based Swarm GUI library.  This library is
already fairly portable, +/- new windowing systems like Aqua/Quartz.

Pragmatically, what am I saying?  Contributors are free to write
Swing-based contributions to Swarm if they like.  There's no conflict
with the COM/DOM/XUL/XBL/SVG work..  It will all play nice... or I
will make it.

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.