I am already aware that GoF "Design Patterns" are mostly workarounds for poor language design, but this is awfull

M. J. Dominus—The problem Alexander is trying to solve is:

How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?

This is also a fundamental problem of computer systems development

Richard P. Gabriel on the same: I've been working with the patterns community for a long time. The so-called Gang of Four (Gamma et al) design patterns are notoriously misleading about the ideas behind patterns. A better way to think of what a pattern is in software is to think about the kinds of advice an experience usability or UI person would give to people working on a project in order to make the interface really nice and usable.

Patterns are not about abstraction.

but whar are patterns? Again, if you think patterns are only about abstractions, then you must notice you never comment to yourself that one piece of code is better than another nor that one design is better than another. Patterns are a literary form for expressing those judgments along with the reasons why, and a pattern language is a literary form for showing and teaching people how to build a nicely designed and implemented system.

Ohh, and the notorious Jim Coplien introducing C. Alexander: www.patternlanguage.com

Christoper Alexander—The pattern language that we began creating in the 1970s had other essential features. First, it has a moral component. Second, it has the aim of creating coherence, morphological coherence in the things which are made with it. And third, it is generative: it allows people to create coherence, morally sound objects, and encourages and enables this process because of its emphasis on the coherence of the created whole. [...] So far, as a lay person trying to read some of the works that have been published by you in this field, it looks to me more as though mainly the pattern concept, for you, is an inspiring format that is a good way of exchanging fragmentary, atomic, ideas about programming. Indeed, as I understand it, that part is working very well. But these other two dimensions, (1) the moral capacity to produce a living structure and (2) the generativity of the thing, its capability of producing coherent wholes -- I haven't seen very much evidence of those two things in software pattern theory. Are these your shortcomings? Or is it just because I don't know how to read the literature?