A humble start on a Boid System Vocabulary -

I just took a crisp spring bike ride to our coast guard station and
spent the whole ride thinking about these Boids again.  I've been
working with them solid for months and somethings that have gradually
become clear to me as I have seen things begin to work, and as they
have evolved are not so easy to communicate about.  Explaining these
things separately probably does not do justice to the strong model
that is a nice part of the advantages of this design/architecture.

Working with Boids is rather like using OO, at first it seems to be a
lot of fuss about nothing, then when you've used inheritance and all
you can't even think how you'd do it another way.   While I'm not
saying at all, that is design has anything like the significance of OO
I have come to be convinced that there are some big niche projects to
be done in this style for reasons I hope to help make clearer.

For example there is a concept of "categorization" where the Boid
author is given a series of simple choices about what his Boid is
about.  Seems simple, maybe even stupid? Let the author give some
"tag", right?

Well let 5,000 lines of text zipl past you telling you what Boid is
making what assertion and the status and the messages and all you want
to know is "how many hits" did I get on "contraindications on drug
xyzarin" then the lights go on and you see the need for a
"scoreboard".  Well if all you have are dumb tags how can you "keep
score" - ahhh - and now the expert is presented with a series of
choices representing a Matrix - and now you can change colors and do
the cool stuff web design stuff.  I used Wee and came up with a Panel
that also supports Drill down, and since the Boids keep really
intricate records I've allowed for 3 levels from summary to
totally_anal.

So if I'm going to communicate about this, there is some sort of need
for a vocabulary that fits this way of thinking...  and on my ride I
remembered that GitHub folks had their "Porcelain" and "Plumbing" that
was very amusing and useful so why can't Boid Folks have "Satz" and
"Swarms" and and such - so here are the terms off the top of my mind
in no particular order and if there is interest any interest in this
we can refine it further:


BOID
    Several types - makes assertions or can be a review, or can
contribute to reports.
    Several SECTIONS-  Headings, Attributes, Assertions,Messages,
Conclusion each a DSL.  More coming.
    ScrptRec - sort of the "black box" a recording of everything and
anything that happens to the Boid that can be of interest - names of
author, intermediate calculation results, everything gets recorded
into this object.  Nothing else is left when the Boid is finished.

SWARM
   A logical set of Boids.


SwarmSession
   the mother of all swarmsObjects.

Fire!
   The "living" part of the Boid cycle.  All "Assertion" type boids
use at least one "helper_class".  Data is held READY in the Screens -
and what they are is domain dependent but this is where simulation is
coming in for me - I use a real Drug ClassBase but simulate "patient
records" by the 1000's for testing.  I'm not sure if this is
particular strength of Boid Architecture or not.
....All 5 sections are executed in order, each part tends to be just a
few lines.  Each section has a specific DSL to handle it (thank you
Ruby!!)


begin Core "flight time" Swarm Objects
=====================

SwarmSender
    Loads the Boids, sequences them by "pass numbers" and so forth -
    think of those wwII pacific war movies and aircraft carriers if it
    helps - and wear a white scarf.
          |   |   |
<See HelperClasses>
          |   |   |
<See Screens>
          v  v  v
SwarmReader
    Literally "debriefs" the Boids one at a time as they come back to
the carrier (if you liked that analogy).  Scores are tabulated for the
"control panel" so colors can change with the "hits".  The Blackbox is
offloaded and stuck away for analysis - and it is ALL there - a
beautiful thing if you really want to drill down on how a result was
arrived at. I have implemented 3 levels of Drill down, with the 1st
level being a summary and so on.   But so you know, every attribute
used in every assertion has been recorded.  See Categorization /
ControlPanel

===============

Screens
..... Between the Sender and the Reader (conceptually) there is at
least one "screen" but two is much more interesting.  These are what
the Boids "see" and use "to load their attributes" and "fire!" on
them.

Helper_Classes
,,,,,,I was using this before checking out Ruleby, honest, but I see
those folks had the same concept, I think.  Anyway it takes the load
off the Boids and really helps make the 'Expert Session' almost
trivial and that seems important / critical to the outsider
contributions aspect of all this.  A few clues:   The names of the
Helper Library is the first choice the the Assertions, then all the
'?' methods are listed to the Expert.   These methods must (so far)
result in a true/false or fail response and all this stuff is
inherited anyway.   helper_classes can have  access to all kinds of
resources.
.....Once a domain is established this is where the "programming goes"
- expanding existing, creating new libraries.  See expert session -
they are tied to this WebApp.


================================
     End "flight time" core Boid Class descriptions


Expert Session -
......This is everything and anything needed by an "outsider" to
author a new Boid.  The Boid type is selected, then there is a screen
for each "Section" of the Boid.   Heading -> Attributes -> Assertions,
Messages, Conclusion - nothing complicated, the messages are the
"meat" because they explain what the author is up to.   There's
categorization.
.....I had this on-line for a different domain written in Wee (thanks
to Michael Neumann) and it was possible to turn, probably the most
"exotic" part of this thing, the Assertions, into an exercise in
selecting method names (all '?'s methods)  and little more.
....What I'm messing with right now is a "super boid" that can
multiply itself.  Some of this is domain specific.  There are "system"
boids that can kick everything off, and clean up after.... and on it
goes.  After awhile, its like OO and you can't even think about how
this would be done any other way.  Its common sense and fun.

------------------------------------------------------
not really 'core' to the Boid System

ClassBase
It ain't yo daddy's db - whatever else it is - one "record" might
correspond to one class?  Not sure anymore, I can't think that way,
but one interesting thing is that at the Method level I have
"standardized' on always returning an Array of "Satz" (from German for
sentence)  - and this thing is a Hash that follows certain DSL like
rules.   A satz can be used for quick computer access but it can also
be converted to a natural language, Well almost :).   Every satz has
uses several types of Keywords, :NOTES are useful for letting humans
know understand if things getting confusing, and ends with a :REF to
keep everything straight.
....I would not mention this class but it really warps nicely into my
Boid based design.  The "techno-english" sentences derived from the
Satz are easier to understand and less ambiguous than English - I have
not been able to get myself to remove the Brackets around the logic
because it seems clearer to me.  Not sure what other folks are going
to think.  Here are a few examples:

	IF...   [ CONDITION  *is*  CHOLESTEROL  (HIGH) ]  THEN... this is a
CONTRAINDICATION*
		*Jenike MA Editorial.  Journal of Geriatric blabla....

	IF...   [ CONDITION  *is*  KNOWN ALLERGY ]  THEN... this is a
CONTRAINDICATION <When the Form is Gel> <When the Use is: External>*
	       *Syzju G. Igta T, Effects of blabla


==============================


Here's an example summary - as things are running now on my 3 yo
Hackintosh

Number of Boids Fired:	60
	BOID Execution Time:	0.02725100517 Seconds
	Number of Boids:		60	Nr of Boids Fired:	51
	Time per Boid:		        0.000454183419545492
	Fired per Second:		2202