13 ms·

>20 years ago, the “Gang of Four” published the seminal work on design patterns How quickly we forget our history. It was the seminal work on design patterns

>20 years ago, the “Gang of Four” published the seminal work on design patterns How quickly we forget our history. It was the seminal work on design patterns in software. But by 1996 Christopher Alexander, Sara Ishikawa, and Murray Silverstein had been writing about design patterns in architecture for at least 28 years ('A Pattern Language Which Generates Multi-Service Centers', 1968). And only 2 days ago this was on HN https://news.ycombinator.com/item?id=11334395 https://news.ycombinator.com/item?id=11334395

dang 11y ago
It's true that Alexander's design patterns inspired the software patterns that culminated in GoF, but the two have so little in common that it's misleading to think of them as related. The speech that you linked to, which he gave at OOPSLA in 1996 at the height of his influence on software people, is a very long, very polite disclaimer of any relation between the two. It's basically an extended version of McLuhan's "you know nothing of my work" line from Annie Hall. If we were really trying to apply Alexander to software practice, we would be asking things like which designs create more wholeness or a greater image of beauty in the soul. We don't begin to have such a vocabulary in software; it's hard to even ask what it might mean without laughing. Certainly it has nothing to do with the Visitor pattern for traversing trees or whatnot. Software design patterns are more comparable to the 19th century compendia of gear mechanisms that crop up on HN from time to time, though more poorly specified. The problem with software patterns (and why the 'movement' failed, IMO) is that either they're incoherent—in which case you can never be sure people are talking about the same things, which does not lead to clarity in design—or they're precise enough to implement programmatically, in which case humans shouldn't need to type them out in the first place.
- memracom 11y ago
  I don't think that you have much experience with software if you really believe that developers and especially people who architect and engineer software do not ask such questions. We do, and the discussions do make it out into the wild from time to time. In particular we discuss these things in software involved with software interfaces, but even the discussions over the suitability of the relational database or the movement towards more functional programming languages touch on these themes. Just like in building architecture, it is a struggle to think differently, to see new possibilities and new ways of doing things. As the world changes, our context changes, and from time to time the change accumulates enough strength to become a new thing. We need to watch for those events because when the context changes, so should our patterns of design. Read up on Engels 2nd law of dialectics The law of the passage of quantitative changes into qualitative changes and Aristotle's Paradox of the Heap. Using patterns is not so terribly important. What is important is SEEING patterns, UNDERSTANDING patterns and CREATING new patterns.
  - tptacek 11y ago
    The simplest response would be to point out that Alexander's Pattern Language was intended to (and did) have the effect of allowing ordinary people to design living and working spaces, in such a way that architects and builders could convert their designs directly into building plans. But no ordinary person can design software with a couple Abstract Factories, a Bridge, and a Strategy. That there are so few design patterns in the original GoF book is a tip-off (there are so many in Alexander's book that the best way to read it is to open to a random page and read either direction). The most devastating critique of the GoF pattern movement came from Norvig: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/ The GoF pattern language doesn't relate software's design back to its users. It relates Smalltalk to C++ programmers.
    - mcphage 11y ago
      > Alexander's Pattern Language was intended to (and did) have the effect of allowing ordinary people to design living and working spaces, in such a way that architects and builders could convert their designs directly into building plans Although he found the same problem as software design patterns suffer from—people assuming the pattern language is a buffet, and adopting whichever they felt like. Attempting to correct for that later led to his The Nature of Order series, which hasn't had any significant effect on the programming community.

dang 11y ago

It's true that Alexander's design patterns inspired the software patterns that culminated in GoF, but the two have so little in common that it's misleading to think of them as related. The speech that you linked to, which he gave at OOPSLA in 1996 at the height of his influence on software people, is a very long, very polite disclaimer of any relation between the two. It's basically an extended version of McLuhan's "you know nothing of my work" line from Annie Hall. If we were really trying to apply Alexander to software practice, we would be asking things like which designs create more wholeness or a greater image of beauty in the soul. We don't begin to have such a vocabulary in software; it's hard to even ask what it might mean without laughing. Certainly it has nothing to do with the Visitor pattern for traversing trees or whatnot. Software design patterns are more comparable to the 19th century compendia of gear mechanisms that crop up on HN from time to time, though more poorly specified. The problem with software patterns (and why the 'movement' failed, IMO) is that either they're incoherent—in which case you can never be sure people are talking about the same things, which does not lead to clarity in design—or they're precise enough to implement programmatically, in which case humans shouldn't need to type them out in the first place.

memracom 11y ago
I don't think that you have much experience with software if you really believe that developers and especially people who architect and engineer software do not ask such questions. We do, and the discussions do make it out into the wild from time to time. In particular we discuss these things in software involved with software interfaces, but even the discussions over the suitability of the relational database or the movement towards more functional programming languages touch on these themes. Just like in building architecture, it is a struggle to think differently, to see new possibilities and new ways of doing things. As the world changes, our context changes, and from time to time the change accumulates enough strength to become a new thing. We need to watch for those events because when the context changes, so should our patterns of design. Read up on Engels 2nd law of dialectics The law of the passage of quantitative changes into qualitative changes and Aristotle's Paradox of the Heap. Using patterns is not so terribly important. What is important is SEEING patterns, UNDERSTANDING patterns and CREATING new patterns.
- tptacek 11y ago
  The simplest response would be to point out that Alexander's Pattern Language was intended to (and did) have the effect of allowing ordinary people to design living and working spaces, in such a way that architects and builders could convert their designs directly into building plans. But no ordinary person can design software with a couple Abstract Factories, a Bridge, and a Strategy. That there are so few design patterns in the original GoF book is a tip-off (there are so many in Alexander's book that the best way to read it is to open to a random page and read either direction). The most devastating critique of the GoF pattern movement came from Norvig: http://norvig.com/design-patterns/ http://norvig.com/design-patterns/ The GoF pattern language doesn't relate software's design back to its users. It relates Smalltalk to C++ programmers.
  - mcphage 11y ago
    > Alexander's Pattern Language was intended to (and did) have the effect of allowing ordinary people to design living and working spaces, in such a way that architects and builders could convert their designs directly into building plans Although he found the same problem as software design patterns suffer from—people assuming the pattern language is a buffet, and adopting whichever they felt like. Attempting to correct for that later led to his The Nature of Order series, which hasn't had any significant effect on the programming community.