|NormKerth initiated this discussion. It was still on-going when I compiled this protocol.
I have been thinking about all the discussions we have had on how to organize the pattern papers, and at the same time I have been looking at EuroPLoP and PLoP papers.
I have noticed that paper organization and acceptance criteria are all oriented towards the view that we are writing about patterns.
Some where along the way, we have lost the whole concept of a pattern language, (that is a number of patterns woven into a grammar that suggests an ordered usage of patterns). The real un-tapped value in the whole patterns movement is in this weaving together of patterns.
I don't think this has been lost. I just don't think it has been discovered. There are certainly patterns that are useful when used together. But I don't believe we have really discovered anything along the lines of what Cope likes to call a "generative pattern language"; i.e. a group of patterns, which when used together, generate applications like water crystalizes into snowflakes. -- RobertMartin.
The GOF book introduced a handful of patterns that the world went wild over. But now we have several hundred patterns, and soon we can expect thousands. The issue of knowing about the right pattern is upon us. The indexing project we worked on during the last Hillside meeting helped a bit but also demonstrated how far we have to go. The indexing project did involve a careful understanding of the system of forces involved with at real-life problem.
Although indexing projects are probably a good idea, the only real way to know the "right" pattern to use in a situation, is to already know the "right" pattern to use in that situation IMHO. In other words, patterns can only do you good if they are in your head. As long as they stay in a book, they are useless. RobertMartin
A pattern language on the other hand does attempt to solve a large complex problem by reducing the issues into a number of small manageable issues.
The issues and questions that need to be asked about pattern languages is different from simply talking about a single pattern. If we do not have the pattern language framework to judge quality of a pattern, we are left with being generous -- accepting a single pattern, not as one that we would embrace but because we can see that it might do someone some good in some way. I wonder how many of these kinds of patterns Alexander rejected because they were in-appropriate when considered within a grammar of patterns.
Frankly, I could care less what Alexander did. His problems are not the same as ours. I would be very upset of some self proclaimed guru decided that one pattern or another was not fit to publish because it did not fit into their personal schema. RobertMartin.
I suggest that we consider Pattern Language papers separate from Pattern papers. I suggest that we have separate acceptance criteria, and I suggest that pattern languages be separated from patterns. As pattern languages involve more complex problems, it takes more to develop the ideas. As a result I suggest that the page limit be adjusted for pattern languages.
The world understands what a pattern is, but has not yet appreciated a pattern language. we can help that thinking along by making the distinction explicit. And the adding the editorial support to further thinking.
Perhaps. There have been quite a few pattern language papers at PLoP, yet very few of them have shown the kind of relationships that Alexander tried to express in "A Pattern Language". The one that comes closest is Cope's paper on development team patterns; which was not a software pattern at all. Remember, Alexander's pattern's had more to do with art than with structure. But in software we are more concerned with structure and performance than with art. In art, there are lots of strange relationships that may yeild to a pattern language of some kind. But in engineering, I am not at all sure that that is the case. RobertMartin.
For PLoP 95, John Vlissides and I debated this issue and we agreed to disagree, stay with the PLoP 94 format because of time pressures and revisit the issue when we had more time. So here we are but with more time to discuss it.
NormKerth, June 1996.
A pattern that does not have use by itself is worthless. Any pattern that is useful by itself deserves to be published, irrespective of whether it happens to fit into somebody's idea of a pattern language.
RobertMartin, June 1996.
Not true. A pattern may only have value in the context established by a series of patterns that preceed it. The workshop that begot hillside was dedicated, at my insistance, to exploring such systems. The light went on for several of us while doing an exercise on the side of a hill. Much of our efforts since have been devoted to lighting that light in others. I, like Norm, am saddened when I see such lavish attention devoted to isolated patterns. They may be useful. But there is a limit to how brightly they can shine.
WardCunningham, June 1996.
The page limit is a soft rule. My first PLoP paper was a pattern language that required a *lot* more than 12 pages. So I got creative and wrote 12 pages of brief description, and then 30 pages of appendix that contained the actual patterns. The whole paper was published in PLoP94.
If the page limit is increased to, say, 40; then we may wind up with a *lot* of 40, 50, and 60 page papers. (Murphy's law of blackboards, no matter how much blackboard area you have, you always need an extra square foot.) Such papers could be difficult to shepherd, and difficult to review in writer's workshops. So, if the page limit is increased, I suggest that it be a nomial increase: e.g. 15 pages.
RobertMartin, June 1996.
I thought your criteria are very well done. I have one suggestion -- the acceptance criteria shows a focus towards the area of presenting a pattern. I suggest that you think about alternate criteria for pattern anguages. For example:
Presenting a Pattern Language
|Last edited July 5, 1996
Return to WelcomeVisitors