Live data from Hacker News

I'm Sick Of GOF Design Patterns

thecodist.com

31–40 of 46 posts

Re: I'm Sick Of GOF Design Patterns

#31

I've always taken these "design patterns" to be a Shibboleth of the bottom 80-ish percent of programmers. The mediocrities can't handle math. If they dig deep enough into any technical area, they get confused and insecure and pissed-off. Design patterns is the Revenge of the Not-Nerds. It's to use the language of the business to turn the tables and make the actually competent feel queasy and unsure of themselves in t…

What an obscure load of tosh. I might as well say that all the maths-nerds don't really know how to program because they don't understand design patterns properly, as evidenced by them hating on it all the time. But of course, I wouldn't say that because I have absolutely no evidence and it would be based purely on my close-mindedness and preconceptions. (I also wouldn't say it because I have no hatred towards "maths…

I agree with you in general. But learning the design patterns superficially, and applying them where they don't really fit, can in fact make someone a worse programmer. Hopefully they'll grow out of it, so the "damage" is part of the student phase, but some probably do get stuck there and never progress.

Re: I'm Sick Of GOF Design Patterns

#32

I've always taken these "design patterns" to be a Shibboleth of the bottom 80-ish percent of programmers. The mediocrities can't handle math. If they dig deep enough into any technical area, they get confused and insecure and pissed-off. Design patterns is the Revenge of the Not-Nerds. It's to use the language of the business to turn the tables and make the actually competent feel queasy and unsure of themselves in t…

The "enterprise-y" garbage you note has almost nothing to do with the mathematical competence of programmers who implement it.

You write as though programming is an exercise in mathematics. It's not, in general. There are specific problems where mathematics is actually a component of the problem/solution space, e.g. mathematical research, scientific computing, in which programming is the form of the solution to the math problem (analogous to, e.g. "express your answer using set notation", except in this case it's "express your answer in the form of a computer program"). Mathematics may underpin some of programming, and most often in some areas of computer science, but the vast majority of software development has very little to do with math.

Re: I'm Sick Of GOF Design Patterns

#33
post #15

Earlier quoted context omitted.

You are right in such a deep sense that I wish I had more than one upvote to give. This is what people mean when they say a design pattern represents a deficiency in a language: the very fact that it's a design pattern and not, say, a library function is precisely because that language provides no way to abstract it away. Hence, rather than being something that we can turn into a reusable code artifact, the pattern i…

You're thinking wrong. You're thinking like you're going to only use one language ever in your career. You're not (unless you have a very stunted career). Learn what you're doing, independent of language. Then also learn what you're doing within the language.

I strongly disagree that I am "thinking wrong". I think you're saying that design patterns are a useful abstract way of thinking about your problem that you then translate into code using whatever tools are available in the language you're using. I think there are some patterns for which this is true, but the majority don't fall into that category.

Re: I'm Sick Of GOF Design Patterns

#34
I somewhat agrees with the author. But I think GOF Design Patterns is only ONE step in the right direction and it is time to move beyond that.

It is because of the GOF Design Patterns that we started to talk about anti-patterns. In my opinion, learning about the anti-patterns maybe more important than learning about patterns.

Re: I'm Sick Of GOF Design Patterns

#35
In my interview revenge fantasy I imagine turning the tables on the interviewer:

"Before I tell you what I know about design patterns, let me ask you a question. From speaking with you, I can tell that you are articulate and have a good command of the English language, in other words, you're a good communicator.

Now, if I asked you to give me a sentence containing a gerund in a preposition phrase could you? Probably not, even though you probably don't go a day without writing such a sentence. Could I assume that because you aren't familiar with the terms in the above question that you probably aren't a good communicator?"

Re: I'm Sick Of GOF Design Patterns

#36
The adage "those who don't know history are doomed to repeat it" comes to mind when I read this article.

If you simply write off the GoF patterns then you're likely to spend a lot of time creating inferior solutions to common problems. You are less likely to recognize a common problem when you see one. At the same time, people who just see the GoF patterns as some sort of bible will implement things in a ridiculously complicated way because they're trying to use as many patterns as possible.

Basically they're just tools to have in your tool chest. You have to learn how and when to use them.

Re: I'm Sick Of GOF Design Patterns

#37
post #30

Obligatory link: 16 out of 23 patterns were found by Peter Norvig to be simpler or invisible in Lisp or Dylan: http://www.norvig.com/design-patterns/

Thank you. This explains thoroughly what is wrong with design patterns ala GOF. It's not that particular frequent patterns in particular languages or enumerating them in academic fashion is wrong. It becomes wrong when sophistry of these band-aids to language flaws are raised as somehow being really important, when actually they are just reactions to accidental complexity. It often creates unnecessary complexity to d…

I wouldn't say "what is wrong". I mean, the patterns stand on their own merit: they provide a recipes for solving commonly recurring program design problems in Java, C++ and their ilk. "What is wrong" is making a religion out of them: elevating these patterns to an overly important status, as if they are some important generalities in software engineering, if not in fact computer science or even mathematics.

Re: I'm Sick Of GOF Design Patterns

#38

Obligatory link: 16 out of 23 patterns were found by Peter Norvig to be simpler or invisible in Lisp or Dylan: http://www.norvig.com/design-patterns/

I actually found that comparison to be a great example of why design patterns are useful. By naming the pattern, Norvig was able to instantly list 16 ways in which dynamic languages solve real-world problems.

Re: I'm Sick Of GOF Design Patterns

#39
I always viewed design patterns as a communication tool between programmers. Saying

  $('.button .link .pulldown')
     .addClass('active')
     .on('hover', highlight)
     .on('click', doSomething);
is quite a mouthful. But if everyone's familiar with design patterns, then you can just say "Oh, it's a Builder pattern" and everybody knows what you're talking about. Same goes for many, many other situations; familiarity with MVC will go a long way towards understanding angular.js, and familiarity with Chain of Responsibility will teach you about WSGI or Django Middleware, or the State pattern will help you understand trampolines in interpreter implementation.

Re: I'm Sick Of GOF Design Patterns

#40

This person sounds super jaded. Like they didn't get a job because they didn't know about some pattern they were asked about. The thing about the GOF book is that it gives you a great foundation for designing great software. No, they aren't the only patterns out there, but you are going to find at least some of them in any well designed system. You will also see a lot of code that is clearly based on a GOF pattern, b…

What I got from the article is that these patterns are guidelines, not paths carved out of stone that you have to follow. How he presents it is irrelevant to what he's trying to convey.
Post reply on HN