Resolving the discoverability problem
For the more idiomatic patterns, those of programming language or paradigm, discovery cannot be fixed by organising by problem. None of these patterns are strongly aligned with an overarching theme or domain of conflict. People don’t often encounter them when they have a need—an applicable problem. For these kinds of not-quite-patterns, we need a different solution to make them visible.
A preferred approach would be to automate idiomatic adherence. The Clang Static Analyser and clang-tidy tools, Rust’s clippy, Python’s Pylint, pyflakes, and ESLint for JavaScript are all examples of automated tools to help identify where something doesn’t seem right. They capture errors or at least identify where meaning is ambiguous. Other tools such as style enforcers, Rust’s fmt, Python’s black, and Clang’s clang-format all provide a way to make code readable for all by enforcing a standard way to write code.
An idiom section of the pattern library provides a place to discover why these tools raise a proverbial eyebrow. However, we still need to improve the usability of the library itself.
Externalising a brain
We act when we sense. We sense when we can discern. We discern when we are attuned to the typical parameters of the elements with which we interact. Only then can we experience change and contrast. But if we don’t know or have not experienced, we will not have the presence of mind to think about some aspects during our interactions. We won’t have the ready knowledge to act on input, because without sensing, there is no input.
Our goal cannot be to teach everyone every pattern. This knowledge and wisdom must be kept outside the minds of pattern users but held in such a way that it is accessible just in time. But do we have any examples where this has been possible? Yes! We have many.
A dictionary is the externalisation of a brain filled with answers to the question of what a word means. A thesaurus is the externalisation of knowing the categories of words and the selection of expressions you can regurgitate in pursuit of persuasion. Indeed, even how-to guides are an externalisation of competence. Recipe books and repair manuals alike store information irrelevant outside of specific moments of need. Even an organisational chart is an externalisation of intra-organisational networks, so you know everyone you might work with.
A library
We must reference patterns in one of these different ways. I prefer a Thesaurus-style approach with a section for discovering what categories the pattern might be in and a second section for learning what patterns are in each category.
Categories may be related forces or common contexts. I do not have a solution for the challenge of structuring them, so even this step is tricky. Perhaps you’d hunt for contexts or forces by pattern name and then hunt for pattern names by context or forces. That is the way Roget’s Thesaurus is constructed; different dictionaries built into the same space, as an inversion of each other.
The other benefit of even attempting this would be the possible discovery of truer categories of patterns. These categories could be the starting point for discovering the fundamental properties of software patterns.
If we resolve the discovery issue, it will be worth building a repository of
all patterns. At present, because they are most often searched for by name,
just listing them all makes no sense. For proof of this, the