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.