Metaphors > This language, envisaged by Victoria Livschitz, seems to have some relationships to BPM. BPM contains the ideas of a process virtual machine, process as an abstract manageable entity and process as concurrent distributed mobile communications (pi calculus). Quoting from a paper by Victoria:
"Q: What is an executable entity, and what problems does it solve?
A: I can observe that contextual programming constructs serve to formally define an application's abstractions and codify a programmer's thought process, not to do any "real work." That real work is the prerogative of computational constructs. Contextual programming statements therefore create logical -- not executable -- entities. They are of practical use to application designers who need to fix, extend, or reuse the context now or later. However, at runtime, some statements must be executed for a program to be of practical use to end customers.
It seems important to introduce a concept of executable entity, decoupled from the metaphorical constructs of contextual programming. Of course, executable entities may need to be generated from the contextual constructs. Something similar is going on in OOP, where executable entities (object instances) are generated from logical entities (classes). My executable entities, though, are going to be very different from conventional object instances that are sitting on a heap or a stack.
The world around us that we attempt to simulate, automate, and control via software is profoundly autonomous and asynchronous. When an apple falls from the tree and hits the ground, the phenomenon can be observed as a sequential process, but it cannot be understood as such. The sequence of events is accidental, an emergent property of the system tree-apple-ground. An apple falls autonomously when the force of gravity overcomes the force of the apple's attachment to the tree branch. The tree and the ground respond to the force applied to them by the falling apple with counterforce, also autonomously.
Unfortunately, modern programming is profoundly passive and sequential. Execution starts with some bootstrapping mechanism, like main(), that induces a chain of sequential, passive request-response invocations. Things like events and messages are special-purpose mechanisms that have been devised to allow for some illusion of autonomous behavior. True concurrency requires complicated multithreading machinery and a special-purpose programming model that is not only notoriously difficult to master but also inherently dangerous because of the unpredictability of deadlocks and race conditions.
Building concurrency on top of a sequential automaton is a bit like trying to explain quantum physics as an extension of Newton's laws. Both are probably better done the other way around.
I'd rather assume that everything is autonomous and asynchronous. Application runtime consists of autonomous executable entities, or agents, as some would call them. These agents interact with their environment and each other asynchronously, respond to external stimuli, and initiate actions out of "free will." They may exert a force or be subjected to a force field, which basically means that their ability to choose their actions will be constrained by the circumstances.
One interesting technical challenge is to devise a program execution model that will be able to efficiently support thousands -- if not millions -- of autonomous executable entities that are active at all times, even though truly interesting events happen to them only once every millionth or billionth cycle."
