31–40 of 49 posts
No, GOF didn't introduce the "strategy" pattern. What they did was catalogue and describe the "patterns". Perhaps GOF invented the name "strategy", don't know about that.
There’s a certain class of programmer who seems to derive great pleasure in comparing programming to architecture. Maybe because architects are cool, or sound more grand than “programmer”. The author mentions Patterns of Software as profound, but in my experience it was mostly empty and contained only references to other work, without adding its own voice or perspective. At worst, it was pretentious and boring.
There’s a certain class of programmer who seems to derive great pleasure in comparing programming to architecture. Maybe because architects are cool, or sound more grand than “programmer”. The author mentions Patterns of Software as profound, but in my experience it was mostly empty and contained only references to other work, without adding its own voice or perspective. At worst, it was pretentious and boring.
As a counterweight, the first few chapters of Patterns of Software (not the GoF book but Richard Gabriel's https://dreamsongs.com/Files/PatternsOfSoftware.pdf ) constitute the #3 most profound piece of writing on software I've ever read.
Earlier quoted context omitted.
And you’ve misread the whole concept of my post. There’s nothing wrong with finding parallels with different disciplines. I don’t recall saying that at all. My gripe is that different discipline always seems to be architecture and the design patterns topic has been talked to death for over 50 years now.
"A Pattern Language" was published in 1977. It has only been in existence for slightly less than 50 years. When it was published it was simultaneously a revolutionary and also completely niche book. It did not build on any kind of existing sub-discipline of architecture, and most architects ignored it entirely (an awful lot of them still do). It took several decades for anyone to notice that there might perhaps be so…
Earlier quoted context omitted.
As a counterweight, the first few chapters of Patterns of Software (not the GoF book but Richard Gabriel's https://dreamsongs.com/Files/PatternsOfSoftware.pdf ) constitute the #3 most profound piece of writing on software I've ever read.
What are the other top ones?
#2: Christopher Alexander, "Notes on the Synthesis of Form" which is also mentioned in OP, and which I read based on the mentions in Patterns of Software. So that's another thing to thank #3 for.
Earlier quoted context omitted.
And you’ve misread the whole concept of my post. There’s nothing wrong with finding parallels with different disciplines. I don’t recall saying that at all. My gripe is that different discipline always seems to be architecture and the design patterns topic has been talked to death for over 50 years now.
Such a strange gripe to have. Architecture as a default comparison makes sense on many levels. You don't make blueprints for pottery. The level of 'coincidental' design is much lower in architecture than it is in painting. There are much more specified 'primitives' that you can use in architecture that directly reflect the capabilities of the construction, etc. And even before programming architecture was used metaph…
The verbing of "architect" is relatively recent, and certainly comes after programming. Historically, and outside the USA, one generally designs a plan, you do not architect it.
Architects design buildings, they do not architect them. Some kinds of software involve designing an architecture.
There’s a certain class of programmer who seems to derive great pleasure in comparing programming to architecture. Maybe because architects are cool, or sound more grand than “programmer”. The author mentions Patterns of Software as profound, but in my experience it was mostly empty and contained only references to other work, without adding its own voice or perspective. At worst, it was pretentious and boring.
As a counterweight, the first few chapters of Patterns of Software (not the GoF book but Richard Gabriel's https://dreamsongs.com/Files/PatternsOfSoftware.pdf ) constitute the #3 most profound piece of writing on software I've ever read.
Why though actually can't we build the way our ancestors did? Is that knowledge all lost? The Palace of Westminster isn't a farmhouse but it seems like a pretty beautiful, functional, durable building.
Why though actually can't we build the way our ancestors did? Is that knowledge all lost? The Palace of Westminster isn't a farmhouse but it seems like a pretty beautiful, functional, durable building.
Because we stopped making buildings to create shelter, or livable places. The process became industrialized, and serves the same goal as most processes in a capitalist society: to generate most profit at minimum cost.
Earlier quoted context omitted.
This is really misreading the whole concept of patterns in both architecture and software. The goal is not to somehow equate or even link the two disciplines. Instead it is to note that when you go about arranging stuff to do stuff (e.g materials to be buildings, or programming languages to be programs), it is likely that there will (over time) emerge ways of doing things (patterns) that you can (and likely should) u…
So I would rephrase the parent poster you replied to even though he replied himself. There are many programmers that put cart before the horse - they think they should use those patterns even before they start to emerge in their systems and treat those patterns as some kind of a goal. Whereas one should notice when pattern is applicable because it starts emerging as such - and GoF wrote down descriptions for people t…
Isn't that the whole purpose of design AND of patterns? You design your software first, and instead of reinventing solutions that already exist, you base them on patterns. It doesn't have to be a BUFD, but you should still map out your requirements before hand, and when thinking of your implementation, if it's a solved problem why not use the patterns that are accepted and available. That improves build-time and maintainability because you're using familiar patterns.
There's a time and a place for going full hacker and just start coding immediately and letting the pieces come together as they will, but lets not glorify it and certainly not call it the "right way" or imply that design before building is "putting the cart before the horse". Design should come before construction.