Thread by @brunopostle

One of the more interesting things to happen in architecture during the late twentieth century was the discovery by Christopher Alexander of 'Pattern Languages'.
jomardpublishing.com/UploadFiles/Fi…

'A Pattern Language' has 253 chapters in a kind of early hypertext format; the idea is that a collection of patterns like this forms a thing called a 'Pattern Language', and Alexander's book is just the first of these.

The 'patterns' in A Pattern Language are not fabric or wallpaper designs, but solutions to typical everyday architectural problems. They can be thought of as each being a guide to meeting a specific human need through architecture.

Each Pattern in A Pattern Language consists of a statement about an aspect of the built environment, noticing problems and suggesting solutions; the pattern is then linked to related patterns that should also be considered at the same time.

Alexander ordered the patterns in his Pattern Language book by geometrical scale, with city level patterns such as 9 SCATTERED WORK at the beginning of the book and 249 ORNAMENT at the back.

105 SOUTH FACING OUTDOORS **
People use open space if it is sunny, and do not use it if it isn't, in all but desert climates.
[...] Always place buildings to the north of the outdoor spaces that go with them, and keep the outdoor spaces to the south.

The patterns in A Pattern Language are unlike most of the rest of 'architectural theory' in that they are testable and falsifiable: here is a way of doing architecture as science. cnu.org/sites/default/…

The patterns in Alexander's Pattern Language are not a design method in themselves, they are rather a guide for assessing a plan of action, assessing potential designs, or assessing actual places and buildings.

If you are somebody who pays attention to these things you will have noticed that actual real architects don't make use of Pattern Languages. At best Alexander's book is thought of as a historical curiosity, at worst it is too restrictive of the architect's artistic expression.

A 'creative designer' collects relevant information, then they think real hard, and produce a design as a creative act; the greater the genius, the greater the creativity, and the better the resulting design - A Pattern Language is a fundamental challenge to this way of thinking.

Alexander himself considers A Pattern Language to be incomplete or inadequate, "my biggest failure".
transitionculture.org/2010/12/23/exc…

Alexander's problem was that the Pattern Language itself was taken to be a series of rules, and the result of using it like this for architecture were often crude or badly formed.

After A Pattern Language, Alexander became interested in the process of morphogenesis in organisms, describing this as a process of step-wise unfolding where each part of a structure and each stage of development embodies what he describes in metaphysical terms as 'wholeness'.

Alexander's idea of 'wholeness' itself is expressed in fifteen properties or traits that Alexander believes are inherent in all things that have emerged through a process of incremental change.
tkwa.com/fifteen-proper…

If you accept Christopher Alexander's ideas then you realise that 'modern' architecture: minimalist detail, bold shapes, industrial repetition and monumental scale; are 'anti-patterns' that, although architects find them creatively satisfying, don't actually meet human needs.

Modernist architecture, something that would otherwise just be a slightly weird fad from a century ago, has somehow become associated with all that is progressive, and resistance to it has become associated with everything that is backward, traditional, conservative, Luddite.

Those of us who want a humane, human-scale, and ecologically-sane living environment as promised by A Pattern Language, but who don't feel either 'traditional' or 'modernist', what then do we do?

Christopher Alexander believes that we are going to have to change to working adaptively, evolving buildings through incremental changes using Pattern Languages as a guide.

This theory of Pattern Languages is an alternative approach to architecture that is largely neglected, disdained and sidelined. At the same time we have a standard architectural creative design method that does seem to be a bit hit and miss to say the least.

If we judge by the quality of the cities around us, it seems we don't have enough creative geniuses, our geniuses are not good enough, or maybe we can be generous and say they are just not given the opportunity to demonstrate their genius?

If you come from a Computer Science background, you might think that Pattern Languages for buildings sounds very similar to a big thing in Object Oriented programming called Software Design Patterns – you would be right because the two are directly related.

Software Design Patterns describe a very practical way of working, so much so that you will hear programmers, even those who have never read a book, discussing projects in terms of patterns – the influence of Alexander's Pattern Language is everywhere.

The first wiki was devised by @WardCunningham specifically as a repository for software Design Patterns - everyday tools like Wikipedia have this influence from Alexander's Pattern Language at their core.

We are all familiar with finding ourselves with a task that turns out to be something entirely different once we get started, in software, as in building, this is a normal state of affairs rather than an exception.

When making incremental changes, it is best to choose the change that makes future changes easier, rather than aiming directly for the goal.

In architecture we have a huge problem. The divergence between our existing systems of building and a humane, ecological, living environment seems insurmountable.

Well constructed software is universal, it can be duplicated millions of times and still behave the same in different locations, on different operating systems, unexpected situations, and different hardware; it is modular.

I used to think that there could be some building equivalent of software, a mass-produced 'pod' that can be quickly moved around the world, you could imagine an Open Source architecture where designs for these modular pods are shared and improved collaboratively.

Buildings are not the same as software, buildings are specific and software is generic, every building has to exist in an actual location which is different to a finite number of other locations. For software, space is cheap and all distances are small.

For buildings, not only is space expensive, but distances are critical. Distances for people tend to be very significant; when space is sparsely occupied, travel distances are further, entailing additional costs and other negative effects.

Software is useful when it saves people from doing repetitive or unnecessary tasks.

Efficiency in buildings and the spaces between them is very different to efficiency in software, efficient buildings are packed together, consuming the least amount of space and materials for the most amount of utility.

The utility of a house is unrelated to the degree of modularisation, a generic pod-room or pod-house will always be just a little too big, or a little to small or just the wrong kind of shape.

Software Design Patterns are not about placing widgets on a screen like placing rooms in a house, rather they are about how you go about wiring the widgets together behind the scenes.

If you find yourself with a software problem where two Design Patterns are conflicting, where there is an overlap in functionality which means that you can't implement either pattern in full, then this is a sign that you are doing something wrong.

When designing a house there is a constant trade-off, a process of give and take that necessarily results in compromises.

Every built space in the real world is the result of a balance of needs and costs. If we are building with a Pattern Language, then each pattern can never be implemented in full - this is why A Pattern Language can't be used as step by step instructions.

This book, A Pattern Language, describes a built environment that is humane and human-scale without eating the planet, but the ideas behind it have been far more successful for writing software. The influence in the architecture profession is somewhere near zero.

Adaptation is a process of evolution through incremental change, think of it as different to invention, which is the application of inspiration to create something new.

Specifically, life and life's evolution through selection is adaptive, Darwinian natural selection means that organisms that are the best fit for the environment are the organisms that go on to produce the next generation.

Pattern Languages for architecture require an incremental, adaptive, approach. But making a decision for any single building situation involves balancing potentially dozens of patterns.

With multiple patterns to be considered, every design decision can have unseen ramifications beyond the task in hand. With a Pattern Language, how can a single person juggle all these variables at the same time?

In computer software terms, balancing multiple interacting variables is an optimisation problem, specifically this is the kind of hard problem that can be tackled using Evolutionary Computation.

Here's our idea: how about trying a different approach altogether for designing buildings? Can we create software that designs buildings in an evolutionary way using Pattern Languages as fitness criteria?

What if we can describe the steps necessary to unfold a building using a genetic 'code', and that genetic code can be mutated or crossed with the 'code' of other buildings?

What if we put building designs in a simulated environment of a Pattern Language, of daylight and surrounding landscape, and try to evolve them to fit?
bitbucket.org/brunopostle/ur…

Pattern Languages have already proven to have a profound contribution to the computer science field, it remains to be seen whether A Pattern Language will have the equivalent influence on architecture and the built environment as was originally intended.
jomardpublishing.com/UploadFiles/Fi…