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

111–120 of 133 posts

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

#111

Post by mikekchar »

hackits wrote: post #93
mikekchar wrote: post #88

Earlier quoted context omitted.

> 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. Number one on HN at the moment for me is "Async/Await support landed in Firefox Nightly". With Async/Await, instead of explicitly queuing callbacks in the main event loop and then re…

Just some comments to your response. `The opinion you express (that modern programmers need know nothing of patterns) is one of the reasons why programmers don't understand the tradeoffs between Reactor, Async/Await, and Continuations. It is one of the reasons I have to pull out my hair dealing with domain object models that mirror relational layout exactly.` I actually rather a domain model that mirrors the relation…

> Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others?

It's hard to say what you mean by this. I have difficulty believing that you think that a technique used in one situation is always going to be the best technique to use.

As someone has already graciously described situations where Flyweight can be used, perhaps something simpler than that like the Singleton can be illustrative.

The OP opined that the Singleton is only useful to people who don't know how to use a global variable. If that were the case, it would not be useful at all. In fact, it's usually something to stay away from. However, it absolutely shines when you want to make sure that an entity's constructor is only called exactly once.

There are many situations where you need to do this -- often when interacting with hardware, this kind of thing is crucial. As the OP suggested, though, it's easy to misuse this pattern.

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

#112

Post by Patient0 »

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…

Your second to last paragraph is brilliant. Forget welding - you should write a novel!

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

#113

Post by lugus35 »

phlakaton wrote: post #28

I like his point about Alexander going after delegation of design decisions, though I don't necessarily think that's the only point he was driving at. From "The Timeless Way of Building" I got that he's also driving at this: 1. Modern (not necessarily just modernist) architects are generally terrible at achieving what Alexander refers to as "living space" because they're solving for the wrong things. 2. Small-scale p…

Design is a kind of Constraints Satisfaction Problem (CSP).

https://en.m.wikipedia.org/wiki/Constraint_satisfaction_prob...

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

#114

Post by 3minus1 »

noobiemcfoob wrote: post #77
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…

I've heard the quote about design patterns making up for the lack of features in a language. I've always been a little confused by it. Can you give me a good example of a language feature that removes the need for a design pattern?

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

#115

Post by thristian »

3minus1 wrote: post #114
noobiemcfoob wrote: post #77

Earlier quoted context omitted.

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…

I've heard the quote about design patterns making up for the lack of features in a language. I've always been a little confused by it. Can you give me a good example of a language feature that removes the need for a design pattern?

In Java, you'll sometimes see people handing around instances of nearly (or entirely) empty classes with a single method, for use as callbacks. In languages with first-class functions, you can just hand around function pointers directly, you don't need to dress them up with classes.

In C, you'll sometimes see people make a struct containing only a collection of function pointers, and different parts of the code will produce instances of the struct with the function pointers populated differently. In languages with built-in polymorphism, this isn't necessary.

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

#116

Post by lucozade »

skrebbel wrote: post #47
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…

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…

> Why do people focus on pages 4, 5, and 6 of a 13-page talk, and forget all about slides 8, 9, 10, 11, 12, and 13

From a sample of one i.e. me it might be that they aren't forgetting slides 8+, it could be they just didn't bother getting that far.

I got as far as the Iterator example where he, effectively, says that there's no such thing as an iterator pattern because perl has a list iterator built in. Having read that, I didn't feel a huge drive to continue reading the rest.

I appreciate that's probably a failing on my part, it is unlikely to have been a huge drain on my life and I might have learnt something. But that was the path I took. I have a funny feeling others may have done the same.

EDIT: I have felt sufficiently guilty that I have read the rest. If I understood correctly, the author doesn't think that GOF design patterns are the same as Christopher Alexander's design patterns. He thinks that Alexander's patterns are important and applicable to software. He doesn't really say why.

It wasn't a huge drain. It wasn't particularly informative. The Iterator pattern is definitely a thing. Don't feel a pressing need to read Alexander's book again.

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

#117

Post by lmm »

3minus1 wrote: post #114
noobiemcfoob wrote: post #77

Earlier quoted context omitted.

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…

I've heard the quote about design patterns making up for the lack of features in a language. I've always been a little confused by it. Can you give me a good example of a language feature that removes the need for a design pattern?

A language-level match feature replaces many use cases of the visitor pattern.

Typeclasses often remove the need for facades.

First-class constructors (e.g. static virtual methods) remove the need for factories.

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

#118

Post by andreareina »

lucozade wrote: post #116
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…

> Why do people focus on pages 4, 5, and 6 of a 13-page talk, and forget all about slides 8, 9, 10, 11, 12, and 13 From a sample of one i.e. me it might be that they aren't forgetting slides 8+, it could be they just didn't bother getting that far. I got as far as the Iterator example where he, effectively, says that there's no such thing as an iterator pattern because perl has a list iterator built in. Having read t…

The takeaway I got was that in software as in building architecture, the design should result from a conversation between the architect and the users. Christopher Alexander's book presented a shared vocabulary that allows the eventual users to specify at a high level what they want ("entryway transition", "varying ceiling heights", etc) for the architect to synthesize into a coherent whole.

Christopher Alexander patterns are about the conversation between the maker and the user; GoF patterns are about the conversation between the maker and their tools.

If we drop out of the conversation about design patterns altogether and look at that kernel of the argument, I think there's a very valuable point there: makers need a way to effectively communicate with their users at the correct level of abstraction. This generally necessitates a design language that is useful to both parties.

Users don't care if their data is being stored in a relational database, or document store, or flat files; they just care that it's persisted. Linus Torvalds didn't build git because he wanted a content-addressable tree of objects, he wanted fast, distributed source code management with protection against data corruption.

Talking to our users is one of the hard problems in software architecture.

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

#119

Post by rurban »

LordDragonfang wrote: post #36

I'm a bit young for perl, but I've had rather extensive experience with python at my last job, and it's my understanding that perl has a similar "global" solution with for elem in collection: and the `__iter__()` function. Correct?

no. perl5 can deal natively only with finite lists, not general iterators over infinite (lazy) lists. of course you can design an iterator over lazy lists, but you got no language support as with __iter__, other than using tie callbacks.

only perl6 supports lazy lists and coroutines and yield.

but iteration is only a trivial part of a design pattern. as the name says, a pattern is matching certain conditions, like number of arguments, types of arguments, context, ... and applies a specific solution to this pattern. perl5 and perl6 are not functional enough to provide this kind of pattern matching and functional dispatch. python and ruby neither. perl6 has multi-methods, but no proper matcher.

Norvig explains a bit in http://norvig.com/design-patterns/design-patterns.pdf, but in essence any strongly typed FP deals with that.

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

#120

Post by danblick »

In the last year I've learned a little bit about expert performance from the book "Peak" and also the Coursera course "Learning how to learn".

Experts learn to think and act more efficiently by forming "chunks" - associations between different concepts that are recalled together and can be handled as a larger unit (which reduces the amount a person needs to keep in working memory).

I think this really has a lot in common with "design patterns", which are basically "chunks" of design expertise that have been written down and can be recalled by name and shared between people.

(Also, if you haven't looked through "The timeless way of building", do it! It's a beautiful book about architecture and the role of individuals as a part of society and how our environment shapes our lives. When I open it I feel transported to 1970s Berkeley.)

Post reply on HN