Re: [Swarm-Modelling] Announce: metaABM 1.0.0

[Miles T. Parker]

On Nov 22, 2007, at 2:03 PM, Marcus G. Daniels wrote:

> Miles T. Parker wrote:
> > All of the C derivatives are "pretty close" structurally and  
> > syntactically -- which is why I think an Obj-C or C++ would be a  
> > good next order target to shoot for
> How about JavaScript?  Mozilla's working on integrating the Adobe/ 
> Macromedia JIT into Firefox, so there's the possibility it will be  
> approximately as fast as Java in a few months.  Javascript is even  
> more mutable and dynamic than Objective C.  Also modern JavaScript  
> has useful features for ABM.  For example, there's a `yield'  
> operator so that one `for' loop can yield to another and back again  
> (much like a multilevel discrete event simulator, but simpler and  
> closer to the language).

Yes, to be clear, for the immediate concern I was not calling out a  
need for a good target language, but looking for good target ABM  
platforms -- from a technical and user-base POV -- so in that sense  
I'm not really concerned with general language features. From that  
lens, think of metaABM as an intermediate high-level language / inter- 
op protocol. You can create a) code generation that leverages any  
language/platform for implementation and/or b) DSLs, Visual Editors,  
etc.. that are translated into metaABM model. So in that sense, its a  
common broker that opens up all sorts of possibilities for  
collaboration on either end. Seen from that perspective, the Visual  
editor provided with metaABM and the Ascape and Simphony targets  
aren't really metaABM proper, but reference implementations of a) and  
b).

For example, if someone has a great idea for a little ABM language,  
they don't have to worry that there target platform is going to become  
irrelevant and they'll have to do all of the heavy-lifting all over  
again. This is all why I have felt (more and more) strongly that  
metaABM itself should not be tied to any particular platform, for  
political reasons if nothing else.

> Language integrated query is, I think, quite relevant to common ABM  
> tasks like an agent looking around its neighborhood, especially if  
> it is implicitly parallel!

Yeah, exactly..except that I think this is a deep representational  
issue much more than a target language/syntactical one -- I'm betting  
you'd agree. The parallel stuff is absolutly implicit in the design.  
If you look at the design of a typical metaABM rule, you have to work  
pretty hard to write a rule that *isn't* parallelizable (even though  
looking at the visual editor one might naively think that an ordering  
for sibling Acts that is definitely *not* the case -- and there are  
other analogous features.

I haven't written anything readable up on this yet, but that is  
exactly how I'm constructing the Act behavior stuff, and something  
that Nick and Tom and I have talked about quite a bit. The basic idea  
is best illustrated from an observation -- hmm..I'm going to have to  
find the attribution, Fowler? -- that RDBMS were the first truly  
successful examples of codegen. If you think about it, SQL is a pure  
declarative language that has the incredible virtue of specifying  
*nothing* about implementation. I think that you can look at what  
happened next from a pure market efficiency POV. The economic drivers  
were  all about who could take the basic representation and stretch it  
as far as it could go. That in turn meant that companies began to do  
all kinds of crazy things..

So the point is that you need to discipline the basic meta-model  
design so that it is *impossible* to specify implementation. This is  
why metaABM does not have any support for loop structures -- one of  
the things I had a philosophical difference with "PTB" about. "There  
have to be loops, because that is what the users expect". But if you  
give people loops and what not, instead of forcing them to learn why  
they don't need them, you can't get all the good stuff above.

> Finally, perhaps with this metamodeling approach or others there's  
> the possibility of not targeting a conventional programming language  
> at all, but to have the modelling framework make calls against  
> something like LLVM (http://llvm.org) and have native code generated  
> in memory for the model itself.   Such an approach would of course  
> build on a set of standard libraries for non-model things like the  
> GUI.

;)

--Miles

http://metascapeabm.com