“Design Patterns” Aren't (2002)
perl.plover.com
“Design Patterns” Aren't (2002)
1–10 of 133 posts
Re: “Design Patterns” Aren't (2002)
#2The core points of this talk, as noted in the Addendum [0], is that "we need to take a fresh look at Christopher Alexander".
Since that point has been established, it would make a phenomenal follow-up talk to take Alexander's book, which is from the 1970s, and begin a discourse on how his ideas can be applied to modern software engineering and architecture. While the reader takes away from the slides that Alexander has some unique ideas that are probably useful, he/she doesn't come away with a good understanding of what they might be. (though if anyone knows of talks that discuss Pattern Languages, I'd love to see them!)
Re: “Design Patterns” Aren't (2002)
#3title += ' (2002)'
Re: “Design Patterns” Aren't (2002)
#4The bigger problem often is...
We don't often understand what we are building most of the time.
Software is a communication tool most of the time. You are communicating between machine and user or user to machine to network of data and so on.
Most of the code is really a translation from input to some kind of command or process and outputting the result.
The more layers you add to that, the further you are from the truth and the more confusing the world truly is. For all the patterns, abstractions, and so on that we lean on, we miss out on the most important one...
input -> processing -> output
Re: “Design Patterns” Aren't (2002)
#5This guy clearly doesn't understand the iterator pattern!
J/K'ing. But he consciously chose to give the talk a "click bait" title, and the goat thing was a bit of hyperbole. Totally reasonable things to do, but know that you have to live with the backlash from that.
All of that said, I agree with this core point that "we need to take a fresh look at Christopher Alexander". I plan to go out and get a copy of the pattern language book and read it sometime soon, to get a better perspective on "real" Alexanderian patterns. This was a handy reminder to do that.
Re: “Design Patterns” Aren't (2002)
#6The bigger problem often is... We don't often understand what we are building most of the time. Software is a communication tool most of the time. You are communicating between machine and user or user to machine to network of data and so on. Most of the code is really a translation from input to some kind of command or process and outputting the result. The more layers you add to that, the further you are from the t…
We need a way to explore the design space of the design space.
Re: “Design Patterns” Aren't (2002)
#7Also from Norvig, same basic idea, minus the Alexander appreciation:
Re: “Design Patterns” Aren't (2002)
#8This guy clearly doesn't understand the iterator pattern! J/K'ing. But he consciously chose to give the talk a "click bait" title, and the goat thing was a bit of hyperbole. Totally reasonable things to do, but know that you have to live with the backlash from that. All of that said, I agree with this core point that "we need to take a fresh look at Christopher Alexander". I plan to go out and get a copy of the patte…
Ugh! I read the joke without realizing it was a joke.
Re: “Design Patterns” Aren't (2002)
#9My impression was that design patterns are just shared vocabulary, not something to aspire to use (other than realizing there was an existing "word" that would succinctly describe your jumbled spaghetti sentence and using that instead).
Edit: I've been wanting to read A Pattern Language for a while, but this snippet from Amazon made me chuckle. If I didn't know better, I would have given it a 50/50 shot of being from APL or GoF!
>The elements of this language are entities called patterns. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
Re: “Design Patterns” Aren't (2002)
#10MJD says Alexander's central question is "How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?"
The only "solution" to this question in software that I'm aware of is, "hire a charismatic architect and let them do all the design" which is terrible.
Thinking about my team, I'd say probably a third of them are interested in architecture at all, and of that third, at least one has a punishingly minimalist aesthetic that the rest of us loathe. The rest of us are fairly scared of being wrong, scared enough to avoid making bold decisions.
GoF may be insufficient, but it's really the only pattern language we have. I don't even know how to think about this idea properly, which I consider a symptom of the author being onto something.