"A pattern language is a collection of inter-related patterns that can be combined together"

I had some time (not a whole lot) before class and I saw Maurice's post on the class wiki that he has some materials that would be nice to read before his presentation. He has a lot of materials listed down above, but I was only able to go through The City is Not a Tree I & II and also the discussion on it .

From those two articles, I come to understand patterns as a new, non-rigid way of classification of solutions. When people encounter a complex system (it need not be a computer program; it could be a new concept, new theory, etc) their natural tendency is to clump things together into non-overlapping concepts. Doing so aids their understanding of the new material. This works well for most systems that we deal with. A tree-like classification system is an example of classification that favors non-overlapping composition. A concept is in one branch of the tree but not both.

However, by separating the system into non-overlapping concepts, we might actually miss the interactions between them. Most concepts do not exist in isolation. One branch of the tree might be related somehow to the other branch. That tree now should evolve into a graph, where concepts can be interconnected.

We have a natural tendency to favor the tree over the graph for organizing ideas. However, solutions to most interesting problems do not appear in isolation. There is seldom a single solution to problems. Good solutions do not exist in isolation from one another; rather, solutions are usually applied in the context of other solutions in some combination.

Therefore, patterns are a way to understand new concepts and suggest solutions to them. Patterns must be presented within a context - where this pattern had occurred. Moreover, it is useless to propose a solution without understanding what the real problem is so the problem should always accompany the solution. Also, the solution must be presented in honesty: the advantages and disadvantages of the solution should be stated.

This is my understanding of a pattern language from reading the articles above. I am interested in what Maurice will be talking about since he has listed a whole bunch of related materials. It will probably have little to do with the design patterns that most computer scientists are acquainted with. I suspect that he will be dwelling more on the origins of patterns, the pervasiveness of them, and end with a discussion of the usefulness of patterns. It's very tempting to go into the metaphorical and psychological details of patterns but that would be a bit hard for me to swallow. I hope he goes into the classifications of patterns as well. It is very easy to have an explosion of patterns in one particular area and then it becomes hard for the mind to actually see the connections between those patterns.

Update: Overall I liked the presentation a lot. At the end of it, I asked the question on what patterns will turn the programmers into a satisfied Emotional Programmer. Prof. Johnson said that following along the lines of XP usually made programmers happy. I suspect that there are some other patterns out there that could make programmers happy but I have not had a chance to experience all of them yet. For instance, using HumaneInterfaces will certainly help make my day better.