ABM/Toolkit futures [was: Swarm futures (was Re: GNUstep and MacOS X Port Effort)]

[Gulyas Laszlo]

Hi,

I like the idea of approaching ABMs once again with a (more or less)
freash mind.

Actually, I'm going to moderate a panel on this topic next week at
the 'Toolkits Developer's Meeting' (Agent 2002), in Chicago. Well,
the title is 'Where should we be in five years?', but I do intend to
raise issues like this. Also, a 'DB-based runtime' (to put it loosely)
has long been a pet idea of mine...

In any case, you guys are obviously welcome to the discussion, although
it's rather short notice. (I know Roger Burkhart will be there, since he's
on the panel.) But I'd also like to solicitate ideas from the list.

Best,

Gulya

On Thu, 3 Oct 2002 address@hidden wrote:

> Marcus G. Daniels writes:
>  > In it's current form it is good for nothing except historical
>  > continuity.  But that's the rub, either replacing Swarm with something
>  > new and ambitious and interesting or cleaning-up loose ends on the old
>  > version.  I don't see the benefit of larger codebase changes; there are
>  > too many complications.
>
> So, perhaps now is the time to discuss releasing 2.2, freezing it,
> and starting fresh on a whole new thing!  This is my preferred route.
>
> Perhaps we could define a useful Actor Modeling Interface by
> interpolating between IMA, Ptolemy, COOL, AUML, APrIL etc. and
> implement that.
>
> Or perhaps we could do it in a more bottom-up fashion and pick an
> extant tool (like Avida or Bobo) with some cool but un-extrapolated
> features and throw effort into that.
>
> Or perhaps we could pick a place where very little work has been
> done so far like developing a continually evolving OO database whose
> objects and clusters of objects periodically migrate into the processor
> for various reasons and marshal themselves to communicate or to
> travel.
>
> Or perhaps we could build an agent-oriented data analysis library
> that takes the kind of data agent-oriented modelers usually need.
>
> The bottom-line, here, is that the SDGs implementation of Swarm is
> difficult to use.  It makes great strides in bridging the modeler/
> programmer gap; but, in doing so, burrowed itself in deep enough to
> make evolving the tool difficult.  On the other hand, many other
> packages, by adopting simplifying assumptions, are easier to use, but
> are too limiting to be used for large-scale, long-lived projects,
> which makes them difficult to evolve, as well.
>
> Or, perhaps we do some combination of all of these, as well as
> continue the evolution of the current codebase.
>
> I, personally, believe it's time to back ourselves out of this hole.
> And that means picking a new "mission", possibly abstract at this
> point.  If the current codebase fits in with that mission, then great!
> If it doesn't, then we wrap that code up and get started on something
> new.
>
> I would like the next SwarmFest to hold a relatively long session
> on this... maybe a whole afternoon.  But, in order to do that and
> have it be useful, we need a large population of people, with practical
> ideas in mind, to come bat those ideas around.
>
> And this won't happen unless we get some people fired up.
>
> glen
>

-- 
--
Laszlo Gulyas                           address@hidden
AI Laboratory                           http://www.sztaki.hu/~gulyas/
Computer and Automation Research Inst.  H-1111, Budapest, Kende u. 13-17.
Hungarian Academy of Sciences           * 36 1 209-6194

--> On leave at Government Department, Harvard University      <--
--> 113b VanSerge, Mails: 34 Kirkland st., Cambridge, MA 02138 <--
--> address@hidden, (617) 384-9088                     <--


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.