Owen Densmore wrote: > But the bigger picture of my wish is precisely that: we need to build > a far broader set of easily integrated tools for ABM. Far more > important is the synergy amongst them than their ease of use. > My experience with Swarm was that it was not easy to do in an incremental fashion or with a typical open source approach. Neither newcomers nor theory people want to concern themselves with the details of the technology, and these are the people measuring your progress in a public/academic funding type scenario. My impression of toolkits that have followed is that there still isn't a great deal of community support at the level of programming. This is not to say projects haven't succeeded, but they've succeeded with focused organizational support, not because of loose community cooperation on improving software.
Still you can be sure that GIS-oriented static modelers will want to use their familiar ArcView package, and if they can't they won't get that involved in dynamical modeling. I'm sure we could make a long list of important technologies to support from an ABM toolkit, but it takes a lot of user support to get non-programmers to explore these synergies, even if it really isn't that hard. It's quite possible to work very hard on middleware, and then have a large community of people completely unwilling or unable to get off the ground with it, even with intensive support. (E.g. in Swarm the ability to have the scheduler issue COM calls or call JavaScript functions -- that stuff was effectively middleware and had no immediate payoff except for another programmer to do further development work. The problem is that all development you do on a shoestring budget usually needs to become visible relatively quickly.) In spite of all this, I still think technology integration is one of the most important things. Software packages have to evolve with the times and build on other packages, or else user perception will kill them, if not maintenance burden. Another important thing is to provide leadership in new directions. Scientists are comfortable with this way of doing business and I think it is more fun anyway. One way a small open source project could do this would be to explore a more mathematically tractable language that at once also provided all new capabilities. The two new capabilities I'd like to see are 1) evolvable agent rules, provided at the language level, not in an ad-hoc way, so that agent behaviors could be inferred from observed data (sort like what Phil was talking about), and 2) real scalable parallelism. ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
