There is a terminal, closed conversation in the Gang-of-4 patterns where as Alexandrian patterns are "ideas"
Paul Graham wrote:
When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.
anti-pattern, a bad thing.
something could either be a pattern or an anti-pattern based on the context. (e.g. Data Transfer Object)
Requires too much ongoing work and maintenance over time
Computer users should write their own programs. Computer users as "inhabitants" of the space.
A way to look at this is that programmers are the "users" here, and the patterns are for the programmers. Another type of "user" is the "end user" and they won't be using these programming patterns. It is these "end users" that more closely resemble the "users" – inhabitants – in Alexander's sense of patterns for cities, towns, neighbourhoods, buildings, etc.
Role of "consumer" versus role of "inhabitant" – things are designed for you and you pick and choose whereas as inhabitant you are a contributor to a community; you can't really contribute to something without knowing the shape of it; inhabitants – people as being in the same space as the object they're interacting with.
What a pattern language for Infusion might be.
Not just patterns of software development code
Do we have an articulation of the quality that we want to have, not necessarily what we currently have; what are the kinds of abilities we want people to be able to do with the software which shapes the qualities that we want to have