"But the C++ macro system blows goat dick" teehee
“Design Patterns” Aren't (2002)
51–60 of 133 posts
Re: “Design Patterns” Aren't (2002)
#52I remember reading this when it was new. foreach only works on a list. I can bless a list of lists into a rose tree, but i can't traverse that in a uniform way. There's just no hook to say, when the thing isn't a list, get the next element like this. Now days i'd point at haskell's traversable as the gold standard. On large java projects it seems like composite/facade for days. Those splits seemed to let teams work t…
From the postscript of this slide deck: It appears to me that almost everyone who has read this has completely missed the point, even though I said it twice in big letters. People keep sending me mail that says things like this: > I just read through you article "Design Patterns" Aren't. I'm afraid you got it all backwards. At least the iterator example is totally flawed. Or people spend a lot of time arguing about h…
It appears to me that almost everyone who commented on my comment completely missed the point, even though i made it three different ways.
Why do people focus on paragraph 2, when paragraph 5 is where i make the real point? Facing a big coding challenge is hard, and having an abstract language for describing how to structure a solution is valuable to the point of protecting sanity. I have a few theories. One theory is that most of these people are technical experts. They're equipped to consider technical issues, but not much else. When all you have is a hammer, all you can see are the nails.
Re: “Design Patterns” Aren't (2002)
#53My 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…
This.
Design Patters are simply tools at a higher level of abstraction than the code itself.
They are 'approaches to modelling information'.
That's it.
Use them, hack them, or not.
I've found them handy enough, though never implemented anything precisely. They make sense when communicating ideas as well.
I don't see why there is a need for debate.
Re: “Design Patterns” Aren't (2002)
#54I was at that talk. YAPC in St. Louis. (WUSTL?) At the time, I didn't know much about the Gang of Four and I had never heard of Christopher Alexander. Even many many years later, this talk has stuck with my and I spent time looking up Christopher Alexander and reading about some of his ideas. Also, I told everyone I knew about him :D
Re: “Design Patterns” Aren't (2002)
#55Earlier quoted context omitted.
From the postscript of this slide deck: It appears to me that almost everyone who has read this has completely missed the point, even though I said it twice in big letters. People keep sending me mail that says things like this: > I just read through you article "Design Patterns" Aren't. I'm afraid you got it all backwards. At least the iterator example is totally flawed. Or people spend a lot of time arguing about h…
It appears to me that almost everyone who commented on my comment completely missed the point, even though i made it three different ways. Why do people focus on paragraph 2, when paragraph 5 is where i make the real point? Facing a big coding challenge is hard, and having an abstract language for describing how to structure a solution is valuable to the point of protecting sanity. I have a few theories. One theory i…
fyi i don't understand why you're getting downvoted, and touché.
Re: “Design Patterns” Aren't (2002)
#56My 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…
Right, if you do the same handful of things over and over again, you eventually realize that it helps to have a way to talk about those things at a higher level. It's nothing too serious.
Re: “Design Patterns” Aren't (2002)
#57"The Gang-of-Four idea is to discover existing patterns of software development. Then program people to implement them habitually" Citation needed. GoF's intention was to give people a tool for thinking about architecture and sharing their experiences with others. If people are "programmed to implement them habitually", that's some manager's fantasy and neither in the letter or spirit of Design Patterns. It's be like…
> that's some manager's fantasy The issue is that in a lot of shops design patterns have turned into a religion and not just a tool to help thinking. I've seen managers like that. If you didn't implement 15 different design patterns in this or that code base that was "bad design", even if it unnecessarily made the code more complex. I've seen iterators classes written when a simple for loop would have done the trick.…
[deleted]
Re: “Design Patterns” Aren't (2002)
#58Earlier quoted context omitted.
It appears to me that almost everyone who commented on my comment completely missed the point, even though i made it three different ways. Why do people focus on paragraph 2, when paragraph 5 is where i make the real point? Facing a big coding challenge is hard, and having an abstract language for describing how to structure a solution is valuable to the point of protecting sanity. I have a few theories. One theory i…
fyi i don't understand why you're getting downvoted, and touché.
To be fair, it was pretty snarky. It was meant to be silly not hurtful.
In my experience, people pick and choose what they need at the time. I don't think it's unreasonable to say conversations like this happen all the time.
Dev1: Hey, i need to test my control flow, but i need the register allocator.
Dev2: Oh yeah, I put together a facade for register allocation that just does LRU and injects the push/pop pairs to do the right thing. I couldn't get away with a simple interface because there's some weird shared state. The graph coloring allocator is hard, and will take me some time to get ready.
Facade is kind of code for a leaky abstraction. It communicates a lot about how the api really works. Most of the stuff in GoF got picked over and teams took what they needed. Are you doing design patterns? well, kinda. In that sense, i think it did a lot in the Christopher Alexander spirit.
The original author wasn't wrong, just look at FactoryFactoryBuilderFactoryMadness from java's crazy times. But i don't think that's a fair characterization of the entire field of programming.
Re: “Design Patterns” Aren't (2002)
#59"The pattern language does not tell you how to design anything. It helps you decide what should be designed. You get to make up whatever patterns you think will lead to good designs."
Impressive insight.
Re: “Design Patterns” Aren't (2002)
#60The thing very few people seem to get about Design Patterns (in the gang-of-four sense): they are not a Good Thing, desirable and worthy of study in and of themselves. They are a necessary evil to compensate for fundamental deficiencies in C-like programming languages.
The patterns still exist, just many of them are already implemented in the language itself.