Hi Marcel!

> -----Original Message-----
> From: Marcel Weiher [mailto:marcel at system.de]
> Sent: Sunday, December 13, 1998 7:57 AM
> To: squeak at cs.uiuc.edu
> Subject: Single page programs (Re: Configuring a Dynabook)
 . . .
> The problem with domain-specific languages is that they are usually
> very limited (for 'ease of use' and because their one-off nature
> doesn't allow expending the effort to make them more general), and in
> the context of refinement/composition they only allow the
> construction of sentences with the words (objects/classes) already
> pre-defined, so if you need something slightly different you're
> absolutely hosed.
 . . .
> So, one way of improving the situation might be turning the source
> language capable of serving as a domain-specific (scripting)
> language.  Making this happen requires framework writers to think
> hard about re-integrating their new components back into the base
> language.  It also means making the base-language flexible enough to
> let new components play well with the other core language elements.

I've used an approach called "Systems Dynamics" to build medium sized
simulation models.  In an SD model there are 'level' objects (implementing
floating-point state variables), and 'valves' to represent flows or material
between levels.  Formulas are attached to values to determine the rate of
flow from an input to an output level.  There are several modeling
environments such as Stella (see http://www.hps-inc.com/) that provide a
nice graphic environment for hooking up complex networks of these elements.
A SD model is equivalent to a system of partial differential equations and
is executed using standard integration algorithms.

It is true that you would never want to implement a general-purpose program
in a SD package, nor even a simulation model that did not fit in to the
particular modeling paradigm.  There would be some real advantages to
building a SD package within an object oriented programming environment.  In
particular it would make it easier to integrate SD models with other
software and simulation tools.

As a grad school term project built a class library for spatially organized
SD models. In this case small SD models were attached to cells or polygons
on a map.  Each cell's model had to interact with its neighbors.  I
discovered that creating an object-oriented version of the SD elements was
relatively easy, but creating an object-oriented version of the SD paradigm
was difficult.

I think the same problem would occur in any language that made relations (or
even propositions) first class objects.  Like relations, valves have two
sides (input and output) and really do not belong to any one level object.
If you try to create a container class or module of SD components it quickly
feels a lot less encapsulated when each container sprouts all of those
(independent) connections to other modules. Network thinking is somewhat
different from object oriented thinking.  In my case the situation was worse
as each model on the map had to have connections to the models in the
neighboring cells.

I ended up creating an object oriented macro language for building SD
networks.  That worked fine but it was no longer really object oriented SD.
It was OOP meta-programming for a non-OOP language.

How could I solve this problem in good object oriented style?  What features
would allow me to take a class library implementing SD systems and another
implementing, say, polygon (vector) maps and combine them?  If there were an
easy way to do it wouldn't I still have to work out all of the difficult
ramifications of combining two very different kinds of systems?

When using a powerful programming language you still have to try to
understand the behavior of the things you create.  If you start with two
complicated systems of classes it may be very difficult (not impossible) to
understand the product of combining them.


Jonathan