Re: [Swarm-Modelling] Something Glen said

[glen e. p. ropella]

Marcus G. Daniels wrote:
> If you had an idea specific and important enough to implement, and
> your view was that the SDG was incapable or unwilling to help you,
> and you felt it was unethical or inappropriate to have the SDG fund
> you as an insider or outsider,

It's not unethical for the SDG to fund anyone.  It is unethical for the
SDG to fund them through a private, no-bid, negotiation using tax-free
donations.

> then the clear and responsible path is to stop complaining about it 
> and start programming.   This will give you maximum autonomy and keep
> you on the moral high road.

This is precisely what I do.

>> My argument is that the SDG should become a more open organization
>> that serves the community.
>
> I believe it does that with SwarmFests.  This is by far the largest 
> component of cash flow at the SDG.   I personally don't care about
> these meetings, but others like them and find reason to organize
> them.  (i.e. I'm not the SDG.)

If anyone expresses an opinion about what the SDG should do, you tend to
say "stop complaining".  And there's a problem with SwarmFests in that
I've never seen any action items result.  Everyone just forgets about
any opinions expressed and goes about their own business until the next
SwarmFest.

And you _are_ the SDG as long as you're a board member.  Plus you are
the most vocal and visible representative.  And you do all the development.

> It is, you know, more "geek hermeneutics", at least whenever you find
> it convenient to call it that.

It's always that, regardless of what I find convenient.

> A first step would be to separate the packaging of GUI and non-GUI 
> Swarm.  Scott did some of this internally for GNUstep, it just needs
> to be broken into physically separate code bases. Another step would
> be to rehost Swarm on the Apple Objective C system.

Perfect!  That sounds like an excellent plan.  I think it's a perfect
use of SDG funds.  If the SDG committed to that, then I'd contribute
time and effort to such a project.

>    That would drop two
> libraries from Swarm as dependencies and some very nasty technical 
> issues (that would be handed off to Apple, at least in part).  This 
> means careful coordination with the Apple Objective C people to get 
> hooks for the features Swarm needs (for phases).

That's the wrong approach.  I think it would be much more appropriate to
use the existing Apple system.  If that means changing Swarm, then so be
it.  The defobj API could be implemented without requiring the peculiar
run-time.  Granted, Swarm wouldn't meet the initial Swarm requirement of
automatically determining more efficient implementations of particular
classes.  So, it would mean a bit less computational efficiency.  But, I
don't think the SDG should hook its development timeline to Apple or GNU
projects if it doesn't have to.

> B) a core library for representing object
> lifetimes and dynamic messages in a language independent way. Thus A)
> is really not that hard to do because the basic RPC approach is in
> place, and because Swarm can already generatesIDL for itself that 
> could be handed of to a COM stubber (e.g. Firefox's cross platform
> COM or the Sony/IBM stubber for the PS3).

This sounds like a barrier to ABM modelers to me.  The SDG is not likely
to garner the resources (money or programmers) to do this correctly and
completely.  Therefore it shouldn't be done by the SDG.  In fact, all of
these barriers should be removed in favor of a simpler set of features
that is accessible to modelers.

> C) a discrete event simulator module that has a collections library
> with it.  The collections library is needed for the scheduler and for
> legacy simulations. D) simtools and analysis, possibly merged but
> stripped of any direct reference

Excellent.  However, again, the libraries need to be complete.  If the
SDG doesn't have the resources to complete them, then we should opt for
an existing library like Foundation in Apple/GNUStep.

> E) the space library
> 
> With this organization, one could write lightweight batch simulations
>  for large scale parameter sweeps without bothering with installing 
> libraries for GUI instrumentation.    One could write or replace 
> components for Swarm in any number of languages crossing language and
>  machine boundaries.   A web-based monitoring application could
> equally well setup up simulations in the browser itself (e.g. with
> JavaScript agents), or it could initialize native objects on a
> Playstation 3 or clusters or supercomputers (either real or byte code
> streamed to it's processors or precompiled classes advertised as a
> standard web service on those machines). A new library I'd like to
> see would be a JIT native code generator for simulations described by
> higher level model descriptions, such as in XML.   Such code could be
> deployed in browser plugins or on cluster nodes.  Perhaps the best
> way to do this is via a JVM or CLR but I'd be happier to know (one
> way or another) that CPUs receiving code really were running at full
> tilt, i.e. take some time to study how a potential package like JIMT
> executes its code in the JVM and make any needed enhancements to
> optimize it for the hardware. 

Again, the features you're describing sound like barriers rather than
facilitators.  _If_ these were done well and completely, then they would
be very helpful.  But, the likelihood is that they will not be done well
or completely.  So, it would be more strategic to integrate with other
data structure libraries for spatial computation.

Overall, regardless of my little objections, this is the way the SDG
should be thinking.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
It's too bad that stupidity isn't painful. -- Anton LaVey