5 ms·

"Design patterns are bug reports against your programming language." – Peter Norvig http://norvig.com/design-patterns/design-patterns.pdf http://norvig.com/de

"Design patterns are bug reports against your programming language." – Peter Norvig http://norvig.com/design-patterns/design-patterns.pdf http://norvig.com/design-patterns/design-patterns.pdf

sidlls 9y ago
There is a programming language which captures all patterns in its spec? Fascinating. Alternatively, even if one agreed with the quote, it isn't very useful: it is simply another way to state that no programming language does everything.
- marvy 9y ago
  > There is a programming language which captures all patterns in its spec? No, but see https://blog.plover.com/prog/design-patterns.html https://blog.plover.com/prog/design-patterns.html and the follow-up https://blog.plover.com/prog/johnson.html https://blog.plover.com/prog/johnson.html They're both a bit long, so here's what I think is the key quote (from the follow-up): [W]hen pattern P applies to language L, then, to the extent that some programmer on some project finds themselves needing to use P in their project, the use of P indicates a deficiency in language L for that project. The absence of a convenient and simple way to do P in language L is not always a problem. You might do a project in language L that does not require the use of pattern P. Then the problem does not manifest, and, whatever L's deficiencies might be for other projects, it is not deficient in that way for your project. This should not be difficult for anyone to understand. Perl might be a very nice language for writing a program to compile a bioinformatic data file into a more reasonable form; it might be a terrible language for writing a real-time missile guidance system. Its deficiencies operate in the missile guidance project in a way that they may not in the data munging project. But to the extent that some deficiency does come up in your project, it is a problem, because you are implementing the same design over and over, the same arrangement of objects and classes, to accomplish the same purpose. If the language provided more support for solving this recurring design problem, you wouldn't need to use a "pattern". Consider again the example of the "subroutine" pattern in assembly language: don't you have anything better to do than redesign and re-implement the process of saving the register values in a stack frame, over and over? Well, yes, you do. And that is why you use a language that has that built in. Consider again the example of the "object-oriented class" pattern in C: don't you have anything better to do than redesign and re-implement object-oriented method dispatch with inheritance, over and over? Yes, you do. And that is why you use a language that has that built in, if that is what you need. By Gamma, Helm, Johnson, and Vlissides' own definition, the problems solved by patterns are recurring problems, and programmers must address them recurringly. If these problems recurred in every language, we might conclude that they were endemic to programming itself. We might not, but it's hard to say, since if there are any such problems, they have not yet been brought to my attention. Every pattern discovered so far seems to be specific to only a small subset of the world's languages. So it seems a small step to conclude that these recurring, language-specific problems are actually problems with the languages themselves. No problem is a problem in every language, but rather each problem is a red arrow, pointing at a design flaw in the language in which it appears.
- tikhonj 9y ago
  No, the idea is that your language should be able to express patterns in the language. Then they're not patterns any more—they're libraries! Working with an explicit abstraction from a library is far more pleasant than working with an implicit abstraction from a book. The way to achieve this is emphatically not adding patterns to the language spec. Instead, you want small and simple languages that can grow—languages flexible enough to add new abstractions that let you write code the way you want. "Growing a Language"[1] by Guy Steele expounds on this and, as a bonus, is the single best technical talk I've ever watched. Highly recommend watching it[1] or, if you're pressed for time, reading the transcript[2]. [1]: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 [2]: https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
martin1975 9y ago
I guess programming languages then are a bug report against your context free grammar? I think it's safe to say thinking of any particular language as a silver bullet amounts to hubris.
hota_mazi 9y ago
Norving has no idea what he's talking about. A design pattern is a practice that emerges as more and more people start using your language. Basically, there are two kinds of languages: languages that have design patterns and languages that nobody uses.
- lemming 9y ago
  Norving [sic] has no idea what he's talking about. There's a sentence I literally never thought I'd hear anyone ever say.
- hellofunk 9y ago
  I think most Clojure devs would definitely agree with Norvig on this one (and on most things -- Norvig does actually know what he is talking about.) Design patterns are indeed common and necessary in some languages that are not as flexible. But few languages are as flexible as a lisp, with all the pros and cons that brings. Focusing on re-usable patterns to force on very different problem domains is counterproductive in a language that gives you much better (and more creative) ways of solving problems.
flavio81 9y ago
+1 on Peter Norvig's remark on design patterns.

"Design patterns are bug reports against your programming language." – Peter Norvig http://norvig.com/design-patterns/design-patterns.pdf http://norvig.com/design-patterns/design-patterns.pdf

sidlls 9y ago

There is a programming language which captures all patterns in its spec? Fascinating. Alternatively, even if one agreed with the quote, it isn't very useful: it is simply another way to state that no programming language does everything.

marvy 9y ago
> There is a programming language which captures all patterns in its spec? No, but see https://blog.plover.com/prog/design-patterns.html https://blog.plover.com/prog/design-patterns.html and the follow-up https://blog.plover.com/prog/johnson.html https://blog.plover.com/prog/johnson.html They're both a bit long, so here's what I think is the key quote (from the follow-up): [W]hen pattern P applies to language L, then, to the extent that some programmer on some project finds themselves needing to use P in their project, the use of P indicates a deficiency in language L for that project. The absence of a convenient and simple way to do P in language L is not always a problem. You might do a project in language L that does not require the use of pattern P. Then the problem does not manifest, and, whatever L's deficiencies might be for other projects, it is not deficient in that way for your project. This should not be difficult for anyone to understand. Perl might be a very nice language for writing a program to compile a bioinformatic data file into a more reasonable form; it might be a terrible language for writing a real-time missile guidance system. Its deficiencies operate in the missile guidance project in a way that they may not in the data munging project. But to the extent that some deficiency does come up in your project, it is a problem, because you are implementing the same design over and over, the same arrangement of objects and classes, to accomplish the same purpose. If the language provided more support for solving this recurring design problem, you wouldn't need to use a "pattern". Consider again the example of the "subroutine" pattern in assembly language: don't you have anything better to do than redesign and re-implement the process of saving the register values in a stack frame, over and over? Well, yes, you do. And that is why you use a language that has that built in. Consider again the example of the "object-oriented class" pattern in C: don't you have anything better to do than redesign and re-implement object-oriented method dispatch with inheritance, over and over? Yes, you do. And that is why you use a language that has that built in, if that is what you need. By Gamma, Helm, Johnson, and Vlissides' own definition, the problems solved by patterns are recurring problems, and programmers must address them recurringly. If these problems recurred in every language, we might conclude that they were endemic to programming itself. We might not, but it's hard to say, since if there are any such problems, they have not yet been brought to my attention. Every pattern discovered so far seems to be specific to only a small subset of the world's languages. So it seems a small step to conclude that these recurring, language-specific problems are actually problems with the languages themselves. No problem is a problem in every language, but rather each problem is a red arrow, pointing at a design flaw in the language in which it appears.
tikhonj 9y ago
No, the idea is that your language should be able to express patterns in the language. Then they're not patterns any more—they're libraries! Working with an explicit abstraction from a library is far more pleasant than working with an implicit abstraction from a book. The way to achieve this is emphatically not adding patterns to the language spec. Instead, you want small and simple languages that can grow—languages flexible enough to add new abstractions that let you write code the way you want. "Growing a Language"[1] by Guy Steele expounds on this and, as a bonus, is the single best technical talk I've ever watched. Highly recommend watching it[1] or, if you're pressed for time, reading the transcript[2]. [1]: https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 [2]: https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf

martin1975 9y ago

I guess programming languages then are a bug report against your context free grammar? I think it's safe to say thinking of any particular language as a silver bullet amounts to hubris.

hota_mazi 9y ago

Norving has no idea what he's talking about. A design pattern is a practice that emerges as more and more people start using your language. Basically, there are two kinds of languages: languages that have design patterns and languages that nobody uses.

lemming 9y ago
Norving [sic] has no idea what he's talking about. There's a sentence I literally never thought I'd hear anyone ever say.
hellofunk 9y ago
I think most Clojure devs would definitely agree with Norvig on this one (and on most things -- Norvig does actually know what he is talking about.) Design patterns are indeed common and necessary in some languages that are not as flexible. But few languages are as flexible as a lisp, with all the pros and cons that brings. Focusing on re-usable patterns to force on very different problem domains is counterproductive in a language that gives you much better (and more creative) ways of solving problems.

flavio81 9y ago

+1 on Peter Norvig's remark on design patterns.