Hi Marcel et al,
It is interesting that you should write about patterns in this way.
I was reading some 'propaganda' about Lisp some time ago on Paul Graham's web site and the following quote really made me sit up and take notice: "When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write."
(The whole article can be found at: http://store.yahoo.com/paulgraham/icad.html)
This is very similar to the way you describe it and I can't help but come to the conclusion that "patterns" is taking programming down the wrong path!
Regards,
Karl
On Sunday, Dec 1, 2002, at 20:52 Australia/Tasmania, Marcel Weiher wrote:
Yes! IMHO, ALL patterns are like this. Think of it: why should there be repeating patterns of code in our programs? There shouldn't be! If there is a "pattern", we should be able to somehow express the pattern and encapsulate it. "Once and Only Once".
So I consider a pattern a bug. Not a bug in the program, but a bug in the programming language. Or let's call it a shortcoming, because the language cannot encode this pattern in a way that I can put it in a library and forget about it. I think the fact that many patterns necessary in a primitive language ( C++, Java ) are not necessary for their more advanced predecessor (Smalltalk) supports this point of view. However, we shouldn't be too smug: the Smalltalk Pattern Companion is not empty. In an ideal world / programming language, there would be no patterns books.
There is some reason to believe that such an ideal world may be even theoretically impossible, or at least impractical, but that doesn't mean we shouldn't treat patterns as indicators of something being wrong.