Thunk,

I have been reading the posts but I still have problems understanding 
what this setup is actually for - I have an interest in Ruby and 
biological simulations so the word "swarm" captured my attention.  Can 
you describe what you are attempting to do in a more simple/overview way 
so I can see if I should be interested in this or not?

Thanks!,

Phil.


On 2010-03-22 06:15, thunk wrote:
> Robert,
>
> Whatever else this project is, I think it has to be a rather "extreme
> design". Will you give me that?  Development and debugging has been
> slow and involved early on.  Only after multiple iterations have I
> been able to simplified and the roles clarified to where things are
> now.  The set of "Boids" have determined the names and functions of
> most of the other project parts.  There's a strong mental model to
> adjust to, but some elements of the project like the need for a
> "categorization" scheme did not become evident until I was thinking,
> "ok I have the results from 100 fired! boids, what can I do with
> them?  Early on I had developed the concept of a "result record" and
> the result record could be used by subsequent passes to build reports
> - I spent a week testing it back when.  What I didn't see at first was
> the use of "output panel" that acts on the results of the Boids like a
> big billboard passively announcing the number of various "hits" in
> various subcategories.  It all makes sense, and seems totally natural
> when you see it in the context of "your domain".  I really don't think
> it was so obvious when I was designing the DSLs the support the
> various sections of the Boids.
>
> In he current design there is a "transmitter object", and a "receiver
> Object".  The receiver object "debriefs" the Boids and send info to
> the "Control Panel" and into open "Work Sheets" (probably particular
> to  my domain).  The Boid author specifies the assertions he needs to
> arrive at a passed/failed conclusion.  These things build up into
> something pretty interesting with depth.  Each Boid, so far, is
> limited to using a single helper_class - where the "real" logic and
> calculations are concentrated.  The boid is a sort of "gatherer shell"
> or something - but that's the whole idea - they must be kept simple so
> that non-programmer types can design them.
>
> What's exciting about this?  Hmmm.  What's exciting to me is that the
> system could grow from outside experts from a network of say 1,000 to
> 10,000 boids "organically" without the need to change one line of code
> in the framework.  What I think should be 'exciting' to
> entrepreneurial types is that this can be done using outside resources
> - like a forum. So the whole thing becomes something like a "knowledge
> farm".  I'm not sure where the "magic" is, its all "just ruby" but I'm
> watching the output of some pretty involved problem solving getting
> done quickly - and I'm no where near the 1000 Boid "tipping point"
> that I consider to be the design break-even point for this system
> versus a strictly "conventional design".
>
> Then, if I'm right about the run-up from 1000, to 10,000Boids this
> will be getting to pretty interesting - at least to me.
>
> Thunk
>
> PS There is this inherent power to the web that allows a contributor
> to be anybody / anyplace / anytime.  And there is this ability to
> process 10,000 of these "logic capsules"/Boids or whatever in about 2
> seconds.  And there is "time value" attached to knowing something "out
> there" changed that effects something I'm about to do.  This all fits
> together somehow, "my domain" gets close enough to justify my efforts
> to me, I think there are domains where the power of this design could
> be leveraged much farther - I keep thinking of medical procedures
> where lives are on the line and changes are happening everyday -
> around the world. A 100,000Boid system could be fired at the records
> of every patient every day for about the same resources (per hospital)
> as a couple hours of video game playing.  Nothing like this seems to
> be happening. Why?
>
>

-- 
Philip Rhoades

GPO Box 3411
Sydney NSW	2001
Australia
E-mail:  phil / pricom.com.au