Re: [Swarm-Modelling] lifecycle requirements

[glen e. p. ropella]

Marcus G. Daniels wrote:
> glen e. p. ropella wrote:
>> I don't want that detail in my _model_.  I want another agent to be able
>> to speak "passTheSalt" or whatever and have it translated to:
>>
>>    [X abc: arg1];
>>   
> If we imagine that X, Y and Z agents are processes that listen, and that
> they each have a lexicon that happens to contain passTheSalt with a
> binding to -abc:, -def:, -ghi:, respectively, it's clear how this has to
> work, yes?   Of course agents in any given model won't necessarily need
> to accumulate lots of subjective state, so it's not clear to me this is
> a common case a toolkit must address

No, it's not clear to me how that has to work.  The primary sticking
points lie in two places: 1) the lexicons are _dynamic_ so under some
conditions "passTheSalt" is bound to -abc:arg1 but under other
circumstances it might be bound to one of the other methods or some
method that doesn't exist.  2) One has to be able to switch lexicons
when working on the internals of different agents.

I view (2) as something like Ptolemy II's "director" objects where the
tokens in the lexicon might be the same but their meaning is different
depending on what director you apply to the diagram.  When you're
specifying the behavior of agent1, you have to use one language and when
specifying the behavior of agent2, you have to use another language.

It's not clear, at all, how this has to work.

> Here's my point:  If you have a long process of identifying requirements
> without triaging them as to how best to make them integrated and useful
> (by prototyping real code as you go), and without noticing the ones that
> are computationally expensive (in watts), you find yourself and the end
> of this process with a big dumb design document that no-one will ever
> want to touch.  Conversely, it isn't good to force programming
> formalisms on concepts unless they fit, but it's fine when they do
> because an instance of an appropriate implemented formalism is something
> that is one step close to something working.

I agree.  However, different people have different levels of
understanding and different perspectives.  If one or more people in any
conversation tend to _shut_ others down with their jargon-laden
statements, it intimidates many of the other people, thereby preventing
the conversation from being enlightened by their comments and knowledge.

I don't know what the numbers are; but my guess is that very few people
on this list (or in the ABM community at large) have used all of
Objective-C, C, C#, C++, Java, Javascript, Python, etc, much less know
what dynamic vs. static binding or branch prediction are.

They trust those of us who are familiar and do know what these terms
mean to either make the decision for them or give them enough but not
too much information to assist their decision making.

So, even if modeling and programming are methodologically identical,
trying to approach modelers using programming-speak will fail unless the
modelers become programmers.  The same is true with any expression of a
model.  Expressing a scientific model to a scientific review panel using
lots of programming terms will prevent the model from ever being accepted.

Models of, say, biology, should use biological language and models of
programs should use programming language.

As for your comment about a big dumb design document, again, we're not
at the _design_ phase, yet.  We're still talking about _requirements_.
The end result is a requirements document.  Of course, the discussion of
the requirements should be enlightened by and annotated with potential
design issues; but, design of a tool is different from the needs of the
prospective user base for the tool.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
Liberty is the only thing you can't have unless you give it to others.
-- William Allen White