Organic Programming

I was always passioned on how to make programming a easier task. A direction that looked promising to me when I was a student was about programming techniques based on asynchronous behaviors. Asynchronism allows a declarative style that can simplify(minimize) the code,at the expense of  some complexity in behavior.  In many cases that is the right thing to do (such asynchronous code could be expressing business rules (what) and not how you do low level variable management => usually a very good practice ) but you have to simulate it in pure synchronous programming languages.

Many years after school, when I discovered Action Script and his events model based on observer design pattern, I instantly liked it.  I know that many programmers have serious problem dealing with asynchronism in their code and for good reasons (and others are abusing it when simple function calls should be used ). The usual solution is to create synchronous layers  inside of an asynchronous environment and hope for the best

In Quark’s model description language, we have the idea of “trigger”  that is basically a function/observer that is automatically called when other objects get changed. While this is a very natural way for describing model’s behavior, a naive implementation of the triggers can become very tricky to understand. The cause looks to be the intuition of atomicity of changes in a function.

class example
{
 var a:int; //should never take a value greater then 10
 var b:int; //should be always 10 * a, or 0

 [trigger on a changes]
 function trigger1()
 {
   if(a >= 10)
   {
    b = 100;
    a = 10;
   }
   else
    {
     b = a * 10;
    }
 }

 [trigger on b changes]
 function trigger2()
 {
   if(b != a * 10)
   {
    b = 0;
   }
 }
}
 var e:example;
 e.a = 11;

Above code (in a hypothetical action script dialect) should result in e.b having value 100.
Still, a naive implementation of triggers, could lead b having value 0 if trigger2 get called immediate after b = 100. This is just a simple example that reveals how evil the asynchronism can get.
We will take the risk in Quark Framework to implement asynchronous programming but we try to prevent things like unintuitive/unexpected behaviors or infinite loops caused by asynchronous events.
The syntax of Quark Schema language is a mix of XML and Action Script (but not really like MXML) and we will publish/document later (before the first release of quark 2 planed in October).
The way of preserving atomicity intuition about functions/triggers, it is also a good way to minimize the number of function calls (especially calls on intermediate results).