Re: Swarm futures (was Re: GNUstep and MacOS X Port Effort)

[Alex Lancaster]

>>>>> "GR" == Glen E Ropella <address@hidden> writes:

GR> Marcus G. Daniels writes:
>> In it's current form it is good for nothing except historical
>> continuity.  But that's the rub, either replacing Swarm with
>> something new and ambitious and interesting or cleaning-up loose
>> ends on the old version.  I don't see the benefit of larger
>> codebase changes; there are too many complications.

GR> So, perhaps now is the time to discuss releasing 2.2, freezing it,
GR> and starting fresh on a whole new thing!  This is my preferred
GR> route.

[...]

GR> The bottom-line, here, is that the SDGs implementation of Swarm is
GR> difficult to use.  It makes great strides in bridging the modeler/
GR> programmer gap; but, in doing so, burrowed itself in deep enough
GR> to make evolving the tool difficult.  On the other hand, many
GR> other packages, by adopting simplifying assumptions, are easier to
GR> use, but are too limiting to be used for large-scale, long-lived
GR> projects, which makes them difficult to evolve, as well.

Indeed.  OK, I'll throw in my $0.02.  

To use a fitness landscape analogy, we are at a local optimum, sitting
on a (low) peak, from which the only way is to go down and up another
(perhaps only slightly higher) local peak.  (I suspect the Swarm
implementation fitness landscape is at least moderately correlated and
not fully random ;-)).

Many of the options, such as backing out the runtime, using NSObject
etc, are analogous to descending our current non-global peak, and
ascending to a nearby peak.

I think that we need to something in the short run, to take us to a a
new (higher) optimum (with a Swarm 2.2 release), and at least have
stable binaries for GNU/Linux, Windows and (if it ends up being
possible and doable) MacOS X.

We then need to think about crossing the fitness landscape to explore
farther-flung peaks.  To continue the fitness landscape analogy this
kind of landscape exploration can be performed by recombination, in
our case, this translates to looking at both existing and new code and
coming up with something new (which can draw on the existing
implementation, or be something entirely from-scratch).

However, I think we need some continuity and a way for users of the
existing implementation to continue their work, but at the same time
not hinder the future development, and I am beginning to agree more an
more with Glen and others that some of the aspects of existing
implementations are hindering our progress at this stage more than
enabling it.

A final polished release of 2.2 would be a way to draw to a
completion, this phase of Swarm's existence and move on to a rewrite
or reconfiguration of Swarm.

Alex
-- 
      Alex Lancaster |  Swarm Development Group  |  http://www.swarm.org


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.