Unresolved Forces - Copyright Richard Fabian 2024

Loss of meaning

The most subtle yet deleterious failure was the deviation of meaning to that of an idiom. Patterns are very different from idioms. They would not have been as fascinating to Christopher Alexander had they carried the same value. However, given how so many design pattern authors have presented idioms as patterns, the distinction between the forms may not be sufficiently clear. To help, I shall go the extra mile and let the cat out of the bag by explaining what an idiom is, why it’s different from a pattern, and what unique values it brings.

Idioms are natural expressions of an intent by those fully embedded in the medium. For native speakers of a language, it means that words in contexts gain a new meaning. We can differentiate idioms from other word forms by their unique nature. For example, I did neither release any feline from a container nor travel any considerable distance when writing the previous paragraph. Those words, in those configurations, mean something different than their literal meaning.

Idioms are agreed upon, whether consciously or unconsciously, by the group using them. An individual is unlikely to spawn an idiom. They are not a ‘found’ thing. They don’t naturally reoccur, because they are an element of the momentary culture. They are the acceptance of an idea rather than a strongly self-selecting thing that forms from the properties of an environment. Because of this, we can question why an idiom exists and who it’s for. These are clues to the idiom’s value to us both now and in the future.

In programming, idioms are the accepted or preferred way to achieve goals in those languages or paradigms. This latter point is why some classify the GoF patterns as idiomatic. They are examples of solutions to repeating problems but for object-oriented design alone.

Programming idioms can communicate an intent through a set of steps. If you think of steps as verbs and the objects upon which the steps are taken as nouns, it’s easier to see the link. Idioms are domain-specific in the way patterns are specific to contexts with particular properties. But there are many domains for idioms to cling to.

• Idioms of compiled languages
• Idioms of functional languages
• Idioms of C++
• Idioms of programming in your specific team
• Idioms of academic programming
• Idioms of high-performance programming

Each of these domains can overlap with the others. There are potential idioms of programming in your academic team of high-performance C++ programmers using a functional style. There are so many domains where idioms might occur that it is implausible to list even a tiny fraction of them. Think of them instead as modes of thought—fields in which you can assert invariants or immediately know what would be considered valuable through that lens. Another way of thinking about idioms is as a form of etiquette. They can be rules, but they are artificial even when beneficial.

An idiom, like a word, extends the language. It’s easy to recognise and comfortable to work with, as long as you’re part of the group that understands the in-joke. Because of this, we prefer to write idiomatic code. Code is more easily seen as correct and inflicts less cognitive load when its appearance matches our expectations.

So, why are these not patterns? After all, patterns are often referred to as extensions of a language. Pattern languages communicate relatively larger ideas through smaller, more commonly understood ideas. But patterns and idioms, for all they share, have some significant differences.

Patterns aren’t always constrained to one location or level of scale. They will change in appearance at a different location or level but can be the same fundamental composition of interacting forces in a context. The context does not have to be limited to a specific level of detail, language, or medium. For example, the physical building pattern 159 Light on two sides of every room creates places with abundant natural light. People can see things clearly in rooms with little glare. We feel good in places like this because we can observe the small movements on people’s faces and, therefore, feel better connected to them. This same pattern plays out when using lighting rigs in film and TV. When we want to engage an audience with a character, we light them with little or no glare so that the slightest emotional details are perceived. It’s an entirely different level of scale, but the pattern forces and the context match.

Patterns are self-starting. If they didn’t exist already, they would naturally occur under a different name when the same forces arose. In comparison, idioms tend to be cultural elements. Sometimes, an idiom is something that came along at the right time to be accepted as the right way. There’s also the aspect of idioms being a culturally enforced right way, not reinforced by environmental feedback the way patterns are.

A pattern is a word in a language because a word is needed to describe what it does and where it fits in the grammar of the whole space. Idioms are more like the word choice, spelling, or sequence of words used to realise a solution for a specific in-group. If you know C++, you may have encountered the erase-remove idiom. It’s an idiom of deleting elements from a vector¹. However, the algorithm for removing elements from a vector—by shuffling them down and only resizing the vector itself when all removals are complete—is a pattern. The solution to the problem of erasing elements from a vector is a self-starting pattern reoccurring in different languages and paradigms. How it (the pattern of vector element removal) is implemented in C++ with the STL is with a two-word sequence (the idiom of erase-remove).

For another example, we can consider astrology. No, really. Keep reading, please. At the root of astrology is the recognition of shapes in the stars we see in the sky. I’m not particularly interested in which sign is rising or where the moon was when I was born, but I am interested in the concept of constellations. It’s not something unique to any one particular set of people. Constellations are a pattern of human objectification of the stars. However, the specific stars and the formations we named are idiomatic. Each isolated culture had a distinguishable set of relevant clusters of stars. Some overlapped, but many didn’t. Constellations are a pattern of perception, but each zodiac variant is an idiom.

Because an idiom is deemed valid by social contract, they are unlikely to persist as long as patterns. In contrast, a pattern is considered authentic only by judging its intrinsic virtues, such as whether it’s autopoietic². The nature of idioms often leads to their destruction, as the influence of new language users overrides tradition.

Now you can understand why, despite some brilliant people claiming that all the GoF design patterns are idioms, they are wrong. Some pattern are entirely self-starting from requirements in the domain of object-oriented development. If you attempt to find solutions to design problems and limit yourself to objects, you will, in most cases, come to some of the same patterns as those recorded in the GoF book. Like the bow and arrow, they are patterns forming of their own accord, without requiring outside influence to rouse them. When you search for a way to decouple behaviour from the trigger while constraining yourself to using objects or try to recreate function pointers in object-oriented design, the natural solution is to create an object representing a function call, which is the Strategy pattern in a nutshell.

But idioms can also be fantastically useful. Gathering them and presenting them to those new to the language can hugely impact their ability to comprehend and contribute. Without idioms, you must figure out what each set of words means each time you encounter them or invent a new sequence satisfying your meaning. But idioms are local, in time and space and purpose. Having so many idioms in the catalogue of patterns made it very hard for anyone to understand what a pattern should be. This led to the further dilution from idiom to technique.

As the publications on patterns continued, new areas opened up for pattern coverage. As the breadth increased, the understanding of what patterns are became idiomatic. We started seeing design patterns categorised as any recognisable recurring form in a design. In user interface (UI) and user interaction design, the meaning drifted further until we witnessed UX design patterns, which are all idioms in a pronounced way, as they depend on history and UI literacy. If they were patterns, someone new to computers would not have to ask what the three seashells means, I mean, what the three-line hamburger button means.

When you look at recently released design pattern books, they are often just lists of techniques. Some examples I have on my bookshelf include the MapReduce Design Patterns[MapReduce12] book from 2012, React Design Patterns and Best Practices[React17] from 2017, and Machine Learning Design Patterns[MLDP20] from 2020. A few patterns in each book might be patterns, but the books are dominated by techniques and solutions. With that, it’s clear we have liberated the term ‘design pattern’ so it can be used to describe any book as long as it has a collection of handy tools for solving problems in a domain. Well, that’s unfortunate.