Re: [Swarm-Modelling] Announce: metaABM 1.0.0

[Marcus G. Daniels]

Miles T. Parker wrote:
> > 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. 
Sure it encourages a certain set of library calls, but that doesn't 
encourage users to constantly factor the rest of their simulation code 
(that is using those calls) or follow any particular set of practices.   
Those habits, to the extent they exist, come from examples or the 
community of practice, or personal aesthetics.  A declarative domain 
specific language, however, can force the user toward a small set of 
more optimal constructs and also facilitate the computer noticing 
redundancy, etc.  That's a good thing to the extent the primitives are 
optimal and general (or at least well suited to a domain).
> 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. 
But the opt-out isn't not unified with the high level representation.  
Once generated code of a model for a target language / toolkit is 
elaborated by hand in that target language, it's opaque to the meta 
representation past the interfaces to which it conforms to.   How do you 
pull the meaning of those elaborations back into the high level 
representation so they can be applied to another toolkit?

Marcus