Realtimecollisiondetection.net/blog

http://realtimecollisiondetection.net/blog/?p=81 
=== christer ===
said,
June 25, 2010 @ 11:12 pm
Matt, there’s a big difference between the word “pattern” as it occurs in a dictionary and the word “pattern” as it is used in design-pattern contexts. It doesn’t seem you see the distinction as you claim we all develop patterns and that tricks are patterns. I couldn’t disagree more.
Do you call everyday life commonalities for “xxx pattern”, like you obviously do for a programming “design pattern?” Like, say, the “opening pattern” which can be applied to car doors, cans, and caps. I doubt you do. In fact, I doubt you label any commonalities outside of programming a pattern (in the “design pattern”-usage sense) even though you clearly could. Ask yourself why is what? No, really. Apply the opening pattern to your mind and consider deeply why we don’t see people talk about “design patterns” in carpentry (the “v-claw pattern”) or mathematics (the “substitution pattern”) or any other field and then draw the obvious conclusion.
And of course I’m overstating! The message would be muddled if I said that something is 98% bad. The message remains the same though: pattern terminology and usage thereof rots the brain.
BTW, data structures have nothing to do with design patterns, and vice versa. Why mix them? Data structures (like algorithms) are language independent, design patterns are language dependent. The former (two) is timeless knowledge. The latter is perishable knowledge (with a best-before date of 1994)!
=== sock puppet ===
aThirdParty, Twylite’s comment was feeble-minded for the following reasons:
1. He suggests that all nouns are useful. But this is trivially a false statement as once we reach as many nouns as there are concepts, the nouns have lost their abstractive power and have become worthless.
2. He correctly identifies that design patterns have lengthy definitions and a limited domain, but fails to note that they are, in fact, much more limited than so; they are so specific to a particular development methodology and a particular language that they effectively have no expressive power beyond those.
3. Worse, he fails to read the actual message, not seeing — even though it is plain to see in just about every of my comments — that it is not an issue about the descriptive power of “pattern nouns” but one of leading a whole generation of programmers astray thinking that patterns are important when they so are not. To prove his total ignorance of my point, he still posts about the descriptive powers of nouns (and even so, gets it wrong, as per points 1 and 2 above).
In other words: his comment has less relevancy to my post than Palin’s statement about Putin’s head floating in Alaskan airspace had to Couric’s question.
That you did not see this feeble-mindedness in his comment I find disappointing.
You are right on one thing though, I have little compassion for feeble thinking. I find my compassion is better expressed as donations to ACS than as trying to spell things out, as I did in this post, only to find e.g. that some still don’t get a simple reductio ad absurdum argument (point number one, above).
scathye said,
October 24, 2008 @ 12:17 am
Have you looked at the chapter on design patterns in Richard Gabriel’s “Patterns of Software”? In it, he describes C Alexander’s problem with his pattern language approach as being too large, too coarse, and that there was a smaller, more fundamental organizing force in design going on. He describes this in the context of 2D carpet patterns in “A Foreshadowing of 21st Century Art, The Geometry of Very Early Turkish Carpets”.
So Alexander, in my own words, felt the tail(pattern) wagging the dog(design). I don’t use design patterns per se, but feel they are an attempt at bringing more abstract conventions to programming. Which I am all for, as long as the compiler can check them!
By conventions, I mean if there is a function called “open_blah”, convention suggests a “close_blah” also exists, and these conventions are important for creating navigable space in terra incognita.
http://en.wikipedia.org/wiki/Christopher_Alexander
http://en.wikipedia.org/wiki/Pattern_language
http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf
It is sad to see R Gabriel giving his work away. The book is worth buying (I have twice), if you don’t mind more questions than answers. The section on Gabriel’s academic career is very revealing.
aThirdParty said,
October 24, 2008 @ 1:08 pm
>1. He suggests that all nouns are useful. But this is trivially a false statement as once we reach as many nouns as there are concepts, the nouns have lost their abstractive power and have become worthless.
His statements were not certainly constructed in a rigorous manner. I will attempt to do better.
When he says ‘Design patterns have a use: they are nouns.’:
I think it is unreasonable to take this as saying ‘All nouns are useful, design patterns are nouns, therefore design patterns are useful’ which is how you seem to have interpreted it.
I would instead have assumed he was saying that _some_ design patterns are useful because they provide us with useful nouns.
I agree with this argument.
I think some design patterns are useful in that they provide us with a simple way to express a high level abstraction.
Take the Observer pattern. This is clearly a commonly used technique when architecting certain pieces of OO software. It’s all over swing, for example. I’ve also seen implementations in C++ GUIs. I’ve also seen it implemented by people who have never heard of design patterns.
When I meet another developer to discuss architecture, and they suggest using Observer in a certain area, then, much like Twylite’s post says, that quickly conveys a lot of information to me. Assuming, for argument, that observer happened to be the right way to build the software, then is it not useful to have that noun available to quickly communicate the architecture?
This is, I believe, what Twylite was trying to say. I agree in that sometimes certain design patterns provide nouns for high level abstractions that are useful to have. I think this is a good thing, as it can save time, and increase clarity.
I have yet to see you refute this point by sound and reasoned argument.
Note, I am not saying all patterns are useful nouns, just disagreeing with you when you say none of them are. I am also assuming in my hypothetical situation that the choice of the observer pattern was correct independent of any prejudicing knowledge of the pattern. You could argue that knowledge of patterns biases the architecutre towards their use, and that would be a valid point against, but would not diminish the point for.
To make my own position clear, I agree with you that attempting to use design patterns as the initial building blocks of a large OO system is not a good approach to architecture. I have seen situations where it leads to both overcomplex and ill-fitting design.
>2. He correctly identifies that design patterns have lengthy definitions and a limited domain, but fails to note that they are, in fact, much more limited >than so; they are so specific to a particular development methodology and a particular language that they effectively have no expressive power beyond those.
Depending on what your exact definition of pattern and methodology is (care to field one?) they may or may not be specific to a particular development methodology.
But they are certainly not specific to a particular language.
You have said this multiple times, and it is demonstrably rubbish.
The observer pattern, mentioned above, can clearly be seen in Java, C++, and a host of other (OO) languages.
So please retract the point that patterns in general are specific language, or clarify that you in fact meant specific to broad class of language (those that are OO, which is a sizable portion of popular languages).
It’s worth noting that some people define pattern more broadly, and have patterns that are non-OO too – but this might be a semantic irrelevance here, if by Design Pattern you were limiting your discussion to those in the GoF book.
>3. Worse, he fails to read the actual message, not seeing — even though it is plain to see in just about every of my comments — that it is not an issue about the descriptive power of “pattern nouns” but one of leading a whole generation of programmers astray thinking that patterns are important when they so are not. To prove his total ignorance of my point, he still posts about the descriptive powers of nouns (and even so, gets it wrong, as per points 1 and 2 above).
>In other words: his comment has less relevancy to my post than Palin’s statement about Putin’s head floating in Alaskan airspace had to Couric’s question.
Regrettably I am not familiar with the context of the good governors remarks; but I shall assume you are not using the example as one of high relevance.
IMO, you attack design patterns unequivocally, stating they are from, and strongly implying they have no possible benefit or use.
He provides an argument in favour of design patterns, which you have not previously mentioned or refuted in your post.
Therefore, I see direct relevance to your post in what he says.
=== christer ===
I really have no intention of replying further here, because those who haven’t gotten my message already never will. That said, some final (late) comments:
unwesen, on the silliness that is your “[design patterns are] no more than a name for an approach to pounding nails into a board” analogy. Ask yourself, do carpenters have different names for “approaches to pounding nails into a board”? (Go ask a carpenter. No, really, go do it!) Of course not! Unlike programmers, carpenters are intelligent people, and they wouldn’t even dream of doing something as moronic as assigning a name to nail pounding!
Kenneth, these are all perfect examples of academic questions that have little practical value beyond getting someone a thesis. These questions and attempts at answering them do not belong on my blog. This blog is for discussing real-world issues.
Greg, “language dependent” is not a singular but a plural reference to languages. And, yes, I’m 100% serious, modulo the five somewhat randomly picked subjects of the sentence.
=== unwesen ===
said,
March 16, 2010 @ 1:16 am
Took me a while to realize that you’ve written a reply, christer. Sorry about that.
It’s true that there’s only one way to drive a nail into a piece of wood. On the other hand, there are plenty of ways of joining two pieces of wood (go ask carpenters about that, if you must bring them into the discussion). The “hammer-nail” pattern is just one of them; offhand I’ve personally used the “glue pattern”, the “wood plug” pattern, a combination of the glue and wood plug pattern, the “screw pattern” and even some attempts at proper joinery. err the joinery pattern.
You don’t need to call it a pattern if you hate the word, call it a technique.
Carpenters are lucky compared to us in that even the most complex technique of joining two pieces of wood they employ can be described — not exhaustively, but to the point that they can be identified — in a few informal words. And yet even they resort to formal terms where needed. I recommend starting your reading here: http://en.wikipedia.org/wiki/Woodworking_joints
christer said,
March 16, 2010 @ 3:55 am
I see you’re missing the point.
In carpentry, there is no group of “carpentry masters” who holds classes telling carpenters to use the ‘new’ “glue pattern” while poo-pooing the old way of gluing. There is no group who tries to tell other carpenters what to do or what to call it. Carpentry nomenclature occurs naturally, on the job, not from some club of theory-only carpenters selling expensive coursework and books.
Indeed, it appears all other disciplines are quite sane, and it is only in software development where we have enough feeble-minded people that we have been taken in by a bunch of snake-oil salesmen selling made-up, out-of-the-blue, nonsense terminology like, say, “flyweight pattern.”
=== awood ===
awood said,
March 29, 2010 @ 9:01 pm
This has got to be a cool place for a discussion that started 2-3 years ago to still be alive!
I’ve wondered about this thread based on my own experience and I can’t help but agree with Christer.
My first instinct was to wonder how labeling algorithms or data structures is any different than labeling patterns, but algorithms and data structures are much, much more concrete and applying them has very measurable results.
And while this may seem harsh and overly judgmental, in my experience, the best programmers/engineers are the ones that think in terms of data and algorithms. Those are also often the best architects, because they truly understsand what encapsulation means or they otherwise would not be able to seperate data and algorithms (and I don’t consider encapsulation to be an OOP-only concept, I say this because Christer is obviously not an OOP fan!).
By contrast, programmers that litter the code with pattern usage are usually the ones that cause the most trouble. They absolutely have to label whatever code they create with the pattern they picked from the book. Those are the programmers that love to explain how an Adapter is different than a Facade or a Decorator, etc, and who include the pattern names in whatever new classes they’ve created instead of just trying to name a class with something that captures its purpose. They also think that labeling something with a pattern makes it clean, and that it’s okay for WhateverAIObjectFactory to be known by the entire codebase because it’s recognized pattern. They go through great effort to systematically incorporate pattern names in their language and are completely unaware of the “real” problems other engineers are solving daily to make the game fast and ready for ship. To me, those guys are trouble.
Patterns exist, and whether they need to be labeled or not can be debated. All I can say is, when I see very explicit pattern usage, my alarms trigger and I pay special attention! And that’s a reflex that has been burnt in me over time.
=== links ===
Design patterns
oop
Category:Oop