IMO Alexander's design pattern concept is intelligently superior to the terms trivialization in the atrociously highly rated GoF book. GoF enumerates the tedious patches one needs to use on cumbersome languages like Java or C++ due to the languages primitive nature. The main advantage of GoF that now when you say "Factory pattern" everyone knows sort of concept they are speaking of.
However.
In the scope of Alexander's work GoF patterns are of equal complexity, as if giving names to typical architectural items like "door" or "room".
Alexander's work is on a higher level - discussing how to perceive the complex totality the combination and co-existence of such design features create. GoF book names door a door. Alexander's book discusses how to design houses and communities. Completely different scale.
In software engineering terms I think the closest book that is the best analogue to The Timeless Way of Building in terms of discussing higher level patterns, and how to combine them, is perhaps the classical Structure and Interpretation of Computer programs that since it uses such an elegant language, it can skip the tedium and start with expressing of higher level patterns, and in the end how to combine them into a whole complex system.
You immediately see the difference when you open A Pattern Language and the very first pattern is:
> Wherever possible, work toward the evolution of independent regions in the worId; each with a population between 2 and 10 million; each with its own natural and geographic boundaries; each with its own economy; each one autonomous and self-governing; each with a seat in a world government, without the intervening power of larger states or countries.
No software pattern work has the audacity to start by suggesting that the ordering of the world's governance is relevant to the creation of good software.
> Indeed, since the book was published, a whole academic field has
grown up around the idea of "design methods"-and I have been hailed
as one of the leading exponents of these so-called design methods. I am
very sorry that this has happened, and want to state, publicly, that I
reject the whole idea of design methods as a subject of study, since I
think it is absurd to separate the study of designing from the practice of
design. In fact, people who study design methods without also practicing
design are almost always frustrated designers who have no sap in them,
who have lost, or never had, the urge to shape things. Such a person will
never be able to say anything sensible about "how" to shape things
either.
Poincare once said: "Sociologists discuss sociological methods; physi-
cists discuss physics." I love this statement. Study of method by itself is
always barren.
Most people know "A Pattern Language" because of the design patterns, but it's _this_ book that every software engineer (and everyone in the space of designing solutions) should read.
I agree it's a great place to start; it is much shorter, and contains stronger (or more obvious anyway) links with mathematics, graph theory.
We did a Christopher Alexander reading club some months ago and took some notes as a group using hypothes.is, it worked very nicely and anyone interested is welcome to join in:
That book is fantastic! It's absolutely thrilling design joyride through the most surprising of concepts - and yet it manages to send a very concrete message to designers of all disciplines who are required to build something novel that needs to meet real world requirements.
Minsky, vernacular architecture, graphs, old houses, how to design complex systems...
In the early days of Design Patterns (GoF, et al), he was often quoted.
I purchased a couple of his books: A Pattern Language[0], and The Timeless Way of Building[1]. These books were very readable.
[0] https://en.wikipedia.org/wiki/A_Pattern_Language
[1] https://en.wikipedia.org/wiki/The_Timeless_Way_of_Building