Simulation frameworks in C++?

[Nelson Minar]

Ted says:
>Again, I simply think it would be interesting to see what a general 
>simulation framework would look like in C++.

I agree, it's worth discussing. My own feeling is that C++ is too
impoverished a language to make it easy to build flexible simulation
tools. That, and the language is too complex to explain to people. I
can't think of any advantages that C++ provides over other OO
languages except that it happens to be the most common OO language in
use right now. That's an important thing, but I believe the tide is
changing on that.


As for methods and such..

Manor:
>>I disagree with Ted that one can build a General Purpose simulation
>>environment without the concept of Methods as first class entities,
>>(at least not without some serious recompilation requirements), but

Ted:
>what you are really saying is, Swarm's philosophy is that it is 
>necessary to be able to probe every aspect of a simulation.  Is that an 
>accurate characterization?

I think there are two issues here.. the first has to do with probing
objects for observation. As you note..

>objects could decide for themselves, for instance, what can or can't
>be probed. It's analogous to the way persistence is handled in C++.

Yes, but IMNSHO this is handled very poorly in C++. Take the example
of every single class having to overload the iostream << and >>
operators to generate a printable instance. What a pain in the neck!
People don't want to bother. You really want introspective
capabilities in your OO language for flexibilty, and it's a severe
weakness in C++ to not have it.


The other big use of methods as objects is in building schedules in
order to specify a simulation. In most cases, if people write a
simulation in a normal computer language, they end up writing a loop

  while (time < simulationDone) {
    [heatbugList foreach: "step"];
    [heatspace update];
    time++
  }

In Swarm, though, you explicitly create a schedule data structure with
the actions. That data structure is then fed to the schedule executor.

The Swarm schedule stuff is really a little programming language, and
the executor is an interpreter. The advantage here is that (we
believe) our schedule language is a *better* language for specifying
execution of simulations than C. In particular, it allows you to
specify exact concurrency semantics, an issue that's often
accidentally swept under the rug in normal programming languages.
This is useful both for simulation correctness and parallel implementation.

A secondary issue is that because the schedule structures are data, we
can have all sorts of nifty tools to allow users to view and
manipulate the schedule (at least, in theory. How are those coming?).

Doing something like this in C++ would be considerably more difficult
than in ObjC.


I'm still curious about the possibilities of using threads as an
alternative to schedules or while loops. Yet another topic, I guess.