Where Do Patterns Come From

This is from an early December 96 post on the patterns-discussion list in a thread on the definition of a pattern.

Oh, good: a chance to lecture! My girlfriend and many others usually quietly leave the room to grab some coffee when they see me gearing up to lecture, so maybe some of you should also.

The subject of today's lecture: Where do Patterns Come From?

Reading Alexander, it is clear that he believes that patterns of facility and affordance are embedded in the built world and his program of writing them down is a process of discovery and thought. He states that he believes that the knowledge of patterns, once generally known by all who built, has been lost and needs to be recovered through observation and thought. That is why each pattern in APatternLanguage is labeled by a measure of confidence that it is "correct".

In the world of storytelling, it is the same way. Such thinkers as MrAristotle derived their principles of storytelling (Poetics) by looking at examples written or told by masters. Similarly, in modern MFA programs for writers, the means of teaching is to study other writers and their works to mine things that "work", which is a jargon word in the writing business. All literary criticism I have seen (criticism in the broadest sense) is grounded in actual works. In fact, just last night I was studying some criticism by Carl Dennis (a poet) on where authority in voice comes from (from passion, discrimination, and inclusiveness), and his entire argument was based on examples from Ben Jonson, Yeats, Whitman, Dickinson, William Carlos Williams, Lowell, O'Hara, and Zagajewski (I don't expect you to know the last one).

RichardRhodes? in his interesting but basic book on writing called HowToWrite? talks about reading as the primary means of learning to write, and he cautions novelists and other writers of longer structures to learn only from reading because all other teaching means can focus only on shorter forms which cannot tell you much about the longer ones.

In problem-solving, we see the same thing. No matter how smart and clever we may be in solving a problem of complexity in the practical world, we are never sure of its efficacy until it has been tried, and often not until it has been tried a number of times. For example, early programming languages had GOTO statements which were regularly used, but now we never do except when programming with exceptions and procedure calling and method invocation and delegation (but we shouldn't count those, now, should we?).

Because in all disciplines and arts we learn from the masters, why would software be any different? Well, in a way it is. There is no publicly visible gallery of implementations. Let's try this: Who of you has even seen the source code for a system that I have? Emacs? MacLisp? GnuCpp? GDB? (But, in contrast, how many of you have seen Notre Dame? Chartres? the Golden Gate Bridge? - See how much easier architecture is than software?)

Therefore, in software, we write patterns after having observed them as things in the world which through practical proof have been demonstrated as good resolutions of forces. Because we cannot see source code together, it is only through the medium of patterns that we can learn of their commonalities. Hence, pattern discovery in software is different from pattern discovery in architecture, and more the pity. (I have longed to start an institute in which corporations and individuals and schools would deposit their source code so that pattern miners could mine them.)

Pattern miners are, perforce, usually those who have written the code, because they are the ones who experienced the forces that are resolved. And thus they are able to articulate the patterns well. But try to imagine what this would be like in literature: There would be a hidden sort of literature in which some small almost epiphenomenal piece would be visible, but the artistry is largely hidden. You would know something of the art because in school and in other places there would be opportunity to see it, but there would be no great literature of it that reveals the important parts. And all you could do to learn of those parts would be to read pattern languages about them and see yours and the occasional other piece of literature (and not know whether it is great or doggerel). Interesting. But it is like what we in software need to do.

Once patterns are written down as distillations of best practice, then others are able to use them to ensure that systems they write are well-constructed and well-written.

Some might argue that because software is really some branch of mathematics, we should be able to derive patterns from first principles. To those I offer two remarks: People write code and need to maintain it, so human understanding and human frailties are factors and therefore mathematics cannot help; as a former mathematician, I don't feel confident that pure mathematics is prepared to address things of utility in a utilitarian way a priori. Mathematics is the language of explanation not discovery.

The fact that someone would call "bass-ackward" the practice of stating the patterns that exist in a room or in a software system proves my point of the danger of the definition of "pattern" we've been batting around. Certainly if someone built a system using patterns it is not crazy to expect to see them in evidence in the resulting artifact. And once that point is clearly seen, the step of mining patterns from existing software seems obvious (to me). Perhaps we have grown accustomed to the false security presented by mathematics and academic experts.

Thank you all for attending my Monday lecture.

-- RichardGabriel

Further discussion of this post is found in the PatternMiningThread.

CategoryPattern