Accessible Fundamentals
Accessible FundamentalsA new visitor to the PortlandPatternRepository took the time to write this critique.
Ward,
I was quite enthused when I wandered across the link to your site, imagining the possibilities. I have had a copy of the PatternLanguage book by Alexander for a number of years, and I expected patterns which would be similar. The patterns in that book are familiar, they are described in plain English which a layman can understand, and they cover a full range of architecture from the micro to macro level.
I was disappointed by your catalog of patterns, but on the other hand, not all that surprised. Some of the things which I found so appealing in the book, are missing so far in the patterns on the site. I think this is in part due to the fact that documenting the patterns that a computer programmer uses and needs will end up being as monumental a task to describe, and not something that can be assembled piece-meal by a group of volunteers.
What I found lacking in the site was the boring fundamentals that made the Alexander book so fascinating. The window, the door, the covered walk. These turned out not to be so boring after all. It makes you re-examine the common place, and re-justify its use in larger patterns.
Where are the references to the loop, the exception handler? The different data structures and data types? Instead most of the patterns are concerned with esoteric macro-level details. There are no micro level patterns to ground these upper level patterns, they float away. I don't understand their discussions, and don't appreciate their conclusions.
Although I have been programming professionally since 1980, I am just learning C++ now. I consider myself to be a competent programmer, and yet I found myself not understanding the terms used in these patterns. I'm sure my mother would not understand, and yet I could convey the pattern of a loop easily to her, with a little more work, I could explain inheritance. I encourage you to continue your work, but please make it accessible!
Thanks.
-- DaveFonseca
David,
You are not alone. One of my Pattern Languages was studied in a reading group at the University of Illinois. One student summed it up by saying it was the most difficult thing he had read since Kant.
There is hope. KentBeck has tackled programming at the level you describe. Have a look at ...
You should also spend some time looking through the part of the repository generally known as "wiki". Here is a wiki request looking for loop ...
There are over a thousand pages about patterns in the wiki database. Most have been contributed by visitors. I've taken the liberty to add your letter. I think the repository readership will take it as a challenge.
I hope you (oh anonymous visitor) will take the time to write a pattern such as you describe. If you see the need for it, you're in the perfect position to fill the need (or at least better than anyone else). -- KentBeck
There was also a (small) discussion about this on the patterns mailing list a few weeks back. The following is a posting Eugene Wallingford made in response to a post by RalphJohnson.
RJ said:
The book "Designing Pascal Solutions: A Case Study Approach" by Michael Clancy and Marcia Linn, from Computer Science Press,1992, has lots of low-level patterns. They call them "templates". They include "process elements in a file until done" and "insert into a file". It looks like an interesting way to teach programming.
and EW replied:
I think so, too. I've been doing patterns of that sort in class for over four years. Clancy and Linn's approach is both better and worse than my patterns: They talk about a larger number of patterns (good), but they don't quite tie them all together, at least in mind (bad). A pattern language composed in part of these patterns would be a neat thing to have.
A colleague, along with me and a couple of others in our department, have been working on a small NSF-funded project to develop course materials for a pattern-based approach to introductory programming instruction. It is making progress but hasn't quite reached the point of being written up in the patterns community. Maybe he/we just need to sit down and do it.
I agree with DaveFonseca. It seems to me like the patterns of objects we often see need to be supported by coding patterns (idioms?), e.g. SubRoutine. Perhaps they already are, read CodeComplete - A Practical Handbook of Software Construction by SteveMcConnell or Advanced C++ : Programming Styles and Idioms by JimCoplien. -- KentSchnaith
It's worth noting that Alexander's patterns are compelling because they are so tangible. A LowDoorway or GreenStreets or SleepingInPublic, for example, almost evoke the imagination without much further description.
Software is not tangible. Whilst I agree that there is a hole where low-level software patterns belong, I cannot agree that patterns must or should be made physically or emotionally compelling.
One cannot be in the proximity of a software pattern and bask in its light, or rejoice in its harmony. One can dissect a piece of software and marvel at its elegance for a while, but this doesn't produce much in the way of warm and fuzzies.
That software isn't tangible is regrettable, of course. There's little point in wishing it were otherwise.
-- StevenBlack
Just because it isn't tangible doesn't mean that we should give up trying to involve emotion. Poetry is an excellent counter-example to your view.
Patterns that are compelling and involving will be used and remembered. And I certainly get a rush of aesthetic pleasure when I see a pattern used well.
-- KentBeck
Accessibility Aids Available For Patterns: WikiPagesAboutWhatArePatterns
EditText of this page
(last edited December 7, 2006)
or FindPage with title or text search