PatternLanguage

ThoughtStorms Wiki

See ChristopherAlexander

Not sure in what sense this is a "language"? – SJ

Well, the original use of "language" by ChristopherAlexander, rather than say "Pattern Collection" or "Pattern Encyclopedia" is because he thought that patterns were composed "grammatically" :

  • they were inter-dependent. You can't consider whether a pattern works in isolation. It has it's "meaning" only in connection with, and in the context of others.
  • and when you understand the grammar of patterns, it can help you compose your architecture.

Alexander understands the notion of grammars as generative rules. He really thinks that patterns need to be fitted together the way nouns, verbs and prepositions are. That is, patterns constrain, and make more likely other patterns, and there's a sequence (word order) in which you produce them. Once, as an architect, you are fluent in the pattern-language, you will speak and read it without consciously having to think about it. You will simply use the patterns to express what you want.

KentBeck paper : https://web.archive.org/web/20041204141137/http://c2.com/doc/oopsla87.html

For APatternLanguage, the book, see also BookList

See also PatternLanguageForTheSocialNetwork, TheNatureOfOrder, JimCoplienOnTheNatureOfOrder, OnLanguage

Phil - Am I right in thinking this concept could be of wider interest for non-programmers?

If so could you possibly give a brief 'pop' exposition for non-techies?

Darius.

I'll see what I can do, it's a rich subject. Basically pattern-languages come from a group of architects / urbanists in the 60s and 70s, led by ChristopherAlexander. They rejected the modernist ideas and obsession with geometric simplicity. On the other hand, they weren't just retro. They're interested in the organic, traditional and systemic properties of architecture and urbanism. A good example of Alexander's 60s writing is the paper ACityIsNotATree, (linked from that page) which starts with a mathematical definitions of trees and semi-lattices in terms of set-theory; then does a quick survey of modernist cities (including Brasilia) showing how they have "tree" form; does a quick excursion into pop-psychology to explain why city planners think hierarchically; and ends on one of my favourite flights of rhetoric I've read this year.

Christopher Alexander is explicitly looking for an ObjectiveTheoryOfAesthetics in architecture. In his book : ATimelessWayOfBuilding (the first Pattern Language book) he's looking for what he calls TheQualityWithoutAName (or the Timeless way), which has slightly mystic overtones, and the book occasionally goes in that direction, but not too much. Basically, his group thinks they can see lots of examples of "nice", "beautiful", "good" architecture and urban configuration, and they set out to document it and learn lessons from it.

However, what's interesting is the method of documenting. Timeless Way of Building is accompanied by a second volume called APatternLanguage, which is essentially a catalogue of patterns. Patterns are defined as combinations of patterns of activity and patterns of space. (What urbanists sometimes call semantic and syntactic)

Alexander's catalogue of patterns has several interesting features :

  • it explicitly tackles various scales of structure, and argues that these scales are inter-dependent. The catalogue starts at the large scale, with a note about how cities should be distributed around the country! The next couple zoom in to the particular city and it's relation to the countryside, then gets down to the various patterns in the layout of the city.) About half-way through it starts getting into the details of individual buildings and gardens, and finishes on advice on decorating your rooms. (Maybe this interaction between scales is Holopticism?)
  • the second interesting emphasis is the one I mentioned at the top of this page. Alexander argues that patterns are to be composed linguistically (that's why it's a language and not a pattern catalogue.) Linguistic here means that patterns need to be composed and that there is some kind of generative grammar for composing them. He thinks that when you learn the language, sequences of patterns will flow out of your design process like lines of poetry. Of course this is all metaphorical and you still have to figure out what it means to compose the patterns.
  • the patterns themselves are documented in several ways : with a name, a photograph of an example, a description, a description of the problem they are meant to solve (or the reason for implementing them), a lengthier meditation on the pattern, and a list of other patterns it relates to in some way. It's this last which helps you learn to compose the patterns.

In architecture, Alexander is often quoted, but patterns don't seem to have become a mainstream technique. Alexander himself seems to have been disappointed that the buildings which came out of his research weren't beautiful enough and has gone looking for better, objective rules of beauty (by showing people from different cultures Persian carpets and asking which they prefer). Meanwhile, patterns were picked up big-time by the software development community at the end of the 80s, early 90s.

When I was doing my first degree, software engineering was still in a phase of influence from mathematics. The idea was that programs were just a slightly vulgar and debased form of mathematical proof, and that the way to ensure quality software was to teach programmers to be better mathematicians, using more rigorous, formal encoding systems to specify and communicate what software was meant to do.

In the 90s software got bigger and more complex, and the favoured programming technique, ObjectOrientation was never suited to formal mathematical analysis. But pattern languages turned out to be great way of documenting the accumulated wisdom of and experience from previous projects. In software, it turns out that the same kinds of problems and solutions arise in many situations. At the smaller scale, these similarities could be called algorithms and given formal mathematical definitions and standard solutions could be proven. At the larger scale the best you can do is document the problem you are trying to solve, and the solution. A lot of these turn out to be variants on "when we originally wrote the program we made these two modules too interdependent, but later when we tried to swap from running on Windows with SQLServer to Linux with Oracle, it was a pain because there was too much SQLServer specific knowledge in the windowing code" and the solution / pattern was to seperate them out like this." But in fact there's a lot of subtlety in this kind of question, and there are several varieties each of which can be appropriate according to the context.

Patterns work well for this kind of documentation because software is also a combination of space and activity (or data-structures and control flow). However, in general the software use of patterns is a lot more pragmatic / mechanical. There's not much of Alexander's obsession with aesthetic values or capturing timeless ways. Of course, there are theorists and thinkers who have fascinating discussions and insights, but a lot of people apply standard patterns automatically because that's the obvious thing you do (Compare my discussion of ModelViewController, often acknowledged as the first explicitly documented software pattern) Also, a lot of patterns are very specific. If you read books of JavaLanguage patterns you'll find patterns which really only exist to overcome bugs or quirks in a particular version of Java, and when the next version comes out, half of them are deprecated. It's as if people started coming up with London patterns derived from particular architectural quirks of London.

What about wider applicability?

For me patterns are interesting epistemologically. They seem to occupy a space we haven't filled before. They aren't scientific laws. They admit exceptions. Nor do they claim to be statistical laws. On the other hand, they're more than anecdotes, there's a claim that they can be generalized or abstracted away from individual implementations. Nor are they heuristics, because that word seems to imply an technique for doing something. But patterns describe an objective state of things, not just a practice. Yet because they are patterns of space and activity thay capture both the fixed and dynamic, and the relation between the two. (See also TheScientificStatusOfPatterns)

Also patterns are incredibly ambitious. I was ranting to Guillaume the other day about the failures of Brasilia as a city, and he basically said : "OK, but what should architects do?" implying that it's OK to criticise, but where's the positive proposal? Basically, the original Alexander pattern language is a practical suggestion of what architects should do. It's an attempt at a general theory of a good design of a huge, complex, dynamic system. Software people have adopted pattern language approaches, partly because they are something that can, at least help, when designing huge complex dynamic systems, unlike the formal mathematical / engineering methods which don't scale.

– PhilJones

Thanks Phil.

So what makes it a language is the connectedness of individual patterns contained in the 'list of other patterns it relates to in some way. It's this last which helps you learn to compose the patterns.'

But is this connectedness developed enough to make it a 'grammar'? Are the ways in which the patterns are related to each other described or 'typed'? Or are these just lists of links, like the links between pages on the wiki? If the latter, could there still be a hidden or as yet undescribed grammar of patterns out there somewhere?

– DariusSokolov

I guess when you say typed you mean something like verbs and nouns? I don't have the Alexander language in front of me right now but I don't think it types the patterns this way. Software patterns tend to be categorized but that's according to application (eg. patterns for generating new objects, patterns for using components etc.). So there are times when you know you need a particular sort of pattern for this : separating two subsystems cleanly, but you don't yet know which the right one until you think further. (Maybe a bit like knowing you need a noun but not which one.)

I also think you could analyze a number of pieces of architecture into patterns and thus extract statistical relations (ie. if you have pattern X then you have a 45.89% chance of pattern Y) which could presumably go into some kind of Markov model. And this is one technique which can be applied to languages.

But at the same time, if you press me, perhaps the "language" connection is a pretty flowery metaphor. And maybe the claim of a real grammar isn't sustained. I need to think about this and try to research a bit more.

Discussion with Darius continues on TypologiesAndPatternLanguages

Patterns also have a humanistic dimension. Alexander's patterns make claims about how humans live, and how they live well.

Perhaps the only comparable thing to a pattern language (which is, admittedly even vaster) is law.

Darius's : Or are these just lists of links, like the links between pages on the wiki?

Of course, wiki was originally invented to help capture and document patterns. The first wiki still lives at the Portland Pattern Repository : Wiki:WikiHistory)

PatternLanguageForOrganizations

See also DesignTheory

CategoryDesign, CategoryEpistemology

Backlinks (31 items)

Page Last Modified @ Tue Jun 04 16:55:03 BST 2024 Exported from CardiganBay @ Sat Dec 14 11:22:03 GMT 2024