Re: [Swarm-Modelling] Something Glen said

[Marcus G. Daniels]

glen e. p. ropella wrote:
> The lack of new users has more to do with the comparative ease of use
> for the other tool kits. 
Ease of use increases when a package's infrastructure is maintained and 
updated to mainstream technologies and decreases when it is not.   It's 
not particularly interesting work to describe to modelers, but the fact 
is with limited project resources it is crucial to leverage work from 
outside projects.   There is of course work above and beyond maintenance 
work to make a package easy to use, and users productive, but it is 
arguably the least interesting of all work to do, and least likely to 
occur in a volunteer framework.

On open source projects, I would say it is the exception not the rule 
that active codevelopment occurs outside a small core group of people or 
in a distributed way.   The ones that do work have a very motivated set 
of people in the center of them, and have broad range of opportunities 
for contributing code (in a self-benefiting and/or reinforcing way) 
without deep requirements for system understanding in order to make 
useful and correct contributions.  Thus the motivation for protocols 
that connect system components each with different experts as needed --- 
the motivation for a multilanguage interface for Swarm. Indeed we never 
got there with Swarm as a public release so you and other people Swarm 
as monolithic even though it's a somewhat superficial evaluation of the 
code.   

> I think if Swarm's essential API (activity, defobj, collections, and
> space) were extracted, leaving behind all the bells and whistles, and
> cleaned up
An API is useless by itself.   It must be implemented.  In the best 
possible world a multi-language interface would facilitate, for example, 
a new collection library written in C++ or Python or in whatever 
language an opinionated person such as yourself preferred.   You would 
own the new collections, and be however loud and proud about the whole 
thing as you liked!   A user could opt to try out your great new widget 
and then if they didn't like it fall back to the old one.   In this 
view, the `bells and whistles' (or what I believe you are talking 
about), are in fact the most important thing.   It's the basis for 
uncoordinated and centralized work. 

This implementation approach for Swarm is passe.  Now there is Windows 
.NET and Mono that do all this.   Sure, Swarm could still be adapted to 
fit into this framework, but at least the framework itself isn't needed 
except to the extent of pulling in Objective C. Probably better work to 
do this would be to actually get an Objective C target working in Mono.  
GCC/CLR support was one of those Google Summer of Code projects, and 
probably is within reach.  Or one could just completely start fresh with 
some new ideas.

Volunteer work on packaging for Fedora Core is admirable and very 
valuable as is volunteer work on GNUstep and Mac packaging, but I'm 
afraid it is not enough to keep the package moving forward, at least for 
a community of largely disconnected users. 

Meanwhile a user might reasonably object "I just want something that 
works".  That goal is largely incompatible with volunteer open source 
development.   What these people should do (and what is fair in the 
larger scheme of things) is go to their department heads and get a 
budget for Matlab/Simulink or some similar commercial solution. 

Marcus