Table of Contents

Structure

Previously

We saw in Software? what are the needs of all software, and in Principles the EvenDoor, EvenBoard and EvenPrg objects were defined, which implement the 7 fundamental tasks of all software.

Now we will show how to organize them in order to produce any useful behavior, and so the questions will be answered.

Bubble chamber

In 1992, Fabian J. Padilla was living near the CERN in Geneva, and was fond of quantum physics. The bubble room images he saw in books, in which we can see the behavior of particles and their interactions, particularly interested him.

For him, the behavior of the particles can be related to the behavior of data in software, or more precisely to Dataflow software (Abstraction with data).

The common rules between software and bubble room:

There are inputs and outputs

Particles and data can merge (“fusion” in the case of particles)

Particles and data can split (“fission” in the case of particles)

Particles regulate their energy, which translate to testing the value of pieces of data (“if-value”)

Difference between software and bubble rooms

There is no “if-functionality” with atoms… BUT there are different behavior depending on the energy level of particles. E.g.: atom, photon, electron, neutron, proton, and so on.

If we further the analogy, we can say that the energy of particles are like different layers of behaviors (or different functionalities) in a piece of software.

Also, as in a bubble room or in a Dataflow software, the same causes always produce the same effects. The program will have the same behavior by following rules, those of real-world space and time.

The answer to the questions is to try to mimic the particles behaviors in a program. This analysis work was done when developing a software for “Phone Marketing” work timestamps machine (patent #12121212) in Switzerland and Europe.

But Evenja (or SCALP at that time) was really born when the “Touring Club Suisse” association asked for a server linking PABX and the screen of call receivers. It was hard to take care of every call conditions, and the user interface on PS2 computers was not easy to deal with either. The mix seems really as complicated as a bubble room. So why not try to mimic it?

And so, the SCALP (Script Cross Application Language Programming) compiler was born with:

Input and output in a Door class

Merge in a Board class

Split, Modify and If-value in a Prg class

Evenja's structure

Evenja was born empirically, trying to solve one problem after another in that project for the Tourig Club Suisse. Analyzing the result, some rules appeared:

If we don't want interruptions, we need asynchronous behaviors everywhere.

If we want a high reuse of code, we need a complete abstraction of the data. This is why EvenDatas are completely “stupid”. If one put logic into EvenData, it will automatically become application dependant and code reuse will be hindered.

If something wrong happens with data, we need to be able to check what happened (debugging).

So the structure became simple as well:

EvenDoors receive data in a specific format and convert them to EvenData (input). They also do the reverse operation (output). They then send the data to a “room”.

EvenBoards receive data and merge them by a “link value”, a value that defines the data.

EvenPrgs copy (split), change (modify) or check the value (if-value). Data can be modified in the room like in a standard short program, however only by small steps.

Evenja vs procedures and dataflow

The result is:
- Three classes are all that is necessary to create any kind of software
- No need for “abstraction with procedure” at all
- Dataflow is used, but adding something new to enable complex behaviors is done without “agents”.

The next and last page of Evenja's theory, Breakthrough, explains the reasons.