Unresolved Forces - Copyright Richard Fabian 2024

Unchanging

Christopher Alexander demanded we raise the practical questions about our projects—the questions asked by those who must live with the results. Things change, and people’s lives change, too. Our relationship with space changes over time, as do the materials we use for construction and the choice of location we wish to develop. This was the reason the traditional methods of building and architecture began to fail and what prompted Christopher Alexander to write Notes on the Synthesis of Form[Notes64]. Modern techniques fail even though they adapt to change, but change has already dealt a blow to the traditional approach.

Any patterns we adopt must be part of a process by which those patterns can be reviewed and improved in later years. This is why we should challenge the GoF book[GoF94] in light of our findings about complexity and simplicity. The book requires an update because better solutions to the problems it addresses exist, and those solutions don’t fit into the book’s structure. The update should include warnings about the issues that were found when some patterns were introduced. New solutions replacing old ones must be presented clearly, not overshadowed by a popular but ageing reference.

The need for such a process of review and refinement is why I am not happy about suggesting replacements for the GoF patterns in this work. I want to introduce the idea of replacing Interpreter with the twin patterns of Specification and Monad and move away from the older description to make the value more apparent. But the future holds different problems and I do not have unlimited foresight. In some places, we need safe code over flexible code, in which the pattern No Unsafe Paths plays a part. We need faster code in others, in which a suite of data-oriented design patterns¹ would play a role in resolving forces of wastefully slow software. Replacing the GoF book would mean including too much or not enough.

The patterns of development will change as the languages we use change. Many books showing us how to develop with these languages have already been published. Some programming languages aren’t even upfront with you about the fact that they are languages but they have patterns all the same. For example, who would say developing a Node.js application is the same as writing vanilla JavaScript for a single webpage? And because there are different dialects of these languages, specific patterns have emerged. There are patterns of working within any common language or framework. Popular game engines have their own patterns alongside the idioms. Hardware constraints also lead to patterns. Embedded, high-frequency trading, and mobile development are fertile ground for the emergence of new patterns.

And that is the point. Patterns emerge. They may be eternal forms, but they can also be forms of a transient environment. New patterns may be as discoverable as the processes for multiplication or making rope. Remember, even these patterns were discovered with rational thought and organic matter.