Darwinian Software Composition

Unintentional Software

Last night, I got to thinking again about Charles Simonyi’s intentional software project and it occurred to me that a domain expert or software designer does not always know exactly what he or she wants a new software application to look like or even how it should behave. Initially, a designer may have a partially-baked idea of the look and feel of the desired application. However, even though we may not always know what we want, we can all recognize a good thing when we see it. This is somewhat analogous to a musician searching for the right notes for a new melody idea. The composer may end up with a final product that is not exactly as originally envisioned but one that is nevertheless satisfactory. Searching can thus be seen as an indispensable part of designing. It adds an element of randomness into the process. What makes this approach attractive is that it is highly interactive and it works. It dawned on me that a similar approach could be used when designing software in a COSA environment.

Relaxing the Rules

Normally, COSA uses strict plug-compatibility criteria to connect one component to another.

Two connectors may connect to each other only if the following conditions are met:

1. They have opposite gender (male and female).


2. They use identical message structures.


3. They have identical type IDs.

As you can see, there is no possibility for mismatched components in a COSA application. Strict plug compatibility allows components to automatically and safely snap together. This is fine and desirable in finished applications and components but what if the rules were relaxed a little during development? What if we could instruct the development environment to temporarily disregard the third compatibility criterion in the list above? This would allow the designer to try new component combinations that would otherwise be impossible. The only problem is that, more often than not, the new combinations would result in timing conflicts, i.e., bugs.

Good Bugs vs. Bad Bugs

In general, computer languages try to prevent bugs as much as possible. Most of the bugs that used to plague assembly language programmers in the past are now gone. With the current trend toward thread-based, multicore computers, a lot of effort has gone into making programs thread-safe. The problem has to do with multiple threads accessing the same data in memory. This situation can lead to all sorts of conflicts because the timing of access is not deterministic. Functional languages avoid the problem altogether by eliminating variables and thus disallowing side effects between threads. The COSA philosophy, however, is that side effects between concurrent modules should be welcome. A bug is bad only if it is not found. Since COSA programs are reactive and temporally deterministic, all data access conflicts (motor conflicts) between connected modules can be discovered automatically. What this means is that fast trial-and-error composition becomes feasible. But it gets even better than that.

Darwinian Selection

Given that, in a COSA development environment, components can connect themselves autonomously and that motor conflicts can be discovered automatically, it is not hard to envision a mechanism that can compose reliable and possibly useful applications through random trial and error, from a pool of pre-built components. Simple survival of the fittest. Of course, it is always up to the human developer to decide whether or not to accept the system's inventions but this would take software development up to a new level of productivity and serendipity. Who knows, a nice surprise could pop up every once in a while.

PS. Some of my long term readers may find it strange that I, a Christian, would be using words like 'Darwinian selection'. Well, the world is full of surprises, isn't it?