Re: [Swarm-Modelling] lifecycle requirements

[glen e. p. ropella]

Marcus G. Daniels wrote:
> glen e. p. ropella wrote:
>> 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.
>>   
> Here's one approach:
> 
> 1) A lexicon is a class that get instantiated as a part of a creation of
> a agent type; thus all instances of such agent types have lexicons.
> As there is a slot in an agent for its lexicon, thus lexicon is
> replaceable with another at will.   Or this slot can be used for a list
> of lexicons to enable multilingual agents.
> (Where each mini-language per agent is not necessarily exactly the same
> language that everyone else has.)
> 
> 2) The lexicon class has a method that given a name, returns an
> implementation (e.g. a Selector in Objective C)
> 
> 3) The lexicon initializes its bindings from some global pool or
> stochastically given a community of agents (and thus their lexicons) to
> observe from.
> In a simple extreme case, this pool could be all Selectors active in the
> runtime.
> (e.g. iterate over them using the Objective C runtime)
> 
> The details of #3 depend on your model.  As would the decisions about
> when to replace a lexicon, or make changes to it.

How does this treat the modeling effort?  Everything you've described
treats the execution of models but not the act of modeling, which is
what I'm trying to facilitate.

> different affinities.  That being said, there is no reason to be
> intimidated about asking what a term of any color means in alternative
> language.  Nor is there even any reason I can see why we all have to
> understand one another all of the time. 

Yes there is.  The intimidation is implicit.  Nobody (other than me,
perhaps) wants to look like an idiot in the eyes of their colleagues.
So, in order to participate in a conversation, a person _must_ go out
and learn (either by asking or research) what a term means and how to
use it _before_ being able to participate in the discussion.  Hence,
people who use too much jargon are implicitly blocking the input from
those who may not have mastery over that jargon but still have useful
things to say.  This is just common sense, it seems.

That said, those of us who post frequently, are opinionated, type fast,
etc. can tend to swamp others because we don't give them enough time to
respond.  So a person is faced with the idea that if they can't respond
_NOW_, then they may as well not participate at  all.

>> 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.
>>   
> Us and them?   This is an open forum for agent based modeling issues. 
> Nothing discussed here recently has really been about directed
> engineering <address@hidden> or technical Q&A about the
> package <address@hidden>.  It's all good.

My point was that not everyone on the list can parse the technical
language and by continually and unrelentingly dousing them with
technical language is a form of guerrilla control over the content of
the list.

>> As for your comment about a big dumb design document, again, we're not
>> at the _design_ phase, yet.    
>
> The waterfall software development process is bad.   These phases are
> your preference, I'm just playing along!

You keep saying that.  But, this is not a software engineering exercise.
 All I want to do is determine whether or not lifecycles are important
to ABMers.  In order to determine that, we have to talk about a
lifecycle _requirement_.  There's no software engineering going on, here.

_If_ it were determined that such a requirement exists for ABM tools,
then we _might_ go about finding ways to satisfy the requirement.

Regardless, the waterfall process is not _bad_, per se.  As with any
method, competent and focussed people can make it work.  But, we're not
in a waterfall process, here.  Just because I want to talk about
requirements doesn't mean we're engaged in a waterfall method.

You immediately leap to implementation or design detail.  And that may
work well for you; but, it's not a universal tendency.  I'm plenty
willing to discuss implementation _if_ it helps concretize the
requirement in your mind.  That doesn't mean that we _are_ discussing or
ever will discuss or plan an actual implementation.  I just wanted to
hear what the people on this list think of it!

And that requires input from people other than you or me.  So, I'm going
to quit posting for awhile and hope that others chime in.  I invested a
large chunk of my holiday in this discussion and I've gotten almost zero
return on my investment.  I'm sure that's my fault.  But, it's still true.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
Every normal man must be tempted at times to spit upon his hands, hoist
the black flag and begin slitting throats. -- H.L. Mencken