Re: Heatbug.java continued..

[Miles Parker]

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

>>> Benedikt Stefansson <address@hidden> 01/13/00 11:08PM >>>
>>But we also know why Ascape is like that and Swarm isn't.  To use an OS 
>>analogy
Swarm is a kernel, while Ascape is an application.

Yea, this may be a valuable distinction. Though I still think of Ascape as more 
of a  framework, than 'just' an application. So I would modify this to 
lower-level api vs. high-level framework; for example the difference between OS 
graphics system and a GUI framework. Or perhaps its similar to the difference 
between OpenGL and more OO approaches like the new Java 3D api. OpenGL is very 
strong precisely because it lets people easily do whatever they want in a 3D 
context, even though a higher level solution might make a lot of things easier. 
I'm not sure I'd thought much about this distinction. Its a useful one.

>>None of the Swarm demo applications really demonstrates how one can build
libraries of reusable objects for particular modeling contexts, which carry
through the pardigm of encapsulation and object orientation. From where I stand
that seems to be what Ascape is all about.  It would be a great boon if the 
Swarm
demo models, e.g. heatbugs, were essentially made out of higher level building
blocks which would allow the beginners to start playing around with assumptions
and without worrying to much about C syntax. *)

I agree wholeheartedly. But I wonder if part of the reason this hasn't happened 
isn't that people aren't contributing; in cases where there is an easily 
seperable piece, valuable contributions have been made, like Sven's random 
library, or Paul Box's  et.al. GIS work. But the kind of library functionality 
we're talking about--to get real gains I think esp. from an OO standpoint, you 
would have to have a holistic view and strong resources. Its not the kind of 
thing that would be easily built incremently through user-contributions, but I 
could be wrong..maybe it would just take a shared vision and collabortation 
between model developers.

>>*) I have to add that beginners actually find object orientation confusing,
because it hides so much of what is going on behind an interface. So from that
perspective there is something to be said for examples where most of the code
that is executed in a method is actually shown in that method.

This is a very important point. Frameworks do hide implementation; after all, 
that's the whole point. As Marcus pointed out,
that means that you might not know exactly what's happening 'inside the box' 
perfromance wise. But even more important, a non-programmer might make 
assumptions about the model with out really understanding what's going on 
internally. So there is a definite tradeoff here. As far as OO itself goes, I 
think this is a training issue. My strong view is that people should be taught 
OO first. Unfortunatly, that often means a big up-front investment that often 
isn't feasible. I believe that ultimatly its a more 'natural' way to think esp. 
for those who haven't already been corrupted (like me!) by exposure to 
structured programming..Still, you've had a lot more expereince teaching this 
stuff then I have. I do find that when teaching people how to use the framework 
I often have to have very involved discussions with them about how to relate to 
objects, etc..

My feeeling is that, in general that the advantages of having this code in a 
framework _typically_ outwiegh the disadvantages. First of all, if the code is 
in one place it can be strongly examined and reveiwed, and hopefully at some 
point (:-)) people have a strong trust that it does what the documentation says 
it does. This throws out the possibility of a lot of error. Frankly, I think 
what sometimes happens otherwise is that you can have models where the 
'non-programmers' (and even the programmers!) don't know themselves what the 
code 'really' does. The logic is scatterred and confused and there's no formal 
definition, so describing a model becomes a matter of interpretation.

Also, they might not be aware that a particular theoretical or practical issue 
even exists. So, for instance, they might have a model where some interactions 
assume a von Neumann space, and others assume Euclidian space. Or they might 
have unwittingly built in artifacts by not properly randomizing search order.

I think that pedagogically, frameworks are typically better, but you're right 
that you do lose something by not having the code 'in your face.' It becomes 
very easy to just trust that the framework designer knows what he or she is 
doing, and give up the reponsibility of really understanding what your model is 
doing. So yes, I think this is a critical issue. I think a good framework can 
help in this regard by exposing and making it easy to manipulate issues that 
framework users might not even have thought of, but it can also hurt in some 
sense by making it too easy for people to flip a few switches and get a 
running, if poorly understood model. What it comes down to is that researchers 
must never give up the ultimate responsibility for throughly understanding 
their models.

Anyway, I think a framework wins on balance, given three things. First, of 
course the framework code has to be open source. This is so obvious that I 
won't discuss further. Second, the framework has to be well documented vis. 
exactly how all methods are implemented; that is, there has to be a high level 
description that consistently and accuratly describes exactly what happens when 
a method is called. I've got to work on this a bit, frankly..I don't think I 
have enough low-level description of what actaully happens when a rule is 
executed on a collection of agents, for example, although the api trys to make 
many things explicit. One more thing for my to do list! Finally, the framework 
must be designed such that people can always easily extend it with their own 
implementations. Developing software is still (and hopefully always!) partly an 
art. And there will always be tradeoffs and further areas for people to explore.

-Miles



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