Re: [Swarm-Modelling] Announce: metaABM 1.0.0

[Miles T. Parker]

On Nov 24, 2007, at 11:13 PM, Marcus G. Daniels wrote:

> Miles Parker wrote:
>
> > I do not think there is any justification for requiring someone to  
> > learn the entire set of a general purpose language's functionality  
> > before we will let them loose on any kind of algorithmic  
> > explanation for natural phenomenon.
> Of course not, but that's also not to say that there aren't cases  
> where an algorithmic explanation does require a general purpose  
> programming language, if for no other reason than to figure out what  
> domain specific `macros' make sense.
> Obviously, once you have well-defined model representations you  
> later can automatically transform that representations to a new,  
> more general representations.  And I think we can agree that toolkit  
> approaches don't force users to compress toward a well-factored set  
> of primitives.  They also don't prevent it.

But if you're speaking in terms of APIs / frameworks then that does  
strongly encourage a particular compression. That is, someone could  
write their own low-level graphic subsystem using nothing but  
drawBytes, but for the vast majority of people that's a distinction w/ 
o a difference. OTOH, the only way a metaModel could be said to  
'prevent' something is for those with an extreme lack of imagination  
or who couldn't or wouldn't have done so in the first place. After  
all, the code produced is directly editable in its target language /  
toolkit so there is always an opt-out provision.

More importantly I'm glad you brought up transformations because that  
is the really cool thing about the newer approaches to meta-models.  
This is *very* different from the icky UML everywhere kind of thing.  
EMF and oAW both provide very rich mechanisms for transformations of  
meta-model instances into instances of other meta-models. So for  
example, one could take take a metaABM model and transform it into a  
more general (or specialized) representation and back (there are a lot  
of non-trivial issues there of course). This is how xText DSLs work --  
you write a metaModel that represents the parse tree of your language,  
encode the model (program text) into the meta-model, and then  
transform it into your target model. In fact, Tom Howe has been  
working on a functional language that would target a  metaABM  
representation.

Everything is a meta-model, it is just that we typically aren't  
explicit about it. There is I think a hidden assumption here that  
there is something preferable about having a single syntactic and  
semantic structure for everything (*the* programming language), and I  
am beginning to find *that* assumption limiting.

> > Learning, at least as a CS person conceives it, is where we end the  
> > current representational capability of metaABM per se, so you've  
> > identified an important (current!) boundary.
> Using a general purpose programming language, there's the  
> possibility of inferring a DSL by having a computer find or refine  
> minimal programs that explain some pattern of input and output data.

If you find that palatable, then surely one that is crafted by humans  
is not such a bad thing? :)

>  Ultimately what should matter are rules of predictive utility, not  
> pretty stories..

Ultimate how? Matter to whom? Can we *predict* what direction a flock  
of birds will fly? Theories are perhaps nothing but "pretty stories",  
but they allow us to define and share sets of rules that help us to  
understand and *explain* -- in the most transparent and elegant way --  
why birds move in the way they do, and what the space of possible  
movements looks like. Prediction is nothing but an arbitrary set of  
coefficients for formulas that by definition fails the first time we  
encounter a truly novel situation, and so is useless if we have no way  
to understand it, communicate it, and apply it to analogous  
situations, e.g. "tell a story".