Re: [Swarm-Modelling] Something Glen said

[Marcus G. Daniels]

glen e. p. ropella wrote:
> If the tool maintainers
> refuse to abandon the cruft when they update the tool, then users have
> to know _both_ the mainstream technologies _and_ the old technologies
> well enough to navigate around (or remove) the cruft themselves.
>   
Swarm has had no maintainer for more than five years.   There's much 
willingness to update Swarm at the SDG (and by me) by using new 
technologies and cleaning interfaces, there's simply no motivation or 
time for that work.  Meanwhile, no one is standing in your way or 
anyone's way to improve Swarm or write a new one.  Others have.  Why not 
you, the person that insists the SDG should be volunteer organization?

As far as cruft goes for users, the most arbitrary interfaces are from 
gui and simtoolsgui.   Like all Swarm interfaces, they are language 
independent, but still just a set of primitives of simtoolsgui -- the 
primitives for interactive probe displays and the control panels.  The 
gui interfaces also expose BLT graphing features for the analysis 
module.  That module could be elaborated as BLT can do many nice 
things.  Scott Christley did some work on new GNUstep GUI features a few 
years ago, and that would be one direction to continue in.   Some of the 
last work I did on Swarm was setting up a Firefox module of Swarm.   
That still could be done as now Firefox has a decent SVG implementation 
for interactive graphics as well as a bitmap Canvas.

defobj, collections, and activity (and the objectbase wrapper) are not 
arbitrary interfaces, and what I would call the reference interfaces for 
Swarm.  The ideas and implementation for composable time and space 
vicinities, and well as the implementation for language independent 
messaging and probing and object persistence.

It all could benefit internally by being rewritten and simplified.  The 
question is how to do that and if it is worth the trouble in light of 
the existence of other productive projects.  My understanding of the 
SDG's view with the last minor release work was not to do that.  Thus 
why the SDG just bumped the release with some toolchain adjustments and 
minor fixes for existing users.
> The bells and whistles are currency when (and only when)
> the users _agree_ at the core.  If there is some disagreement at the
> core, then the bells and whistles _prevent_ coordination.
>   
Integration glue addresses the problem that coordination is hard.  That 
no one agrees on direction and throws out technical reasons for not 
getting involved.   If individual technical preferences can be satisfied 
by giving them freedom to use the tools they like then they can lend a 
hand in the manner they prefer.

Now, if there is top down or shared recognition of a goal and a basic 
means to that goal, than a simple library organization is fine.  There's 
a single language used and everyone accepts that.   This was not the 
culture of the Swarm/SFI project when there was still a PI.  And 
certainly not as long as you had breath in your lungs.

Again, by focusing this part of the conversation on "integration glue" 
I'm having to do the inference work and address your chronic problem 
with vague accusation.   If there is anything specific that you object 
to, please name it and contrast it against what it is *not* within 
Swarm, and then explain why it can't be fixed.

Not having any real organizational support when I worked on Swarm (and I 
was not a PI), the future I naively saw for the survival of Swarm was 
one of academic and hacker volunteers.  People that work for their own 
goals or satisfaction but without regard for what the community wanted.  
Thus making the integration glue was more important in my mind than 
anything else.  Today, I'd say a commercial project or long term but 
lower-metabolism academic institutional project would be the way to go 
(a research project).
> > This implementation approach for Swarm is passe.
> >     
>
> A passe approach is just _fine_ if the tool is easy to use.
The tool would be easy to use if someone simply *worked* on making it 
so.  In any case, today, such a tool would be technically inferior to 
what Mono and .NET provide out of the box as it would not provide 
cross-language *and* cross-box code portability (only the former).   It 
still might be worth finishing if the payoff was perceived as big enough 
(like on a Cell-based supercomputer or PS3) or for embedding in Firefox 
or for interim glue to Mono.