Re: [Swarm-Modelling] Something Glen said

[glen e. p. ropella]

Marcus G. Daniels wrote:
> Ease of use increases when a package's infrastructure is maintained and
> updated to mainstream technologies and decreases when it is not.

Bull!  Ease of use increases with simplicity.  The more powerful the
tool, the harder it is to use.  Updating a tool to mainstream
technologies will only increase usability to the extent that it
_abandons_ historical cruft as it is updated.  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.

Good examples are the Swarm runtime.  To make Swarm easier to use, it
should be dumped, even if that means dumping the efficiency of Swarm.

> 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.

This is just more geek hermeneutics.  Sure, integration is work.  But,
the attitude is obstructionist.  Over-engineered and crufty tools can't
be defended by saying things like "you just have to understand that
there's magical but uninteresting to you Eloi that we _must_ do."
Rhetoric like that is a very strong indicator of bureaucracy.

> 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.

I presume by "core of people", you mean "more than 1"?

> 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.  

Superficial?  Yes.  Wrong?  No.

> 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.

I disagree.  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.

Since the domain for these toolkits (ABM) is, itself, fairly new,
there's plenty of room for disagreement at the core.  Witness Mason's
scheduling API vs. Swarm's.  Witness the idiomatic differences between
Objective-C and Java.  These are _deep_ differences and the more bells
and whistles a tool has, the _less_ coordinated effort you'll see.

> This implementation approach for Swarm is passe.

A passe approach is just _fine_ if the tool is easy to use.  Again,
however, this goes back to the fundamental purpose of Swarm and the SDG.
 If the purpose is to support a community of ABMers, then it doesn't
matter whether the _implementation_ approach is passe or not.  What
matters is whether the tool _facilitates_ the users.  Does Swarm do
that?  No, of course not.  Why?  Because it's too hard to use.  Why is
it so hard to use?  Because it still carries all the (incomplete) bells
and whistles of 10 (yes TEN) years ago.  (I was so sorry to see Rumsfeld
go! [grin]  He was inspiration for self-interrogators everywhere.)

> Or one could just completely start fresh with some new ideas.

Exactly.  We _could_ start fresh with some new ideas.  _And_ those ideas
would be enlightened by the original plan for Swarm, the many languages
and tools that have emerged since '96, the evolution of tools like
Repast, and the wants and needs of the constellation of domains (e.g.
bioinformatics) near ABM.

> 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.

I admire the people who do such work for their knowledge, skill, and
tenacity; but, the work itself is _not_ admirable if it's being done
without examining the full panoply work that could be done and the ROI
for any one body of work.  Working extremely hard on a dead-end project
doesn't seem like a good use of time to me.

> 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.

Not necessarily.  There are plenty of valid economic and social reasons
for _using_ open source even if/when you have the money to pay for
proprietary tools.  But, as you said earlier, open source tools require
a motivated core development team.  And it's clear that there is no
motivated core team for Swarm.  Hence, Swarm, in its current form, is over.

-- 
glen e. p. ropella, 971-219-3846, http://tempusdictum.com
I don't give a damn for a man that can only spell a word one way. --
Mark Twain