Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Design Patterns” Aren't (2002)

perl.plover.com

Post reply on HN
Print view View original

71–80 of 133 posts

Re: “Design Patterns” Aren't (2002)

#71

Post by deanCommie »

Arwill wrote: post #68
shubb wrote: post #13

I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later. For instance, MVC is a very popular design pattern. When you read code built according this pattern, even if you are not familiar with the language or framework, you know what kind of thing to expect to find in different parts of the program. They can also be useful in a context where not eve…

>I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later. I've seen a big project with heavy emphasis on patterns, and it was a hell for new programmers. Take a month debugging 50 levels of method calls trough the facades and the framework, just to find code that does the business logic.

Every tool it can be misused. Doesn't mean it doesn't have value.

Re: “Design Patterns” Aren't (2002)

#72

Post by mattmanser »

jfoutz wrote: post #58
skrebbel wrote: post #55

Earlier quoted context omitted.

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 d…

The problem is you buried your point in the 5th sentence in the 5th paragraph of basically a rant.

And it's wrong. No modern programmer does that any more.

When I first came here 9 years ago people would refer to patterns all the time. But this is the first time I've seen the GoF even mentioned in a year or so. People stopped caring about design patterns years ago because they stopped being relevant.

And good riddance, the whole thing was a farce that spawned factoryFactoryFactories and newbies constantly asking how to implement a singleton because actually they wanted glorified global variables because they can't program properly.

Where the GoF completely failed, javascript, ironically, saved us (with Crockford doing the nudging). It forced functional paradigms, lambda expressions, anonymous types, function objects, etc. into the mainstream languages where lisp had failed and almost overnight made design patterns obsolete. It fundamentally changed how we programmed so that the problems the patterns aimed to solve weren't problems any more.

Re: “Design Patterns” Aren't (2002)

#73

Post by empthought »

mattmanser wrote: post #72
jfoutz wrote: post #58

Earlier quoted context omitted.

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 d…

The problem is you buried your point in the 5th sentence in the 5th paragraph of basically a rant. And it's wrong. No modern programmer does that any more. When I first came here 9 years ago people would refer to patterns all the time. But this is the first time I've seen the GoF even mentioned in a year or so. People stopped caring about design patterns years ago because they stopped being relevant. And good riddanc…

Design patterns aren't obsoleted by JavaScript; they've just been given trendy new names like reducers and sagas.

Re: “Design Patterns” Aren't (2002)

#74

Post by bunderbunder »

jfoutz wrote: post #43

I 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…

You're absolutely right.

But I also think the author's getting at something slightly different - it sort of goes back to that popular barb that design patterns are just a way to make up for a language's shortcomings.

At the time this was written, doing something like foreach in most languages was a horrible PITA. And if you had a language like foreach, and you were watching people use the iterator pattern (which, I realize, is more powerful, but mostly it would get used for stuff that foreach could handle), you'd definitely shake your head sadly to see all the sweating it would take to express simple concepts, and you'd think, "Geez, why are most programming languages so awful?"

A lot of languages stayed awful for a long time. Java only recently got better, I think partially in response to pressure from .NET. Nowadays, though, even C++ is a wildly different beast, so the point the article was trying to make has lost a lot of its poignance.

Re: “Design Patterns” Aren't (2002)

#75

Post by wballard »

digsmahler wrote: post #67
jfoutz wrote: post #43

I 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…

I'm a 40-something programmer learning to weld. It's really fun! You can do it too.

Same here. Totally agree. Check out the new weldment and pipe features in OnShape, just noticed this last night.

Re: “Design Patterns” Aren't (2002)

#76

Post by elihu »

> The problem Alexander is trying to solve 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 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

I'm not sure I completely agree with this. I agree Alexander was trying to establish a vocabulary for communicating common ideas, and I agree that his collection of patterns wasn't meant to be the one true canonical list of architecture patterns, but I do think a lot of his patterns do specifically tell you how to design things. Also much of what he wrote isn't specific to large construction projects with many stakeholders ("The Oregon Experiment", which I haven't read, is an account of the process of designing the University of Oregon campus. However, "A Pattern Language" would also be of use to a person designing their own house by themself.)

What makes A Pattern Language more interesting and intellectually honest than just a list of design rules is that he gives justifications for each pattern and tells you what problem they solve and why he believes them to be an optimal solution. Anyone else can come along and propose a better pattern that solves that problem (or a more general one) in a better way, or can provide some argument that the problem isn't really a problem in certain circumstances. There's no appeal to authority or tradition; patterns are judged solely on their merits (to the extent that we can understand what those are; architecture is strongly tied to psychology, which isn't entirely understood).

(I really wish that someone would write a book similar to A Pattern Language, but about music theory.)

Re: “Design Patterns” Aren't (2002)

#77

Post by noobiemcfoob »

lfowles wrote: post #9

My 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…

I'd completely agree that, at their core, design patterns are simply words or phrases that can loosely define what a program can do without getting as specific as even pseudocode.

I believe there is some element to aspiring to use them though. Once something becomes common enough to be called a design pattern that 2+ independent developers might recognize, that's the signal of a common problem that might have better solutions than the first couple you come up with in planning.

If a design pattern becomes really common, perhaps enough developers get together and add a feature to a language (or make a new one) to encompass what was once a common bit of spaghetti code.

Re: “Design Patterns” Aren't (2002)

#78

Post by chiefalchemist »

st3v3r wrote: post #70
skrebbel wrote: post #47

Earlier 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…

I mean, lots of people can't read for crap, but at some point, some of the failure to communicate has to fall on the one doing the talking.

Actually. It's always the sender's responsibility, not the receiver. Or, as it's been said: It's not what you say, it's what they hear.

Re: “Design Patterns” Aren't (2002)

#79

Post by YZF »

It's been a while since I read the GoF but my recollection is that it was fairly language agnostic and also quite focussed on problems that arise when building the UI monoliths of the time. While it was an attempt to capture something fundamental it ended up, in many cases, capturing something that is more reflective of the period, including things that have to do with languages of the period, the types of applications, and the prevalence of OO. In contrast, Pattern Language, which I've also read a long time ago, naturally benefits from a broader perspective because while humans have been building software at scale for something like 30 years, we've been building buildings at scale for thousands of years.

I feel like GoF was pretty useful in a moment in time where a lot of people were facing similar problems and could benefit from canned solutions to those problems. For the most part are not the problems that I'm trying to solve today aren't really related to those monolith UI application and the tools that I use have some patterns already built into them that I tend to follow. So seems it's something that's useful to study, in the right context, learn something from, but not necessarily copy/paste patterns from.

Re: “Design Patterns” Aren't (2002)

#80

Post by Jtsummers »

empthought wrote: post #73
mattmanser wrote: post #72

Earlier quoted context omitted.

The problem is you buried your point in the 5th sentence in the 5th paragraph of basically a rant. And it's wrong. No modern programmer does that any more. When I first came here 9 years ago people would refer to patterns all the time. But this is the first time I've seen the GoF even mentioned in a year or so. People stopped caring about design patterns years ago because they stopped being relevant. And good riddanc…

Design patterns aren't obsoleted by JavaScript; they've just been given trendy new names like reducers and sagas.

Precisely. Each language and domain of programming gets its own set of patterns. Some patterns are obsoleted (by virtue of being unneeded, or baked into the language), some new ones are created. Some are amalgams of old ones.

This is the way of the world, design patterns are intended to offer a language, and languages evolve. The uniqueness of design patterns to certain domains/languages can be seen as equivalent to the jargon between different technical fields. It doesn't mean that one set of jargon is obsoleted, it just means it's inappropriate. The failure, if any, in our world (programming) is to recognize and emphasize that different levels of programming, different languages, different operating systems, require different jargon and patterns and approaches.

Post reply on HN