[Swarm-Modelling] dynamic state and behavior for ABM and GP

[Marcus G. Daniels]

Matt Murphy wrote:
> I think a language like Ruby
> would be even simpler for those new to programming.  Ruby has the
> following nice features: 
[..]
> - extremely dynamic, makes it easy to add new behavior to individual
> instances, whole classes, etc., at runtime.
I did a brief review of what genetic programming toolkits are in use 
these days, as the issues there are similar if not the same to ABM (not 
in general, in this context).  Amongst a bunch of C++ and Java template 
oriented GP packages, the only current systems based on a dynamic & 
interpreted language use Ruby, e.g.

http://rubyforge.org/projects/drp

Also, as far as I can tell there hasn't been much fundamental work done 
for just-in-time compilers (JITs) for evolving objects and languages 
(lifecycle changes, etc).   I did find this commercial system that 
claims to evolve machine code, which therefore performs very well:

http://evonet.lri.fr/evoweb/news_events/news_features/article.php?id=119

One problem is that the two big JITs from industry (CLR and JVM) is that 
they are currently oriented toward static languages, not languages that 
are inherently in flux.   However, there is another substantial project 
that addresses this.  It's called Parrot:

http://www.parrotcode.org

There's a Ruby implementation for it called Cardinal and other languages 
in various states of completion. 

If there were a good, fast embeddable virtual machine available that 
could transform `model languages' into native code without constraining 
the model languages significantly, nor precluding use of typical 
programming languages, I think it would be a great win.   It would mean 
everything from web browsers to giant clusters could provide a uniform 
interface for executing mobile and evolving code.   Uniformity is of 
practical importance for migrating and saving long running jobs, and its 
almost impossible to do this reliably on Unix.  

Then for clusters and supercomputers, it would be possible to make  
minimalistic distributions for compute nodes, along these lines..

http://www.cs.utah.edu/flux/janos

..the point being to minimize the number of components on the system 
that could break.  On large clusters one thing or another is always 
breaking just because there are so many components.  A small 
close-to-the-metal microkernel dedicated to accepting [model] byte code 
might prove to be more reliable..  And when the sysadmins say they need 
to power cycle a few dozen or thousand compute nodes, would be great to 
pull the whole running model out and let it progress slowly in a nearby 
smaller computer or just chill in a web browser.