Re: [Swarm-Support] development priorities (was Re: Membership in Swarm Developmen Group)

[glen e. p. ropella]

Marcus G. Daniels wrote:
>> "Updating" and "reimplementing" Swarm as it is just tosses more money
>> down into a cavernous money-pit. 
>
> Swarm must either find the courage to do something specific, new, and
> radical (i.e. and potentially not stick with commodity technology), or
> to honestly just focus on providing slow improvements continuity for
> users (a number of them credible and productive).  Neither goals are
> objectively wrong, and both are arguably not relevant in light of
> successful user-oriented products like NetLogo and ambitious designs
> like IMA.   What is your specific, new, and radical idea?
> 
>> Most importantly, I think it should be designed as a typical open-source
>> project where code is developed on a volunteer basis
>
> Great, lead the way!   Throw off the chains of outdated and
> over-engineered Swarm and show us your new code!   Or, lip service is
> fine too, if that's easier...  :-)

My my, we are hostile, aren't we?

Unfortunately, I cannot "lead the way" with Swarm because the SDG is
intent on it's current path.  And why would I invest any of my time when
the SDG responds this way, anyway?

However, in the interests of dialog, specifically, I'd like to see Swarm
try again to achieve some of the goals we've been talking about from the
beginning.  Arguably, the most important part of the original project
was the higher order methods for manipulating schedules.  The first
specific effort would be to either extract the scheduling machinery from
the other cruft that's built up over time _or_ implement it anew in a
language more amenable to higher order reasoning than Objective-C.
There's no reason we couldn't build the tools we needed to make formally
provable statements about schedules; but, it's more difficult if the
underlying language doesn't adhere to some rigorous formalism.  There
are many options to choose from, depending on the goals.

Specific observables I'd like to implement are graph measures over the
schedule posets.  I can imagine a companion data structure (a graph) to
the (uncollapsed) schedule that is input for algorithms that determine
the properties of the graph (cycles, cliques, partitions, depth, knots,
etc.).

Such a companion data structure could easily be added to the current
Swarm; but, when/if such capability would be useful, it would be easier
to do and more likely to be used if it were added to Mason or Repast.

What would not be easy to do in any of the current tools is to analyze
the structure on the fly and make future scheduling decisions based on
those graph properties.  None of the tools _support_ that sort of
reasoning.  In fact, it seems to me that most simulations use relatively
simple schedules primarily because there is no such companion data
structure to help users understand what they've created.  And in that
regard, we could go quite a long way just by visualizing the graph so
that users can better understand scheduling.

Is that specific enough for you?  If I thought that the current Swarm
codebase had a future, I would have developed such a data structure.  (I
 also have several utility classes that I could contribute with a little
cleanup and completion; but, it's not worth the effort to clean them up
and complete them if the SDG moves Swarm to GNUStep, finishes its own
Collections library, or spends its meager energy porting to 64-bit
architectures or the Cell.)

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
Always acknowledge a fault. This will throw those in authority off their
guard and give you an opportunity to commit more. -- Mark Twain