Re: The Swarm space (was RePast (another agent toolkit) released)

[Miles Parker]

>>>I've been a little surprised 
>>>that swarm hasn't been more anxious to provide it, though I can totally 
>>>understand their choices given limited resources.

>I realize you didn't intend to broadcast this, but felt I should
pursue it anyway.  

That's cool - - I _try_ not to say anything that I wouldn't say to someone 
directly; still If it had been meant for public consumption, I wouldn't have 
been so off-handed. I actually think it would have been the 'obvious' move, and 
so it puts Swarm in good light that it wasn't blindly pursued. But yea, 
ultimatly I think a more direct move towards Java sooner rather than later 
would have, on balance, been 'better'. Does that mean I think that Smarm 
development has gone in the 'wrong' direction? Not at all. I totally agree with 
your analysis, though prb. not the conclusion. Like most decisions, it doesn't 
come down to the structure of the tree, but the weight we put on various nodes.

If you throw in unintended consequences its all a beautifully non-optimizable 
situation anyway--If Swarm had been totally in the Java space, I probably 
wouldn't have been able to justify to myself building a higher level system 
from scratch, so we would have lost whatever new value there is in that. From a 
purely selfish point of view, I've been happy to be the only person w/ a pure 
Java solution. Now I have to share that distinction with Nick. Bummer. [grin]

As an aside, I do think that there was and has been a history of a kind of 
knee-jerk anti-Java bias in parts of the the open-source *nix world (and by 
extension, Swam.) (Calling java a 'fad' is just one example of this attitude, 
ahem.) Just a cultural thing I think. If software environments were 
politicians, Java would be Al Gore and Linux would be Bill Bradley. If they 
were punk rockers, Linux would be hardcore and Java would be a poser. Now, I'd 
rather be hardcore, and I'd problably vote for Bradley (or McCain)*, but 
technologically I'm going to have to go with Java. If that makes me a sell-out, 
I'll live with it. :-) Seriously, I can sympathize with people not being eager 
to get run over by the Java steamroller, and I think a 100% pure java world 
would be a pretty boring place.

But when I discussed with people a couple of years ago the bringing Java to 
Swarm the response, with notable exceptions, was pretty negative. "Java is too 
slow" and "Java isn't dynamic enough" were the two biggest complaints, and I 
think if people had looked just a little closer they would have seen the 
fallacy of these staments. Deciding to go with Java is not simply being swayed 
into the latest fad. Java is a major technology, one that has enormous momentum 
behind it, and that can provide all kinds of leverage from other technologies. 
Java is now typically the language introduced for a first course in 
programming. Java has strong typing, idioms and patterns, all of which lead to 
better, more robust, consistent, and hence trustworthy code. Java runs 
seemlessly on almost any common machine, making collaboration and model sharing 
completly straightforward and transparent. All of these comparative advantages 
were predictable. (Though I have to admit that developing in 
Cocoa/YellowBox/NextStep for OS X sounds like a pretty nice option.)

That said, of course I _completely_ understand why the Swarm community wasn't 
over-eager to throw everything over to Java. I think in fact that the Swarm 
community in general, and Marcus, Alex, et.al. in particular, have been very 
creative and intelligent in exploiting new technologies while retaining 
backwards compatibility. Orginizationally and environmentally that was probably 
the wisest course. I would probably have opted for a ground-up rewrite and that 
would certainly have lost a lot of momentum. So perhaps things turned out for 
the best..

But anyway, the long and short of it is that I'm not actually complaining. 
We're members, I greatly support and appreciate what Swarm is doing, both as a 
community and as software, and I'm not a Java fanatic. (OK, I'm a fanatic, but 
I try to keep _some_ presepective..) As I said earlier, I think there is room 
for many different solutions; I'd just like us to be open to them. And I think 
this means being culturally open, and not just technologically 'open', which 
means, in a funny way, being open to technologeis that aren't so "open". As a 
practical matter, as you might agree, having at least one 'pure' java solution 
would give swarm a leg up in some ITS metrics for 'proof of survivability, 
etc'..

-Miles

[*Because of where I work, I probably better say that any political (or any 
other, for that matter!) views are of course my own!]




Miles T. Parker
Software Engineer
The Brookings Institution  1775 Mass. Ave. NW  Washington, DC  20036
http://www.brook.edu/es/dynamics/models/ascape
mailto:address@hidden  voice 202.797.6136  fax 202.797.6319

>>> "glen e. p. ropella" <address@hidden> 01/31/00 04:58PM >>>
At 01:52 PM 1/31/00 -0500, you wrote:
>been avoiding it for the same reason.) I think the community needed a more 
>traditional swarm like all java solution--I've been a little surprised 
>that swarm hasn't been more anxious to provide it, though I can totally 
>understand their choices given limited resources.

I realize you didn't intend to broadcast this, but felt I should
pursue it anyway.  What evidence of anxiety haven't we shown about
a pure-java version of Swarm that you would have expected to see?

What the hive has been doing is *both* maintaining the old interface
(which is ObjC) and opening up access to new interfaces (Java and
Scheme as well as R and HDF).  Backwards compatability and the
pursuit of a stable API is *very* important.  Granted they could
have forked the code and re-written the API in Java.  Or they could
have re-written the whole thing, including the API.  But, that is
near-sighted and counter productive.  A tool that is intended to be
used for large and long-term projects has to show stamina as well
as open-mindedness.  Using the latest technological fad (like Java)
is a *good* idea because it allows you to navigate which parts of the
solution space that fad helps you build.  But, dedicating your
entire project to a fad that's less than 4 years old is *not*
necessarily a good idea, because it doesn't allow you the synoptic
perspective that taking an open approach allows.

A modeler can now build her models, using Swarm, with Java, ObjC, Scheme,
and XML.  (Though I wouldn't count on the usability of the last two, yet.)
Granted, those of us who have requirements for pure Java are not yet
satisfied; just like there are many others with requirements that prevent
them from using Swarm (like an underlying mathematical formalism).
But, as for pursuing Java (and even pure-Java), I think the hive has
done a remarkable job of being able to take advantage of new technologies
without risking the usefulness or existence of the project on those
new technologies.

Tools like aScape and RePast are wonderful pieces of our community
and, I hope, we'll be able to integrate them completely.  But, being
targeted for smaller purposes, both of those pieces have much more
freedom than the hive has.  The hive has as its charter to support and
develop a community that is larger than any one tool or technology.

For example, take Cody's aforementioned problem, that Swarm is on
too ethereal a footing for Ford to seriously consider investing
in it.  Ford is right! (Though we're steadily whittling away at that
argument!) Swarm isn't a traditional package or project.  It uses an
iffy proposition for distribution and licensing.  It has publicly
supported resources.  It's a grass roots project, meaning that the
requirements are emergent, rather than a designed-for-a-purpose (e.g.
Linux) project.  Etc.  All these are very good reasons for a technical
consultant to advise a corporation against doing any kind of sole-
sourcing based on Swarm.

This is why Chris, Doug, and I started SwarmCorp.  This is why,
Chris, Irene, Marcus, et. al. formed the SDG.  In order for a
device (in the widest sense of the term) like Swarm to survive the
due diligence process implemented by a software integration guy at
a company that's at a higher than CMM level 1, we're going to have
to *prove* that Swarm will survive fads, integrate with new technologies
that turn out to be more than fads, evolve with changing use-case
requirements, and, most of all, save the company some money.

So, I apologize if I seem like I'm ranting, here.  [grin]  But, I'd
like to know what more the hive should be doing to ensure this end goal
(proof of survivability, integration, adaptability, and efficiency) with
respect to Java?  I'm really asking, here, not just being rhetorical.  Give
us some feedback for what we should be doing!  Believe me, we'll listen.
We may argue beyond your patience[grin]; but we'll try extremely hard to
fold your requirements into the community's as a whole.

glen


--
glen e. p. ropella =><= Feeding the hamster wheel.  Hail Eris!
Home: http://www.swarm.com/gepr                (505) 424-0448
Work: http://www.swarm.com                      (505) 995-0818


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================