Gatemaker

A contemporary account on Gatemaker can be found at gatemaker.org. A recent account was presented at the 2013 PUARL conference in Portland, Oregon and was pre-printed in RAIN Magazine in 2014 as "Gatemaker: Christopher Alexander's dialogue with the computer industry". site

YOUTUBE o8b7ZBWGmu4 #urbanplanning #architecture #design Gatemaker

Gatemaker: Christopher Alexander's dialogue with the computer industry. page

[…]

# Almost a sequence In their influential 1987 paper, two Oregon programmers, Kent Beck and Ward Cunningham, published what they called a small example ‘Pattern Language’. It was actually a tested, ordered sequence. The intent was to empower users to define their own computer interfaces, and to demonstrate that something akin to CA's patterns could improve the communication of good engineering ideas. The paper describes particular structures that should appear, or principles that should be kept in mind, at each of five stages during the design effort for a human-computer interface:

The importance of the right order, combined with global application of each principle at each step, was an aspect of sequences gleaned by reading the above passages in *A Timeless Way of Building*. ⇒ The Timeless Way Of Building

This part of the paper was also inspired by the ‘user-as-designer’ notion found in all of CA's work. Even though this sequence was only about particular aspects of certain kinds of interfaces, and was unrelated to the natural structures CA aims for, it was still an interesting interpretation.

But it wasn't the right interpretation, which is hardly their fault. [The making of each stage in the sequence into a named pattern is primarily to blame here. So this is an ordered set of patterns, but not an Unfolding Sequence]. Alexander's material is ripe for misinterpretation because, to understand it properly, people need to train to recognize natural structure.

It's not too extreme to say that the authentic transfer of Alexander’s ideas to the computer industry stalls because of this paper, rather than starts because of it. [That's not quite true, because when people subsequently heard about the material, they would investigate it themselves, and think about it as individuals -- so many many kinds of transfers happen. Still, gist of the following is still correct. I hope it will change. -GB] The focus of the subsequent Software Patterns movement remained within the formal sciences, and so couldn't interpret CA’s work in the natural and human sciences: the application of human judgment using feeling, the smooth unfolding of natural geometry, and the task of helping people (programmers or users) to become more whole and alive. The criteria for ‘good’ were so different, that everything was misconstrued, from ‘pattern’ to ‘incremental’. Again, they aren’t to blame: this focus on symbolic abstraction and communication, and the dismissal of feeling, with the dismissal of the reality beyond constructed formal systems, is endemic in the computer industry. Today, Software Patterns proponents, like most successful computer people, are not even interested in this cavernous disparity.

# So what *is* a sequence?

A good unfolding sequence focuses the user’s unfettered concern upon nurturing the growth of natural structure. It encourages people to use their innate feeling for natural structure (which may require training to rediscover) to sensitize themselves to important issues as they emerge, so they will start to see them in any situation. It helps them to achieve organic growth: smooth, adaptive, harmonious, ever-improving and coherent. This unfolding growth should feel related to morphogenesis. A sequence is much like a genetic code, and drives increasingly complex structure, a 'complexity' that is still as simple as possible, coherent, and profound. A sequence is short, but accomplishes a great deal. Again, surprisingly little genetic information guides the development of incomprehensibly complex organisms. Sequence users put themselves into a certain state, a particular working modality. This is an actual, physical, easily perceivable phenomenon. It’s unfortunate that such phenomena are derided as ‘psychological’, even though that word literally means a real state within the brain, whose actual operation we should care about. Like most complex features of the human mind, we understand almost nothing about this phenomenon, yet. But we can use it, to do good work.

[…]

This issue arises continually in CA’s work. For example, the misinterpretations of the Software Patterns movement emerge from a lack of direct contact with CA’s circle. It’s difficult to convey, through writing, the sensibility of seeking a particular subset of instinctive judgments. One needs exposure, in a real situation, to discover how to distinguish X from Y.

[…]

There were roughly two camps in the Software Patterns movement: (1) the original Hillside group led by Beck, Cunningham, Richard Gabriel, Jim Coplien and others; and (2) the ‘Gang of Four’ and the readers of their popular book Design Patterns.

Group (1) was interested in entire pattern languages, the applied order of patterns, combination strategies, and popularity with programmers. Group (2) was mostly interested in finding the best technologies -- patterns that should be enforced, and encoded into programmer tools such as frameworks. This was our impression, in any case. Group (1) didn’t want patterns to be forced, and didn’t want to interfere with human thought. They promoted a workshop approach to writing patterns, which was pleasant and social. So we pursued connections with group (1).

I spent months, as did our business manager John Seamster, trying to determine which computer industry ‘titans’ might be helpful if approached for a grant or partnership. I felt that Bill Joy, co-founder of Sun Microsystems, who was a student at Berkeley for years, looked pretty open-minded. I wasn’t sure how best to approach him, however.

In the midst of our search, in October of 1996, CA gave a speech to the major annual gathering of object-oriented programmers in San Jose, California. The OOPSLA speech is online. He made two important points:

1) The actual goal is to build *natural structure*. 2) Programmers could do *good* for people. They don't need be mercenaries to industry. They have more control than they believe.

The second point was forcefully made -- criticizing the industry’s worship of success, and blind techno-positivism. CA implied a fight against monopoly capitalists that hire engineers only for their own ends. This part of the speech caused several people around me to wipe tears from their eyes. He spoke to a scattered idealism among computer engineers, which was then re-emerging as an undercurrent, because the world was turning upside-down during this time: the original dotcom bubble.

After the speech, I mentioned to Richard Gabriel that Bill Joy might be our best bet. He agreed, said he knew him, and so connected us.

Still, at this conference, I continued to see disturbing regressive intellectual trends within our preferred group -- mostly the kind of Behaviorist and pop-Darwinian dogmas common among Artificial Intelligence programmers, and incompatible with serious natural science. But we pushed on. People can change.

Days later in Berkeley, we chatted for a few hours with Bill Joy and his colleague John Gage. We found a great deal of common ground. Afterwards, I negotiated a direction for research with Mike Clary of Bill Joy’s office. I said that CA and I would create something to help the built environment, but that I would report on the novel implications for engineering. Our business manager, John Seamster, then finalized the contract between Sun and CES.

With this budget, what should we build? Certainly, *some* kind of unfolding sequence tool. We couldn’t know in advance what it would look like, because we needed to do hundreds of experiments, using ourselves and friends as subjects.

To make certain that I understood the potential and power of sequences, CA and I thoroughly discussed the mental toolkit in *The Nature of Order*: centers, properties, cycles, feeling. I sketched my way through sequences, with his feedback, until I became rather fluent in "applied feeling".

I remember some alternative cover designs then came into the office, for the first volume of The Nature of Order. One was nicely balanced, and became the leading cover candidate. But another design, which was probably just a mistake, reminded me of title pages from 16th and 17th century books. And then I realized: it was more *alive*. The title text was *pushing* against the borders. I pointed this out to him. He checked the pages, looked quite pleased, and the ‘mistake’ became the final cover. My first post-training contribution of judgment.

# Recursion and the problem with fractals

At one point, we discussed 'sequences within sequences'. He was hesitant, because discussions of recursion tend to succumb to the wrong human faculties: logical systems over natural structure. He read my article in RAIN Magazine from 1991, on 'the problem with fractals'. Although popular at the time, I was a dissenter, because fractals are such a poor idealization of the real world. In nature, factors and interrelationships typically change at different scales. You can’t find a Mandelbrot set in nature. L-Systems cannot be considered first-order approximations of trees. They tell us more about our perception than about trees. However, we are stuck with our faculties, so idealizations are critically important. We must construct theories. Where would we be if Galileo hadn’t dismissed friction while studying the inclined plane? But we must not confuse theories with nature. We don’t understand nature. At best, we understand our theories. I don’t want to be hard on recursion. I was inspired by L-Systems and Phrase Structure Grammars to bridge the gap between operational and structural descriptions, with a simple programming language called grogix. I don’t want to be hard on fractals: I believe that we might learn something about living geometry by studying some of the Hopalong equations.

[…]

Our workflow was his Fundamental Cycle. I’ll paraphrase:

1. Observe and evaluate the last thing you did, and its support for the Goals, and its harmony with the existing work. ⇒ TCR (“test && commit || revert”) 1. If it didn’t help, undo it. 1. Now, the group needs to think hard and decide what might be the next best step. That means the smallest effort that will make the biggest positive difference. 1. Build it.

Each cycle should be small but significant. We also incorporated this workflow into the user’s experience of Gatemaker.

# No leaps

[…]

Figure 2. The initial screen.