Motivation

I'll assume something that I believe is uncontroversial: that natural living systems are, so far, capable of more coherent and robust complexity, and behavior, than are human-engineered computing systems.

So let's look at the ways biological systems develop and see how current software practice deviates from these.

There are many obvious differences, but I need to start somewhere, so let's start with differentiation during development.

In a program, we apply ourselves to a "soma", or "body of software", and change it, incrementally, attempting to make changes to the whole that are consistent, effective, efficient, simplifying, etc. We usually fail to do so, especially when the software becomes increasingly complex, and other demands draw our attention away from diligence. This happens because we are fighting against troubling truths: 1) the inherent difficulty in maintaining complete knowledge of the whole program, 2) the inherent difficulty in knowing and communicating good solutions to difficult problems, and 3) every system we interface with has faced these same truths, and so the failures have a tendency to compound.

Biological systems, however, are faced with the same truths. But there is no attempt to 1) create a single point of failure (equivalent to the programming team) which must have complete knowledge, or 2) resolve each issue and problem with a new sets of differentiations, created essentially from scratch, or 3) depend upon other failing systems.

The primary pattern for biological differentiation is the sequence. The genetic code modifies the soma by applying a series of operations, across the entire system, in the appropriate context.

So, let's try programming in this way. Say that we try to create a generative sequence that effects / creates a body of code.

There are three ways one might approach this. The first two are essentially implementable on top of current practice:

a. Create a "sequence reader / creator" that operates upon a passive codebase, analyzing it at each stage to see if an operation in the sequence is applied in the appropriate context. This "reader / creator" is essentially a code generator, and the sequences would be written in a language of "software unfolding" which I'll describe later, but which anyone with some time and introspection could create, if they follow some morphological principles (which I'll also describe later).

b. Create a "sequence reader / creator" that operates in conjunction with a class / object framework, and which assumes that emerging objects will maintain complete knowledge of their context, which they can provide to the "reader / creator", which then provides instructions to them, regarding their further differentiation.

c. Create "pieces" of software, of some sort, "cells" or "objects", which have access to the sequence, and which determine their own next differentiation (including the creation of new cells) based on their context and the instructions in the sequence.

It's clear that (c) is closest to living systems. It's pretty clear that this somatic mechanism is not hard to create: although a clear prerequisite is a system and language that emphasizes self-modifying code, making it extremely easy. Most systems are not like this, and in fact consider it dangerous -- but creating a system with this capacity is not difficult.

Given this somatic system of self-modifying/differentiating code, we still need to know what the language of differentiating software sequences looks like.

The language certainly depends upon the somatic system to which it provides instructions. This is clear from both a programming perspective and from a biological perspective, so we're still on the right track.

We need to make this a system which works in the real world -- that is, we need to be sure it can be deployed to bring coherence and robustness to existing systems. Otherwise it is only a biological simulation, and we'll discover nothing about the effectiveness of biological approaches on human engineering.

More on both the "sequence language" and the "soma" in the next post, and on core memory.

The Generic Goal

At the moment, the only computing sequences that I've developed, that are helpful, are not completely generic. Even for the same product, say, an e-mail client, a sequence can barely be written that "stays above the development environment". It's much easier to stay within the environment, for now, and work slowly towards building languages and environments that are better suited to smooth sequences of coherent software development. At that point, computing will be sufficiently advanced that it will be possible to write generic sequences for a particular product, where the implementation details are kept within the explanation of each step, and don't invade the body of the sequence. They become, in a sense, pure design sequences ... very much like those Christopher Alexander is working with.

In the meantime, we should value those bits of the development environment that do invade the sequence, because they point out the fundamental problems with the programming environment.

Good Paths

I've been reading Marco Polo lately ... and of course the first thing that strikes a modern person about this book, is that the world is described as paths: from place-to-place, from city-to-city.

The modern world, with its boundaries and territories, is quite unnatural, and the source of great misery. We might consider a change in perspective.

If you follow your cat around sometime, on her policeman-like rounds in the backyard, you'll see that she goes from place-to-place, along a particular route, between objects, rubbing each one. She is Marco Polo.

These are well-worn paths. They are also good paths. There are other good paths, certainly, but there are far more bad paths than good ones.

So this prompts a question for programmers and other engineers: where are the well-worn paths? Why are they not described anywhere? Are we so busy creating products, that we cannot describe, to those who follow us, how and why we did what we did?

This is part of my motivation for core memory.