PATTERNS OF PATTERNS

In Section 2, we detail three techniques which can help a community carry out self-evaluation and peer learning. Each any of these techniques provides of value independently, but we propose that, used in tandem, they complement each other synergetically, and overcome shortcomings of using one or more of these techniques in isolation. The methods, in outline, are as follows.

The first technique is the Peeragogy Action Review (PAR). It is structured around five questions which members of the community discuss and answer, typically soon after an event such as a meeting or working session. This produces a record of the event as seen through the eyes of the participants and of their evaluation of what transpired.

The second technique is Causal Layered Analysis (CLA). This is a research methodology which is based on examining a subject at the four levels of litany, system, worldview and myth using techniques from poststructuralism. macrohistory, and postcolonial multicultural theory. The goal is to achieve a deep and inclusive undertanding by integrating empiricist, interpretative, critical, and action knowledge.

The third technique is Design Pattern Languages (DPL). Design patterns present solutions to recurring problems in a way that can be combined with other patterns and adapted to different situations. Taken together, design pattens form a common language which a community can use to discuss matters of design and serve as a repository of shared knowledge.

Each of the three methods adds a diffferent element to the mix:

• PAR provides the sensory element of systematically gathered observational data and verification. Thus, our analyses are more likely to be grounded in reality and we remain open to learning new things and being surprised by novelties and anomalies we discover in the data. We can continually check how effective our design patterns are in practice and revise them accordingly.
• CLA adds the cognitive element of organization and depth to the enterprise. Before we incorporated this technique, we were in danger of getting lost and tripping over ourselves in a pile of PAR reports and design patterns. CLA-based meta-review provided the metaphorical bones and discursive joints for assembling these disjecta membra into a coherent body of self-knowledge. By critically re-examining the notions of problem, solution, and context implicit in pattern language, CLA facilitates more effecive use of design patterns and helps avoid muddles such as designing a technological solution to what, upon deeper consideration, turns out to be a fundamentally social issue or vice-versa.
• DPL adds the motor element of action planning, orchestration, and enactment. Having carefully analyzed the situation and determined what to do next and where to act, we need to plot a course of action that takes into account the complexities of the situation and is suited to our particular circumstances.

In Section 3, we focus in on the project planning and management techniques of a trandisciplinary research seminar that studies the Emacs editor. We show how we have used PARs, CLA, and DPL, to develop a sense of direction for our research, and to allow our work to interoperate well with related efforts. This case study provides a detailed practical example that other projects across the pattern language space may wish to emulate (or adapt) in their settings.

In Section 4, we use CLA to survey and analyse design patterns methods more broadly. DPL provide a general-purpose design methodology cite:Corneli2018: however, the high-level evolution of this method in response to criticism, innovation, technical developments, and long-term cultural change has not been previously studied in an integrated manner. Causal Layered Analysis allows us to surface the direction of travel of pattern language methods, by helping us integrate foundational with empirical observation. We identify trends within the pattern discourse towards transdisciplinary thinking and large-scale collaboration; and we connect Alexander’s concept of wholeness with the broader evolution of Western philosophical thought. This, in turn, shapes the way we think about what pattern languages can do.

In Section 5, we look back over the case study and survey, to draw out implications for the future of design patterns. We look at how DPL and CLA have been applied (separately) to the well-established problem of anthropogenic climate change. We suggest that the integrated strategy we propose could lead to more satisfactory outcomes on problems at this scale. We then develop four scenarios for the possible future development of pattern-theoretic methods. In Section, 7 we present a PAR for the paper as a whole: this is offered as an example of a potential ‘best practice’ for pattern authors, on the view that widespread adoption of this method would help improve collaboration within the design patterns community.

Let’s begin by setting to one side any specialist notion of ‘patterns’ that we may have in mind, and think about patterns in a fundamental way. Some patterns repeat in space, some in time, some in both space and time: a tiling, a beat, a wave. In the physical world, it would seem that patterns cannot repeat exactly, or forever. The elements that comprise a pattern are subject to spatial or temporal displacement, and other forms of variation.

Let’s explore the notion of ‘design pattern’ starting from this foundation. Leitner supplied the following summary: "[Design] Patterns are shared as complete methodic descriptions intended for practical use by experts and non-experts" \citep{leitner2015a}. As we look into the matter further, two central features emerge. Like an ellipse, the concept of the design pattern has two main foci: context and community.

• Context shapes and constrains the type of activity which is being considered, such as designing a building, or writing software.
• Community encompasses the stakeholders — experts and non-experts alike — who are involved with or affected by a particular project.

Integral to the basic concept of a design pattern is a third feature that describes the interaction of the community and the context. The community uses the pattern to overcome some real or potential conflict that they experience within this context. The conflict is also referred to as a problem; its resolution is described as a solution.

Alexander and Poyner emphasised that ‘design’ is not needed when the conflict can be resolved in an obvious or straightforward manner. For example, you typically would not need a design process surrounding sitting in a chair, because “under normal conditions each one of the tendencies which arises in this situation can take care of itself” \citep[p.~311]{alexander1970a}.

All of this means that design patterns need to achieve something fairly subtle. Each represents the synthesis of a repeatable solution to a type of conflict which itself repeats within a particular context. Furthermore, it does this a way that makes the solution teachable, learnable, and otherwise replicable within a given community. However, if the design pattern makes the solution to the problem too obvious, then “design”, per se, is no longer needed!¹ Accordingly, we might say that the design pattern carries with it a fragment of irreducible complexity. This perspective may or may not be surprising.

Alexander had described the need for patterns when things get complex cite:alexander1964notes. He specifically focuses on what could be called “horizontal” complexity, a situation where there are a lot of moving parts and relations between them. Methodologically this is elaborated with the notion of a pattern language.² Pattern languages have a property of unfolding, from more general to more specific. However, they seem to leave open deeper forms of “vertical” complexity, where there are deep historical or ontogenetic causes, or complex conceptual issues, which are not readily expressible in design-pattern-theoretic terms. Let’s have another look at these issues by way of two contrasting metaphors.

The first metaphor comes from Christian Kohls, who proposed to treat each design pattern as a journey: “a path as a solution to reach a goal” cite:kohls2010a. In this metaphor, design patterns are understood to have an initial condition and an end condition, defined within some context, which also defines a cost function on traversals of paths. There are two problems: the more elementary problem is to traverse the terrain and travel from the start state to the end state at low cost; the second problem is to find a reliably repeatable way to do this. Once found, the low-cost path can be described to and traversed by others.

The second metaphor comes from Joseph Campbell, who described a kind of “archetypal pattern” cite:shalloway2005a, one that can be found embedded in myths and stories across diverse cultures and historical periods. The “hero’s journey” is also typically described with a path cite:campbell1949a, however, in this case the path runs in a circle, and focuses on the transformations of the hero who traverses it. Although an account of the journey can be shared, traversal is effectively single-use. The cost is typically “high.” Nevertheless, once a myth or metaphor is established by way of a shared narrative, the journey can be reenacted through ritual or engaged with in other ways that solve a range of social problems cite:handelman1998a.

This should suggest that Kohls’s metaphor does not fully express the complexity that is underpins each design pattern. It does, however, hint at this complexity. Design pattern creation calls out for suitable methods, and on this basis we should expect to find patterns for finding, writing, and discussing patterns: and, of course, we do. However, this material does not fully explain where design patterns come from — or where they are going to — not an an obviously graspable way. To really get a handle on the future of the pattern theory cite:alexander1999a, we need another approach.

We begin this section by introducing Inayatullah’s cite:inayatullah1998b,inayatullah2004causal Causal Layered Analysis (CLA) formalism by way of two examples, in Table 1: a short motivating story that should communicate an intuitive feeling for the four layers, and an initial brief recollection of the patterns literature across the surface, social, worldview, and myth. We will develop the analysis in Table 1B in Section 4.

Why might CLA have practical relevance, beyond its current sphere of application by futurists? One reason, which could be familiar to the protagonists of the story in Table 1A: “Innovation foils attempts to be consistent and efficient” cite:tan2020uncertainty (p. 12). The need to understand, respond to, and sometimes to foment change — possibly rapid and thoroughgoing change — underscores the incompleteness of Kohls’s journey metaphor. The CLA framework is a particularly good fit for our central objective, because it is often used in organisations and movements to answer the question: “What is our vision for change and how is progress measurable?” For example, in 1999, Alexander’s vision was that of “the generation of a living world” cite:alexander1999a — however the exact process whereby progress would be made towards that vision had the status of a question.

To help make the CLA practicable as a method, we will now turn to five techniques that Inayatullah refers to as the poststructural futures toolbox. Here, we rework his descriptions of these theoretical tools using the classical design pattern format.

Before turning to our main applications, we will introduce one more technique — although we will not refer to it again until Section 3.

The US Army produced a methodology called the After Action Review or AAR cite:Training-the-Force. AARs can be used to assign responsibility when things ‘go wrong’, and can help people figure out how to do better next time. It has been used effectively in business settings cite:learning-in-the-thick-of-it.

In a more fully collaborative and distributed peer-to-peer setting, we needed an adaptation of the AAR that made it a more open ended. We came up with the following template:

1. Review the intention: what do we expect to learn or make together?
2. Establish what is happening: what and how are we learning?
3. What are some different perspectives on what’s happening?
4. What did we learn or change?
5. What else should we change going forward?

When we fill in the template, we call it “doing a PAR”. As an acronym, “PAR” has stood for various things over the years — Peeragogical Action Review, Project Action Review — but we typically use it as a stand-alone term. Allusively, it brigns to mind the corresponding concept of par in golf, and helps give us a sense of how we are doing at any given point in time.³ Like the Army, we typically use PARs retrospectively (so, asking, “what did we expect to learn or make together?”). In this sense “doing a PAR” shares some common ground with the \textsc{Daily Scrum} and \textsc{Sprint Retrospective} cite:sutherland2019a patterns from Scrum. However, PARs can be used without the product orientation of Scrum.

Indeed, PARs can also be applied to look forward, proactively, as a way to scaffold anticipation by “remembering the future” cite:arnkil2008remembering. In that case, item #5 can be expanded to include a number of different forward-looking scenarios. Some further things to note at this stage:

• PARs are related to patterns, in that they describe a context, and surface problems and solutions that arise or are likely to arise in that context. They might be seen as a template for proto-patterns. However, they do not necessarily have a strong ‘repeating’ aspect.
• Once when we have collected a suitable number of PARs, we can use them as data for analysis with CLA. Metaphorically, CLA ‘integrates’ the ‘tangent vectors’ that characterise the observations we gather as we work together, to reconstruct the shared meaning of this work.

We’ve made progress since we started with the raw themes of Research on/in/with Emacs back in December 2020. We’ve met almost every week since then, and interviewed some interesting and varied guests. We have a clearer idea of what what we want to talk about at the next EmacsConf, and how we can be of service to researchers and Emacs users. We have been using a workflow that helps us carefully review progress, diagnose issues, and manage our energy. The next phase of this project is to “go public” and mesh with ongoing related activities elsewhere, including by getting some training events up and running.

If we tackle big enough projects, it will bring with it the need for collaboration. We like to create tangible deliverables (e.g., journal articles). However, “If we knew what the outcome was it wouldn’t be research” — therefore, we’re focusing initially on research methods and design documents. That may mean it takes us a bit longer to write our first paper, but when we get something out it will be good. Meanwhile we’re also keeping sharp by fixing bugs, filing issues, improving our own workflows, and actively exploring the landscape. We want to keep a role for serendipity here, which adds the requirement that our planning process remain open and flexible: including to various disciplinary methods, and especially to change as we reflect on how things are going.

We have looked at RStudio and Roam Research as models of (some of) the kinds of things we think Emacs can learn from and eventually improve upon. ‘Practice’ and ‘method’ keep coming up in our discussions as, respectively, ‘more bottom up’ and ‘more top down’ ways of actualising things. Concretely, we’ve been studying our own processes and looking for the tools and settings that are the most conducive to the work we want to do. For example, instead of having a single Org Roam directory shared via Git, what if we had ways of managing sharing of notes across ‘graphs’?

Collaboration is familiar to in all kinds of teams across all sectors. Even authors working alone may have need to ‘virtually collaborate with themselves’ — and of course to share their work with others when it’s ready. If we all had our slipboxes online, we could reference between them. This would generalise ORCiD, and people to reference processes that are undergoing evolution. Maybe a service like this would turn into a ‘Tinder for academics’ — helping to match people based on their interests (or similar people in different fields). So, what’s the price point? Instead of paying money to go to conferences, now we can spontaneously make conferences and workshops. As a guess, $750.0 per user per year might be a fair price — for those who can afford to pay it — if the service helps people to do better research and saves a bunch of travel. We could also set up a pricing model proportional to each country’s carbon emissions or something like that.

In our concrete methods, we have aligned ourselves with the ‘long-term perspective’. This includes both retrospective and prospective thinking. For example, the things that were timely 7 years ago might not be so timely now; in many cases the relevance of a given innovation goes down over time. However, Emacs has an evolutionary character that has allowed it to keep up with the times — becoming more relevant and useful ever since Steele and Stallman started to systematise Editor MACroS for the Text Editor and Corrector (TECO) program. Not only has the technology evolved, but so has the social setting in which this work is done. Whereas the concepts underlying the free software movement were based on “communal sharing” of source code, these methods can be extended and allow us to synthesise new relationships within broader semiotic commons. Emacs can become part of a system for addressing large-scale existential problems, by expanding the frontier of what’s possible for human beings.

Our vision for change in the Emacs Research Group is summed up in the previous TODO items and cross-referenced with peeragogy patterns. Like Season 0, Season 1 will be a six month transdisciplinary sub-part-time volunteer project, embedded within the larger peeragogy network.

For Season 1, we’ve distilled the concrete aim to make Emacs more accessible via tutorials and other material for \textsc{Newcomers}; we also have a better idea of how to do meaningful research about Emacs that engages SERENDIPITY; we have plans that will develop new ways of working with Emacs and other free/libre/open source tools that suitably FORMALISE the informal workflow we have described here; and we will apply these methods in a way that enhances the DIVERSITY of the tech landscape, and improves access to learning more broadly, e.g., with groundwork for an open source RECOMMENDER tool. Progress can be measured by completion of the TODO items listed above.

Recall that the litany is also referred to as the ‘problem’ layer. The pattern community is comfortable with problems: a ‘problematizing’ view of reality is one of the main features of the method. However, there are a range of problems that the community is familiar with which are not fully solved. For example, ‘Alexander's Problem’, as described by his collaborator Greg Bryant:

… despite all of the tools he created, his penetrating research, his many well-wrought projects, and his excellent writing, he did not manage to grant, to his readers, the core sensibility that drove the work. He also did not organize the continuance of the research program that revolves around this sensibility. cite:bryant2015

Coming at similar issues from a different direction, Alexander framed a related query for programmers using pattern methods:

What is the Chartres of programming? What task is at a high enough level to inspire people writing programs, to reach for the stars? cite:alexander1999a

These are some of the high-level problems that are known and discussed in the patterns community, but which do not necessarily have consensus answers. More recently, Dawes and Ostwald cite:dawes2017a develop an elegant taxonomy of existing criticisms of the pattern method. In outline, their taxonomy covers criticisms at the following three layers:

Conceptualisation

Ontology, Epistemology \newline (e.g., “Rejecting pluralistic values confuses subjective and objective phenomena”)

Development and documentation

Reasoning, Testing, Scholarship \newline\hfill (e.g., “The definitions of ‘patterns’ and ‘forces’ are inexplicit”)

Implementation and outcomes

Controlling, Flawed, Unsuccessful \newline\hfill (e.g., “Patterns disallow radical solutions”)

By showing how the criticisms relate to one another, Dawes and Ostwald begin to develop a GENEALOGY at the level of critical perspectives. At the very least the critiques they examine show that there is not just one pattern discourse, but many. In a parallel work the same authors analyse the structure of A Pattern Language, and develop three alternative perspectives on APL's contents, which they refer to as the generalised, creator, and user perspectives cite:Dawes2018. These perspectives amount to different techniques for REORDERING KNOWLEDGE. We will elaborate at the next level.

At this level, we examine where the familiar problems come from. Using graph-theoretic measures Dawes and Ostwald cite:Dawes2018 found that:

• The creator model appears to be less intelligible than the user model, while
• The creator’s perspective of the language is more beautiful.

Their central finding, however, is that many patterns in which Alexander had medium or low confidence in fact occupy a relatively central position in APL's graph:

the patterns which are most likely to be encountered by designers – are most easily accessed, or provide greatest access to other patterns – might be those which Alexander acknowledged were incapable of providing fundamental solutions to the problems they addressed.

This means that novice users could be expected to encounter problems in application of APL's patterns: “despite its often authoritative and dogmatic tone, Alexander’s text was framed as a work in progress, rather than a definitive design guide” (p. 22). Dawes and Ostwald suggest that their analysis could point to “prime opportunities to continue the development of A Pattern Language'' (p. 21).

Here, however, a range of issues more closely linked to software and media begin to crop up. There are a range of ‘other’ pattern discourses which could be relevant here — ‘other’ in the sense mentioned in our REORDERING KNOWLEDGE pattern, so not necessarily in close touch with PLoP — these include PurPLSoc and the world of practicing architects. There have been some attempts at creating systematic archives of patterns, but these have always had significant buy-in from a wide community.

Importantly, the first-ever Wiki was developed in connection with a platform for developing, sharing, and revising pattern languages cite:cunningham2013a.^{9, 10} However, there was a distinction between the discussions and the finished patterns. In the 2013 retrospective, Ward Cunningham writes:

The original wiki technology functioned in a direct open-source mode, which allowed individuals to contribute small pieces to incrementally improve the whole.

This is true if by “open source” we understand what you see when you click Edit — but the term is misleading relative to contemporary usage, which is usually linked with the Open Source Initiative’s definition, and centred on the premise that “Open source doesn’t just mean access to the source code.”¹¹ On the c2 wiki, licensing was restrictive. Discussions were to take place in “letters and replies” rather than revision or annotation of the published patterns; rights associated with the finished patterns were closely guarded.^{12, 13}

Although Wiki technology could in principle have been a site for ongoing DECONSTRUCTION of patterns, this didn’t seem to happen on c2. This is itself interesting and worth deconstructing a bit. Notably, there were only four published “letters and replies”.¹⁴ Unfortunately, we could not find a public archive of the “design patterns mailing list” where further discussions took place. This is certainly suggestive of contingency.

Over the years, other issues and concerns came to the fore. Jenifer Tidwell’s charges against the Gang of Four (alongside other developer-centric pattern languages) resonate with what we saw in Dawes and Ostwald, above:

… the reality of a software artifact that the developer sees is not the only one that's important. What about the user's reality? Why has that been ignored in all the software patterns work that's been done? Isn't the user's experience the ultimate reason for designing a building or a piece of software? If that's not taken into account, how can we say our building – or our software – is “good”? — http://www.mit.edu/~jtidwell/gof_are_guilty.html

Notice that now the user of the designed artefact has entered the story as a different figure from the user of the pattern language, whom we met above. Tidwell’s critique suggests at least a couple ALTERNATIVE PASTS AND FUTURES: e.g., what if the end-user had been placed at the centre the whole time? Alternatively, what if the primary focus of patterns was to facilate interaction between different stakeholders? The fact that Tidwell’s book cite:tidwell2010designing and an essay by Jans Borchers cite:borchers2008pattern which drew inspiration from her critique both have over 1000 citations on Google Scholar shows that Tidwell’s perspective has been impactful. To get a sense of how the pattern community may have been informed by this critique — along with related trends and concerns — we can look at how the writers workshops at PLoP have evolved over time. In Table 2 a selection of titles of workshop sessions show how the focus of PLoP evolved from primarily ‘programming’ oriented to a much broader contextual view over time. Indeed, by 2019, the focus is almost exclusively ‘contextual’.

\rowcolors{2}{gray!25}{white}

The situation with licensing on c2 is particularly interesting in light of Alexander’s perspective that APL was a “living language”. In principle, Wiki technology might have presented the opportunity to realise this vision fully for the first time, in a virtual setting. Wiki technology did become widely influential when it was combined with a free content license on Wikipedia (originally GNU FDL, later CC-By-SA).

Fast-forwarding to the present day, Christopher Alexander’s website patternlanguage.com writes about The Struggle for People to be Free — but it is not referencing freedom in the GNU sense.

In 1979 he was concerned: “Instead of being widely shared, the pattern languages which determine how a town gets made becomes specialized and private.” In 2021, APL itself is only legally available for subscribers or for people who purchase a paper copy of the book. (Or through a library!) Of course, like many famous texts it can also be obtained extra-legally for download as a PDF: but that format does not afford downstream users the opportunity to collaborate on the text’s further development.

Gabriel and Goldman talk about sharing and ‘gift culture’ in their essay Mob Software: The Erotic Life of Code, and discuss a way of working that seems to bring back the early days of hacker culture. (Notably, this essay was presented as a keynote talk at the same programming conference where Alexander had spoken four years previously.) They reference the open source community — but not the free software community, so we will follow Gabriel and Goldman’s usage here — as the origin of Mob Software.

Because the open source proposition asked the crucial first question, I include it in what I am calling “mob software,” but mob software goes way beyond what open source is up to today.

That “crucial first question” is: “What if what once was scarce is now abundant?” It is well known that the PLoP conference series builds on this idea: it includes shepherding and workshops cite:gabriel2002a as well as games, informal gifts, and other measures that aim to create a sense of psychological safety: indeed, the central issue of making a space where ‘failure’ is OK and even celebrated, as per Mob Software. The essay develops its own criticisms of open source, e.g., “the open-source community is extremely conservative” and forking happens rarely. (Five years later, with the creation of Git, forking became considerably more typical.) Resonating with Tidwell’s critique from above:

One difference between open source and mob software is that open source topoi are technological while mob software topoi are people centered.

On a technical basis, Gabriel’s vision sounds a lot like today’s world of microservices. While his vision hasn’t fully come to pass — there are still many services with proprietary source code — nowadays many big companies are also big proponents of open source. Here we can notice that Gabriel was employing a technique of imagining ALTERNATIVE PASTS AND FUTURES, e.g., he imagined a future in which:

Mentoring circles and other forms of workshop are the mainstay of software development education. There are hundreds of millions of programmers.

We would like to dig somewhat deeper into the foundations of the worldview that Gabriel puts forth in this essay. Usefully, an article by VanDrunen “traces the source of Gabriel’s ideas by examining the authorities he cites and how he uses them and evaluates their validity on their own terms” cite:vandrunenchristian. His critique functions as a (detailed) DECONSTRUCTION of the thinking behind Gabriel’s essay. Some key excerpts appear in Table 3.

VanDrunen surfaced various concepts in Gabriel’s essay that would be at home at this level, for example, the concept of duende that Gabriel takes over from Garcia Lorca originally derives from dueño de casa, the name of a certain kind of household spirit. VanDrunen’s critique is also useful for our purposes because it points to the importance of considering the deeper layers in developing a concept. It’s not just a matter of finding a culture’s myths: where may also be a conflict at this level.

One important narrative for the pattern discourse is in plain view within the terminology of problems and solutions, which come from mathematics or physics. Alexander’s worked at the level of narrative to connect the patterns discoures to a scientific worldview, seeking a sense of objectivity. For example, in “The Atoms of Environmental Structure”:

most designers … say that the environment cannot be right or wrong in any objective sense but that it can only be judged according to criteria, or goals, or policies, or values, which have themselves been arbitrarily chose. We believe this point of view is mistaken.

Notice that, here, the discourse is position as different from the mainstream. The key differentiator is not the language of problems and solutions which would be familiar to anyone with an engineering background; rather, but in a certain notion of wholeness. Which notion of wholeness remains to be surfaced. Quoting, again, from “The Atoms of Environmental Structure”:

We believe that all values can be replaced by one basic value: everything desirable in life can be described in terms of freedom of people’s underlying tendencies. … The environment should give free rein to all tendencies; conflicts between people’s tendencies must be eliminated.

Historically, there are at two major varieties of wholeness: one that is based on progressive differentiation (perhaps understood as unfolding from substance, per Spinoza), and the other generated by interaction between components (perhaps that of mutually reflecting monads, per Leibniz). In support of these allusions, a quote of Alexander from TNO: it “may be best if we redefine the concept of God in a way that is more directly linked to the concept of ‘the whole.’” This sounds a lot like Spinoza!¹⁵

Can obtain some useful DISTANCE by thinking about how different kinds of wholeness are associated with different symbols. In terms of metaphors, we have already encountered overt images like that of Chartres cathedral. If we allow ourselves to explore further afield, other symbols of wholeness come to mind: these include the circle, the cross — or potentially the cross inside a circle, \begingroup\alch\symbol{"3B}\endgroup.¹⁶ Related but more elaborated symbols include the circle with a cross rising above it (\varTerra) which is both the modern astronomical symbol for Earth and also linked with the Carthusian order (Stat crux dum volvitur orbis: the cross is steady while the world turns) — the Rod of Asclepius (\Asclepius, for the deity associated with healing or making whole) — this last symbol sometimes being inter-confused with the Caduceus (\Caduceus, the symbol of Hermes, the deity assocated with mediation of various forms, and also echoed in the planetary symbol for Mercury, \begingroup\alch\symbol{"53}\endgroup).

These symbols are useful map-markers for the landscape we are exploring. In short, the pattern discourse seems to be drawn to both major traditions of wholeness: and also to seek to unite them. We get the idea of unfolding in APL and other pattern languages that work in a top-down manner: however, we also get the notion of patterns and principles that are generative of emergent phenomena. As we mentioned above, at this level, architecture and programming were seen, by Alexander cite:alexander1999a, to unite: here pointing in the direction of bio-hacking and nanotechnology (e.g., for molecular self-assembly)¹⁷ — at least at the allusive level if not at the concrete level.

Relevant to the overall case we are making here, the following quote suggests we are on a fruitful track:

Generative patterns work indirectly; they work on the underlying structure of a problem (which may not be manifest in the problem) rather than attacking the problem directly.¹⁸

Clearly, another key metaphor in the discourse is the metaphor of a language:

… as in the case of natural languages, the pattern language is generative. It not only tells us the rules of arrangement, but shows us how to construct arrangements - as many as we want - which satisfy the rules. (at ibid., quoting from The Timeless Way Of Building, pp. 185-6)

Indeed, the prominence of linguistic metaphors reminds us that Alexander’s writing contains many further traces of symbols asociated with Hermes:

In the house, [Hermes’] place is at the door, protecting the threshold… He could be found around city gates, intersections, state borders, and tombs (the gateways to the other world). cite:benvenuto1993hermes

At the time when Hermes was actively embraced as a deity, he was typically paired with Hestia, the goddess of the hearth, whose “domain was internal, the closed, the fixed, the inward” (ibid.) The discourse around patterns certainly contains aspects a movement “to archaic roots” present in other 20th Century thought: but unlike some of these, patterns methods are apparently working to restore “the dialectic between centripital immobility and centrifugal mutation.” One aspect of this is a movement towards foundations (in the form of fundamental princples, per ANO): these are associated with Hestia. The resolution within pattern language — as a form — seems to be along Nietzschean lines: “anything that is becoming returns” (i.e., is discussable as pattern), and “contingency resolves itself into necessity” (i.e., the wholeness of generativity ultimately recovers the wholeness of unfolding).¹⁹

Patterns have periodically been discussed in explicitly computational terms — however, that direction of work so far remains mostly at the level of a proposal cite:alexander1999a,moran1971a, with limited discipline-specific uptake within architectural design cite:jacobus2009a,OXMAN1994141. Could this change? We wonder if design patterns — and related designs for Ostrom-style institutions cite:ostrom2009a (p. 11) — should be brought onto a similar computational footing, and included in the computational mix within climate modelling software. These developments might be accompanied by more mathematical precision along the lines of the FORMALISE pattern, e.g., drawing on and moving beyond computational paradigms such as contract-based programming and the Semantic Web.

\medskip

In the field of policy, ‘adaptive capacity’ describes a society’s ability to recover after a shock cite:thonicke2020advancing,magnan2010better. This in turn is linked with the health and adaptivity of the society’s institutions cite:fidelman2017institutions. As we saw earlier, innovation conflicts with consistency and efficacy — however, innovation in fact may be a necessary response to other ongoing environmental changes. Mehaffy and coauthors worked with Ward Cunningham to make their book A New Pattern Language for Growing Regions cite:mehaffy2020new into a wiki, npl.wiki, which is licensed under CC BY-SA 4.0. Will other pattern developers follow suit and move to open licensing — and suitable infrastructures for working with open contents?

As we’ve seen in our work with Emacs, PlanetMath, and Peeragogy, projects need a lot more than simply access to source code in order to thrive. We see a link to the topic of reproducible research. Above and beyond the immediate technical considerations cite:sandve2013ten, we think that something is “reproducible” if it is teachable to someone new! We’ve found Org Mode (and literate programming in general) to be useful for this. At the same time, collaboration across different skill sets is challenging. In the Minnesota 2050 project, participants were selected from a variety of professions and leadership roles to produce scenarios for energy and land use, and combined modelling with scenario planning cite:olabisi2010. However, actually solving large-scale problems together in interdisciplinary teams will require new thinking and additional tools: to bridge between the viewpoints of, e.g., professional futurists, programmers, data scientists, local farmers — and to draw on the insights of citizen scientists cite:wildschut2017a.

Reflecting on the increasingly contextual and transdisciplinary nature of the discussions at PLoP and other venues, along with the other points above, brings to mind Hesse’s The Glass Bead Game. This reference can help tie these points together at the level of myth, metaphor, and narrative:

… the narrator informs us that the Game is like a universal language: a way of connecting traditions and cultures from both the East and the West and of playing with all disciplines and values. cite:roberts2007conscientisation

For those who are familiar with the novel, this reference also suggests: proceed with caution. How hierarchical do we want our community, or our society, to be? How critical are we capable of being towards the tenets we hold dear? When reflecting on futures-oriented discourses, Slaughter described these as sitting on a spectrum: “participatory and open at one pole and closed (or professionalised) at the other” cite:SLAUGHTER1989447. In The Glass Bead Game, everyone is able to play, but only some become excellent. Related issues show up in our current technological culture cite:unger2019knowledge — how do they show up in the cultures we might envision? With due care patterns might become the basis of widespread technical literacies, not for an elite group of hackers or for a few highly-paid rockstars, but for everyone.

Our vision for change is that all of these scenarios will be given serious thought. Progress will become measurable partly through citations to this paper, and other markers of debate and ensuing trial-and-error uptake, such as workshops that use DPL and CLA together to explore the scenarios. The Emacs Research Group can use these ideas to help connect with potential stakeholders. The Peeragogy network can help facilitate some of the discussions and projects. As we gather evidence, we can return to the futures community and share what we’ve learned with them. If the ideas we have considered here became part of a shared outlook between all of these different communities, many things may start to move quickly.