🔭 DR: David Spivak’s Operad of Wiring Diagrams: Foundations and Applications (prompted with Spivak 2013: https://gist.github.com/lmmx/068749924b7db88af045d863ceb6f6d7)

1-dr_spivak-operad-wiring-diagrams-foundations-and-applications.md

David Spivak’s Operad of Wiring Diagrams: Foundations and Applications

Formal Foundation and Interpretation of Wiring Diagrams

Wiring Diagrams as Operads: Wiring diagrams (WDs) are a formal graphical syntax for connecting components, capturing how outputs of some components feed into inputs of others. Spivak showed that WDs can be rigorously treated as the morphisms of an operad (denoted $\mathcal{T}$ or $\mathcal{W}$) ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits) (). An operad is like a category, but instead of arrows from one object to another, it has operations (morphisms) with multiple inputs and one output (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). Composition in an operad is defined by substituting the output of one operation into an input of another, effectively nesting or wiring together sub-operations (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). In the case of WDs, each operation is a wiring diagram: it takes several inner components (each with its own interface of inputs/outputs) and interconnects them to form a composed system with an overall input/output interface (). The operad’s objects can be thought of as interfaces (types or ports), and its morphisms are the wiring diagrams that connect a list of input interfaces to an output interface (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). This operadic structure captures the hierarchical, self-similar nature of wiring diagrams – a diagram can be plugged into a slot of a bigger diagram, just as a subcircuit can be treated as a single component in a larger circuit ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). Composition of WDs corresponds to this kind of nesting: plugging the outputs of some sub-diagrams into the inputs of another yields a bigger wiring diagram ().

Categorical Structure and Modularity: Treating WDs as an operad provides a powerful algebraic framework for composition, modularity, and abstraction in computation. Just as a category encapsulates compositionality of single-input/single-output processes, an operad encapsulates multi-input compositional patterns (think of combining several components into one) (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). Each WD encodes a pattern of interconnection – which wires (data flows) link which subcomponents – abstracting away the specific behavior of the components. This enforces modularity: one can replace a sub-diagram (component) with another of the same interface without changing the overall wiring structure. The operad axioms (associativity of composition and identity wiring diagrams) ensure that complex compositions can be built in a well-defined, hierarchical manner (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). In essence, operads are the “rules of modularity” – if you can specify the interfaces of components, how they can be arranged and nested, you likely have an operad governing the system’s composition () ().

Syntax vs. Semantics – Functorial Interpretation: A wiring diagram itself is a syntactic object – a combinatorial description of how parts are connected. To give it meaning (semantics), one provides an operad algebra or model for the WD operad (). Concretely, an algebra of the operad is a functor $H: \mathcal{W} \to \mathbf{Set}$ (or to another category) that assigns to each interface $X$ a set $H(X)$ of concrete implementations (e.g. actual functions, processes, or components of type $X$), and to each wiring diagram (an operad morphism) a corresponding composition function (). This functor interprets each box (component) in a diagram as a specific operation, and the wiring diagram as the recipe for composing those operations. For example, if one interface is a pair of types $(A,B)$ as inputs and another type $C$ as output, a box of that type might represent a function $f: A \times B \to C$. A wiring diagram connecting boxes $f_1, f_2, \dots, f_n$ into a larger box $F$ will be sent by $H$ to an actual function $H(F)$ that composes $f_1,\dots,f_n$ according to the diagram’s wiring (). In this way, the meaning of a WD is the composed computation it represents. Importantly, the wiring diagram language captures only the structure of composition (which output goes to which input) and is agnostic to what each component does () (). This makes WDs a kind of universal syntax for composition: by choosing different operad algebras, the same WD can represent a circuit, a database query, a software pipeline, etc., as long as the components and wires are interpreted appropriately ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits) ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits).

Self-Similarity and Hierarchical Semantics: Because wiring diagrams can be nested inside each other, they exhibit self-similarity: a whole diagram can play the role of a component in a larger diagram ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). The operad formalism captures this by allowing an output interface of one diagram to match the input interface of another, so that diagrams compose. Identities in the operad are trivial wiring diagrams (wires that directly connect inputs to outputs one-to-one), and the operad’s laws ensure that plugging diagrams together is associative. This rigorous foundation means we can reason algebraically about complex networks of computation. The precise semantics of a WD is thus given in two steps: first, the operad describes the abstract syntax of interconnection; second, an algebra (interpretation) provides the semantics by mapping that syntax to an actual composed process (). For instance, Spivak defines an algebra $\mathsf{Rel}$ on the operad of WDs, where each interface is interpreted as a set and each wiring diagram as a specific relation on those sets ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). Under this interpretation, a wiring diagram acts as a conjunctive query on relational databases – the wires enforce which variables (columns) are shared between subqueries, yielding a relational algebra query when composed ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). This illustrates how WDs can serve as a high-level language for different domains once semantics are assigned.

Example – Function Composition: As a simple example, imagine two components (boxes) representing functions, $f: X \to Y$ and $g: Y \to Z$. A wiring diagram can connect the output of $f$ to the input of $g$, forming a new composite box with input $X$ and output $Z$. In the operad $\mathcal{W}$, this is a morphism taking one box of type $X\to Y$ and one box of type $Y\to Z$ as inputs, and producing a box of type $X\to Z$ as output. The operad composition law would identify this wiring diagram as the composite $g \circ f$. In the WD syntax, there is exactly one canonical diagram representing $g \circ f$, whereas in a linear textual syntax one could write it in many equivalent ways (e.g. g(f(x)) or via some temporary variable). Thus, WDs can serve as a normal form for compositions – in fact, it has been shown that wiring diagrams can be used as normal forms for computations in symmetric monoidal categories, providing a unique, diagrammatic representation of composed morphisms () (). Unlike traditional string diagrams which are depicted geometrically, wiring diagrams are purely combinatorial data (like a graph or syntax tree), which makes them more amenable to manipulation by computer algorithms () ().

Abstraction of Duplication and Deletion: One notable aspect of Spivak’s wiring diagram operad is how it handles duplication or discarding of wires (data). In many computational settings, a single output may need to feed into two inputs (fan-out) or an input may be unused in a particular composition. The operad of WDs explicitly includes generators for duplicating a signal and for deleting (discarding) a signal (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). This means the operad’s morphisms distinguish between ordinary transformations and the special “structural” operations of copying or discarding data. Other formalisms, like monoidal categories, typically treat these via properties of the category (e.g. a Cartesian category has diagonals and projections to copy or delete). Spivak’s operad instead builds those primitives into the wiring syntax itself (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). This explicitness can be useful when reasoning about systems where not all inputs are used or where one input feeds multiple destinations. It also aligns with logical aspects: for instance, duplication corresponds to a logical conjunction (using the same value in two places), and deletion corresponds to existential projection (ignoring a value). By making these operations first-class elements of the operad, the wiring diagram framework can uniformly capture the flow of information including branching and merging of data streams. This careful treatment of wiring semantics ensures the operad can model a wide range of computational structures, including those that require fan-out or are not purely linear flows (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth).

In summary, the formal foundation of WDs is an operadic syntax for compositional systems. It provides a categorical algebra of wiring diagrams where composition = connecting outputs to inputs, and an interpretation (via operad algebras) gives semantics to those diagrams in any domain of interest. This framework guarantees that notions of composition, modular design, and abstraction can be treated with mathematical rigor, which is essential for reasoning about complex programs and systems in a principled way.

Spivak’s Contributions and Extensions of Wiring Diagrams

David I. Spivak has been a leading figure in developing the theory of wiring diagrams and exploring their applications in computer science. His key contribution is the identification and formalization of the operad of wiring diagrams as a unifying language for diverse compositional systems. In his 2013 paper “The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits”, Spivak introduced the operad $\mathcal{T}$ of wiring diagrams and demonstrated its self-similar, hierarchical nature ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). This work showed that many systems that look different — from database queries to electronic circuits — can be described using the same underlying operadic grammar of “wires and boxes.” The paper not only defines the operad $\mathcal{T}$ rigorously, but also discusses an algebra $\mathsf{Rel}$ on $\mathcal{T}$, wherein wiring diagrams are interpreted as relations (database queries) ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). By doing so, Spivak connected category theory with databases: each wiring diagram corresponds to a conjunctive query, and composing diagrams corresponds to composing queries. He gave examples such as digital circuit diagrams as a special case of WDs, and even showed how recursion and plug-and-play modularity in software/hardware can be modeled operadically ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). The ability to represent recursive behavior in the operad is notable: it means a wiring diagram can have a component whose definition (via a sub-diagram) refers back to the overall diagram, capturing a form of self-reference or feedback in a principled way.

Building on the base operad, Spivak (often with collaborators) extended the idea to more specialized operads and algebras. For example, with Dylan Rupel he developed the operad of temporal wiring diagrams ([1307.6894] The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes). This variant, introduced in Rupel & Spivak 2013, incorporates a notion of time or sequencing in the wires. In the temporal wiring diagrams operad (often denoted $\mathcal{W}$ in that context), wires are directed with a notion of length or delay, modeling flows of information in time-series or streams ([1307.6894] The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes). They define an algebra $\mathcal{P}$ of “propagators” (inspired by Radul and Sussman’s propagator model of computation) which are essentially discrete-time processes that consume input streams and produce output streams ([1307.6894] The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes) ([1307.6894] The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes). This work demonstrated that WDs are not limited to static relationships (like database relations or static circuits) but can handle dynamic, stateful processes. In the temporal operad, feedback loops in a wiring diagram correspond to dynamical systems with internal state (since an output fed back to an input creates a loop in time). Spivak showed that while undirected wiring diagrams (his earlier model) are great for static constraints and relational models, directed temporal WDs are suited for signal flows and processes ([1307.6894] The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes). Essentially, earlier operadic models allowed you to compose constraints or relations (declarative, orderless systems), whereas the temporal operad handles sequential composition and feedback in a time-indexed manner. This extension was important for applying operadic methods to areas like digital signal processing, control systems, or any discrete dynamical systems.

In addition to these foundational papers, Spivak has delivered talks and written expository work situating operads of WDs in broader applied category theory. He emphasized that operads are a general tool for modular design — the “mathematics of modular systems” — and wiring diagrams are a prime example of how to formalize modularity () (). His presentations (e.g. “Operads for Modular Design” (2015) and “A Mathematical Language for Modular Systems” (2015)) illustrated WDs with numerous examples: from simple circuits to more abstract “circuits” of database tables or mathematical formulas (A mathematical language for modular systems David I. Spivak Presented on 2015/01/29) (A mathematical language for modular systems David I. Spivak Presented on 2015/01/29). In the database example, each box is a database table (with input/output ports representing foreign key links), and a wiring diagram specifying how tables join corresponds to a structured query (A mathematical language for modular systems David I. Spivak Presented on 2015/01/29) (A mathematical language for modular systems David I. Spivak Presented on 2015/01/29). By developing the operad-algebra approach in this way, Spivak extended traditional categorical structures (like monoidal categories used for string diagrams) to a more flexible, multi-typed, and hierarchical setting. Traditional string diagram formalisms assume one fixed monoidal category (one type of wire) and planar compositions; Spivak’s operads handle typed wires (each port can have a label or type), multiple nested levels, and explicit handling of duplication/deletion as noted earlier. This can be seen as an extension of category theory’s descriptive power for computation: rather than just saying “morphisms compose”, operads can say “complex networks of morphisms compose according to these patterns.” It bridges the gap between theory and engineering: the operad of WDs acts as a theoretical backbone that can describe plug-and-play hardware components, software modules, or data pipelines all within the same algebraic framework ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits).

Spivak’s work also connects to many themes in applied category theory (ACT). For instance, the operad of WDs has been related to decorated cospan categories (another formalism for composing open systems). Baez and Fong (2015) discuss how Spivak’s operad approach and the cospan approach are essentially equivalent ways of capturing networks and interconnections (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). Both frameworks enforce the idea of “compositionality” for complex systems, though Spivak’s operad formalism highlights the role of copying and deleting inputs explicitly (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). This connection is important in ACT because it means results and intuitions from one framework (say, network compositionality via cospans) can inform the other (operads of WDs) and vice versa. Moreover, Spivak and collaborators applied wiring diagram operads to dynamical systems and control theory. In a 2016 paper by Schultz, Spivak, and Vasilakopoulou, they provided a framework for composing Moore machines (a type of state machine) using directed wiring diagrams (Wiring diagrams for Mealy machines – Topos Institute). By treating state machines as boxes with stateful behavior, and wiring them, they could model complex automata compositionally. This line of work indicates how WDs serve as a meeting point for computer science (automata, circuits, programs) and other fields like biology or engineering (where dynamical system models are common). Indeed, in 2018–2020, Spivak joined the Topos Institute and continued exploring applications of wiring diagrams to areas such as neural networks and knowledge representation (for example, using “neural wiring diagrams” to describe message-passing in multi-scale systems (Neural wiring diagrams for message passing in multiscale ...)).

Another significant contribution is the influence Spivak’s work had on others, leading to a rich literature on WDs. Donald Yau’s “Operads of Wiring Diagrams” monograph (2018) builds on Spivak’s foundation and provides a comprehensive study of the combinatorial structure of various wiring diagram operads ([1512.01602] Operads of Wiring Diagrams). Yau gives finite presentations (generators and relations) for the operad of directed WDs (eight generators and 28 relations are needed, reflecting things like merging wires, splitting, etc.) ([1512.01602] Operads of Wiring Diagrams). He also studies algebras for these operads, including the propagator algebra, the algebra of discrete dynamical systems, the algebra of open dynamical systems, and the typed relational algebra, providing finite presentations for each ([1512.01602] Operads of Wiring Diagrams). These correspond exactly to the kinds of applications Spivak envisioned: propagators (in AI and programming languages), discrete-time systems, open continuous systems, and database relations. Furthermore, Spivak’s conjectures (such as one about the “quotient-freeness” property of the relational algebra on WDs) have been examined and partially verified in Yau’s work ([1512.01602] Operads of Wiring Diagrams). This signifies that Spivak’s initial ideas opened up a new research direction in category theory and theoretical computer science, inspiring others to deepen the theoretical understanding and expand the range of operadic models.

In summary, David Spivak’s contributions established wiring diagrams as a versatile, formal language for composition and provided concrete examples in computing (databases, circuits, etc.) to demonstrate their utility. He extended classical categorical approaches by using operads to handle multi-component composition with explicit wiring. His research and collaborations showed that the operad of WDs is not just a theoretical curiosity, but a practical tool for applied category theory, enabling cross-disciplinary modeling of complex, modular systems. Spivak’s work paved the way for using category theory in computation in a more structured way, influencing everything from how we might design query languages to how we might build modular software or reason about stateful systems.

Wiring Diagrams and Declarative Programming Paradigms

One of the notable alignments of wiring diagram methodology is with declarative programming paradigms. Declarative programming (such as functional or logic programming) is characterized by describing what the program should accomplish – relationships between inputs and outputs or logical conditions – rather than explicitly detailing how to execute step by step (as in imperative programming). Wiring diagrams naturally emphasize the structure of connections and the relationships between components, which is very much a “what, not how” description. A WD specifies that “the output of component A is connected to the input of component B” and so on, essentially describing a dataflow or dependency graph. It does not inherently specify the order of execution or the mechanism by which data moves – those are either determined by the semantics (for example, data flows when available, or all functions compute simultaneously in a combinatorial circuit) or left abstract. This makes WDs a good fit for representing programs in a declarative, dataflow style.

Functional Programming: In a pure functional paradigm, programs are built by composing functions, often without side effects. This composition is naturally visualized as a directed acyclic graph of data flowing from one function to the next. Wiring diagrams can directly capture this: each function is a box, and if the output of $f$ feeds into $g$, we draw a wire from $f$ to $g$. Higher-order functional combinators (like map, fold, etc.) can themselves be seen as wiring patterns of their argument functions. The order of execution is not central – what matters is the dependency structure (which outputs feed which inputs). Therefore, a functional program’s structure can be seen as a wiring diagram where the wires denote pure data dependencies. Many visual programming environments for functional or dataflow languages (e.g. LabVIEW, Simulink, or functional block diagrams in control systems) are essentially informal wiring diagrams. Spivak’s operadic WDs provide a formal underpinning for such diagrams. In fact, one can view a pure functional program as an algebra over the wiring diagram operad where each interface $X\to Y$ is interpreted as the set of all pure functions of type $X \to Y$. Composition of these functions via wiring diagrams is just ordinary function composition or tupling of arguments. This was hinted at in Spivak’s work: however, pure functions without state form an algebra only for acyclic wiring diagrams (no feedback loops). If one allows loops (recursion), the algebra of pure functions is not closed under the operad’s composition (A mathematical language for modular systems David I. Spivak Presented on 2015/01/29). The issue is that a feedback loop implies some form of state or iteration (the output of a function is fed back as its input, requiring an initial value or infinite loop). Spivak pointed out that “historically independent” processes (memoryless functions) won’t suffice; one needs something like stream processors (with memory) to interpret diagrams with feedback (A mathematical language for modular systems David I. Spivak Presented on 2015/01/29). This observation aligns with the fact that functional programming with recursion or loops typically requires either lazy evaluation or an explicit notion of state/feedback (e.g. a fixed-point combinator). Nonetheless, for straight-line functional composition, wiring diagrams give a precise, declarative picture. The programmer declares the composition by drawing wires; the underlying semantics (the algebra) takes care of actually calling $f$ then $g$ in the correct order. This separation of specification vs. execution is a hallmark of declarative paradigms.

Logic and Constraint Programming: Wiring diagrams can also represent relations rather than functions, which connects to logic programming (where programs are sets of logical relations or constraints). In a logic program, one might have predicates $P(X,Y)$ and $Q(Y,Z)$ and the “program” is to find $X, Y, Z$ such that $P(X,Y)$ and $Q(Y,Z)$ hold – essentially a join on the variable $Y$. This is exactly the kind of scenario Spivak demonstrated with the $\mathsf{Rel}$ algebra on operad $\mathcal{T}$ ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). Each box can represent a relation (a logical constraint between variables), and a wire connecting an output of one to an input of another indicates that the two relations share a common variable (the value is constrained to be equal). The overall wiring diagram then represents the conjunction of all those constraints – a larger relation obtained by joining on the wired variables. This corresponds to a declarative query or logic program where the diagram visually specifies which variables are identified with each other ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). For example, a WD that connects a box representing $P(X,Y)$ to another representing $Q(Y,Z)$ (wire from the $Y$ output of $P$ to the $Y$ input of $Q$) yields a composite relation $R(X,Z)$ = “there exists $Y$ such that $P(X,Y)$ and $Q(Y,Z)$,” which is a conjunctive query in databases. The programmer (or designer) does not write an algorithm to join $P$ and $Q$; they simply declare the connection, and the algebra of relations (or a query engine implementing it) takes care of the actual execution (like a SQL join). This is a purely declarative specification. Spivak’s work made it clear that wiring diagrams can serve as a graphical logic programming language in this way, where composition of diagrams corresponds to logical composition of constraints ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits). Moreover, earlier “undirected” wiring diagrams (where wires don’t have a direction) correspond closely to bidirectional constraints or equalities, which are common in constraint logic programming. Indeed, Spivak notes that previous operadic models of WDs with undirected wires were useful for “static systems of constraints” ([1307.6894] The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes) – essentially situations where one is describing a set of equations or relations that hold simultaneously, without a directed flow of information. This covers use-cases like logic circuits (combinational circuits can be seen as constraints between inputs and outputs, solved by propagation) or constraint satisfaction problems. In such a setting, a wiring diagram is a declaration of which outputs must equal which inputs (just labels connected by wires, no inherent direction of data flow), very much in line with a declarative constraint paradigm.

Non-Imperative Models and Abstraction: Because WDs focus on high-level connectivity, they can encapsulate paradigms like dataflow programming, functional reactive programming, and model-based design, all of which are more declarative than writing imperative code. A dataflow graph (like in streaming data processing frameworks) is essentially a wiring diagram of transformations and merges; one declares the graph, and the runtime handles data propagation. Wiring diagrams could formally represent such graphs. In functional reactive programming (FRP), one describes how outputs react to inputs over time in a declarative manner (“connect this signal to that, apply this function”), which again is naturally a wiring diagram of signal processors. The temporal operad $\mathcal{W}$ that Spivak developed with Rupel is directly applicable here: it formalizes the notion of stream processors connected by wires ([1307.6894] The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes). Each stream processor (propagator) is like a continuously running piece of a program, and the wiring diagram declares the network of these pieces. This aligns with the declarative style of FRP where one does not explicitly interleave operations in time, but instead declares the static network of dependencies and trusts the framework to handle the propagation of values over time.

In all these cases, wiring diagrams provide a visual, declarative specification of a computation. The programmer or modeler specifies the what (which components are connected, hence which functional or logical relationships exist) and not the low-level how. Even complex control structures can be represented: e.g., a conditional can be seen as a wiring diagram that uses a boolean input to select between two sub-computations (a multiplexer), which is again a structural description. Iteration or recursion can be represented by feedback loops in the diagram (though, as noted, executing such loops may require a semantics with state or fixed-point solutions). The advantage of WDs in declarative terms is that they encourage thinking in terms of compositional components and their relationships, mirroring the way one might reason about a problem logically or functionally.

Another perspective is that WDs are akin to writing equations in a point-free style (as in some functional programming), where one connects operations without naming intermediate variables. The wires are the intermediate variables implicitly. This point-free, relational style is common in declarative specifications (for instance, in SQL or in functional combinator libraries) and WDs make it concrete and visual.

In conclusion, wiring diagrams align closely with declarative paradigms by capturing program structure without fixing an execution order or algorithm. Whether representing pure functions, logical constraints, or stream processors, a WD declares a network of relationships. The actual computation (evaluation, solving, data propagation) is something that happens when an interpretation is applied. This separation of concerns (specification vs execution) is a core idea in declarative programming. Spivak’s operad-of-WD approach thus provides a formal bridge between category theory and declarative programming models: it gives a precise language to talk about how pieces of a program are connected, which is exactly the level of abstraction at which declarative programmers prefer to work.

Wiring Diagrams for Program Representation: Literature and Applications

Since Spivak’s introduction of wiring diagrams as an operadic framework, there has been a growing body of research exploring how WDs can encode computational constructs and how they compare or integrate with other models of computation. Here we survey some key developments and applications:

• Visual and Dataflow Programming: The idea of representing programs as node-and-wire diagrams is not new in practice – tools like LabVIEW, Simulink, Scratch, and various dataflow languages have been popular for years. What Spivak’s work contributes is a rigorous semantics and algebraic framework for such diagrams. Researchers have begun leveraging WDs to formally reason about and implement visual programming models. For instance, wiring diagrams can serve as the backbone of visual dataflow frameworks by providing a clear compositional semantics: each node (box) is an operation and each wire is a data channel. Unlike ad-hoc visual languages, using WDs ensures that the composition of components is associative, has identity elements, and can be manipulated algebraically. There are now software libraries (in the spirit of Spivak’s approach) for constructing and executing wiring-diagram-based programs. One example is the AlgebraicJulia ecosystem (developed by Evan Patterson, James Fairbanks, and others), which includes Catlab.jl – a library for applied category theory that implements operads and wiring diagram structures. With such tools, one can encode a flowchart or dataflow diagram as a formal operad morphism and then execute or analyze it within Julia. This kind of research sits at the intersection of programming languages and category theory, and it holds promise for making correct-by-construction visual programming environments. The literature in this area often overlaps with applied category theory conferences (e.g., the Applied Category Theory proceedings) where papers demonstrate case studies like wiring-diagram representations of computational workflows, and how they can be transformed or optimized using algebraic laws.

• Dynamical Systems and State Machines: A significant application of WDs has been in modeling stateful systems such as automata or dynamical systems. We already mentioned that Schultz, Spivak, and Vasilakopoulou (2016) used directed wiring diagrams to compose Moore machines (finite state machines where output depends only on state) (Wiring diagrams for Mealy machines – Topos Institute). In their framework, each Moore machine is a box with a given state space and input/output types, and a wiring diagram composes these machines by connecting outputs to inputs (and implicitly, wiring the state transitions in a consistent way). This allows complex state machines to be built from simpler ones modularly. More recently, D’Angelo (2024) and others at Topos Institute have worked on dependent directed wiring diagrams to handle Mealy machines (where output can depend on both state and input) (Wiring diagrams for Mealy machines – Topos Institute) (Wiring diagrams for Mealy machines – Topos Institute). By enriching the wiring diagram operad to pass along global context (like a current state) to components, they can capture systems where the interconnection involves shared state. This line of research shows that WDs can express control flow and state sharing in programs: for example, an elevator controller was modeled as a Mealy machine via dependent wiring diagrams, illustrating how instantaneous input signals can affect outputs (Wiring diagrams for Mealy machines – Topos Institute) (Wiring diagrams for Mealy machines – Topos Institute). These works contribute to program representation by demonstrating that constructs like finite state machines, which are fundamental in programming (think of automata-based implementations, stateful loops, event-driven systems), can be composed and visualized with wiring diagrams. The advantage of using WDs here is that one can ensure consistency (no mismatched interfaces) and exploit algebraic properties (e.g., state composition might form a monoidal product) to simplify or analyze the composed system.

• Symmetric Monoidal Categories and String Diagrams: As mentioned earlier, symmetric monoidal categories (SMCs) underlie the string diagram formalism often used to reason about programs (particularly in quantum computing, concurrency, and circuit theory). Patterson, Spivak, and Vagner (2021) made the relationship explicit: they showed that wiring diagrams can serve as normal forms for computations in SMCs, meaning that any algebraic composition in a SMC has a unique representation as a WD () (). Their work bridges the gap between low-level algebraic expressions and high-level diagrams. One outcome of their research is that one can use WDs to compute with morphisms in a category – by manipulating diagrams instead of algebraic formulas. This has been applied to improve automated reasoning in proof assistants or computational category theory libraries, where representing a morphism as a wiring diagram (a certain data structure) can make checking equality or composing morphisms more efficient. The broader literature on this topic also compares WDs to other graphical calculi: for instance, hypergraph categories are another formalism where morphisms have multiple inputs/outputs and are depicted as diagrams (generalizing SMCs). It turns out that the operad of wiring diagrams for SMCs essentially captures the same information as hypergraph categories (). Thus, WDs provide a unifying framework that can embed Petri nets, circuits, and other graphical models known in computer science. Petri nets, for example, can be seen as a type of hypergraph where places and transitions form a bipartite graph; wiring diagrams could model a similar structure if we treat markings as tokens flowing along wires. Although Petri nets traditionally have their own theory (with tokens, firing rules, etc.), category theorists have shown they can be treated compositionally via operads or cospans. Spivak’s operad approach influenced some of these developments by offering an operadic viewpoint: e.g., there are operads whose algebras are Petri nets with certain interfaces (sometimes called “open Petri nets”). While a direct citation might be beyond scope, it’s worth noting that researchers like Baez, Courser, and Patterson have drawn parallels between wiring diagrams and Petri net formalisms in terms of compositional structure.

• Tensor Networks and Graphical Calculi: Another domain of interest is tensor networks – diagrams used in quantum computing and numerical linear algebra to represent compositions of multilinear maps (tensors). A tensor network is essentially a graph where nodes are tensors and edges indicate index contractions between tensors. This is strikingly similar to a wiring diagram: each tensor can be seen as a box with multiple “ports” (indices), and connecting an output of one tensor to an input of another means setting those indices equal and summing over them (contraction). Wiring diagrams, especially undirected ones, can capture the abstract structure of a tensor network (ignoring the numeric values). In fact, a symmetric monoidal category of finite-dimensional vector spaces has string diagrams that correspond to exactly such networks. Using wiring diagrams as a formal syntax could, in principle, allow one to reason about tensor networks compositionally or even manipulate them with software. Some literature in applied category theory touches on this (e.g., using hypergraph categories to represent signal-flow graphs, which are mathematically analogous to certain tensor networks). While Spivak’s own work did not explicitly address tensor calculus, the operadic framework is general enough that it could encode these when the algebra $H: \mathcal{W}\to \mathbf{Set}$ assigns to each interface a space of tensors of the appropriate shape, and to each wiring diagram the operation of contracting those tensors accordingly.

• Comparison to Other Formal Models: Wiring diagrams join a rich ecosystem of formal models for programs. Monoidal categories (and their string diagrams) we have discussed – they focus on compositions and tensor products, often assuming a fixed notion of sequential vs parallel composition. WDs generalize these by allowing typed connections and hierarchical nesting (operads allow an operation to contain sub-operations). Petri nets focus on concurrency and resource usage, providing a token semantics which WDs do not inherently have (WDs are more like the “skeleton” of connectivity, whereas Petri nets add a layer of token dynamics). However, frameworks exist to recast Petri nets as wiring-diagram-like structures: for example, by treating a Petri net transition as a box whose “wires” are the places (with multiple wires possibly meaning multiple tokens) – though one must incorporate an effect for token consumption/production. Cospan categories and graph rewriting approaches model open networks by gluing interfaces; they have been shown to be equivalent in power to the operad approach (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). The difference is mostly in presentation: cospans focus on connecting via pushouts in category theory, while operads like WDs focus on a term-like composition (substitution into placeholders). Researchers have established formal relationships proving these approaches coincide under certain conditions, meaning one can choose the framework that is more convenient. The wiring diagram operad tends to make duplication and deletion explicit, whereas cospans implicitly allow merging or forgetting connections (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth). This distinction can matter in programming language semantics: for instance, in a linear logic or resource-sensitive setting, you might restrict those structural operations – something easily stated in operad terms by removing those generators.

• Applied Case Studies: Beyond theoretical comparisons, various case studies have demonstrated the use of WDs in specific computational contexts. For example, Spivak and others applied wiring diagrams to robotics and planning by representing knowledge-based plans as operadic diagrams (one of the AlgebraicJulia publications deals with a “categorical representation language for planning” which is essentially a wiring-diagram style model). In biological computation and chemical reaction networks, wiring diagrams have been used to represent interactions and then apply compositional analysis (Baez et al. 2022 used stock-and-flow diagrams, a kind of wiring diagram, to model epidemiological processes (AlgebraicJulia)). In distributed systems and protocols, a wiring diagram can depict how different agents’ processes connect, and operad algebras can enforce communication semantics. The literature is expanding as the operad of WDs is a convenient lingua franca for many network-like systems. Each of these applications treats WDs as a way to encode a system’s structure (like a program or process graph), sometimes converting it into executable code or into mathematical analysis. For instance, a visual programming interface could let a user draw a wiring diagram, and behind the scenes, this is compiled (via a chosen operad algebra) into executable code (SQL queries, or a circuit netlist, or actual machine instructions calling functions in order).

In summary, existing research on WDs for program representation spans from highly theoretical work (showing WDs are normal forms in monoidal categories () ()) to very practical applications (using WDs to design and compose real systems like state machines (Wiring diagrams for Mealy machines – Topos Institute) or dataflow pipelines). WDs act as a unifying model that can capture aspects of other models (monoidal categories’ diagrams, Petri net structures, etc.), often providing a more flexible or algebraically convenient perspective. The consensus in recent literature is that wiring diagrams (and operads in general) are a powerful tool for structured, modular representation of programs and processes, especially when one wants to ensure compositionality and reuse. They bring the benefits of visual formalisms (intuitive and high-level) together with formal rigor (well-defined semantics and algebraic manipulations). As a result, we see WDs being employed in domains ranging from formal verification to domain-specific language design, essentially wherever one can identify a network of interacting parts that would benefit from a high-level schematic representation.

Toward a System for Modeling Programs with Wiring Diagrams

Given the solid theoretical foundation and growing body of research, one can envision developing a system (framework or language) for modeling actual programs using wiring diagrams. Such a system would allow programmers to design, analyze, and even execute programs in a wiring diagram form. To achieve this, several considerations and components come into play:

1. Theoretical Considerations: We must define how various programming constructs map into the wiring diagram paradigm. Simple function composition and dataflow is straightforward, but what about conditional branching, looping, or recursion? As discussed, WDs can represent conditionals by having a wiring structure that splits the flow (one input goes into two different computations and a selector chooses one output to pass on). Loops or recursive calls correspond to feedback wires. A modeling system would likely differentiate between acyclic diagrams (which correspond to straight-line, feed-forward computations) and diagrams with feedback (which correspond to loops or stateful behavior). This might mirror how programming languages handle recursion or loops via fixed-points or state. One theoretical approach is to use guarded or temporal operads: for example, a feedback loop in a flow of data might require a delay (as in a state update each time step). Indeed, Spivak’s temporal wiring diagrams include a notion of delay to handle feedback in a causal way ([1512.01602] Operads of Wiring Diagrams). A program modeling system might therefore incorporate a temporal or iterative extension to the basic WD operad to ensure well-defined semantics for loops (avoiding instantaneous self-dependency). Type systems are another consideration: WDs should have typed ports (e.g. an integer output can only connect to an integer input). The operad formalism already supports this by having many objects (each interface is essentially a type or tuple of types), so our system would need a clear type checking rule (which is inherent: a wire can only connect matching types). For more complex typing features (like polymorphism or higher-order wiring diagrams where a box could itself contain a subdiagram as data), richer categorical structures (operads enriched over type categories or higher operads) might be required, but those are active research areas.

2. Frameworks and Tools: On the practical side, implementing WDs for program modeling involves both a frontend (perhaps a visual or textual language to specify wiring diagrams) and a backend (an interpreter or compiler that maps the WD into executable semantics). There are already some tools from the ACT community. For example, Catlab.jl (a Julia library) provides a way to construct operads and their algebras programmatically; it has been used to define wiring diagram operads and instantiate them with specific algebras (like circuits or relations). A domain-specific language or GUI on top of such a library could let programmers draw diagrams and then simulate or execute them. Another example is the Topos Institute’s software, where researchers are building interactive diagram editors that ensure the drawn diagram is formally a morphism in an operad or category. One could also integrate WD modeling into existing languages: for instance, a Haskell or Python library that allows constructing a wiring diagram via code and then “running” it by providing an interpretation. Some early prototypes treat wiring diagrams akin to electronic circuits, where you can compile them into a lower-level language (like how hardware description languages compile block diagrams to logic gates). As a concrete illustration, one might create a visual programming environment where the user drags and drops blocks (functions, conditionals, etc.) and wires them. Under the hood, each block is an element of some operad algebra (maybe a snippet of code or a function object), and the wiring diagram is automatically translated to a composition of those blocks. The system could then either generate actual source code (e.g., generate a Python function that corresponds to the drawn diagram) or directly execute the diagram by following the operad algebra’s composition (essentially acting as an interpreter).

3. Challenges: Developing such a system is not without challenges. One fundamental challenge is handling state and side effects. Pure wiring diagrams excel at describing static compositions, but real programs often have stateful interactions, side effects (I/O, mutation), and non-determinism. Modeling these in a wiring diagram requires careful design of the semantic algebra. For instance, to model mutable state, one might include explicit state-carrying wires or boxes that represent reading/writing to state. This starts to resemble the dataflow models used in languages like Lustre or LabVIEW for stateful systems, where there are feedback loops and special delay nodes. Ensuring that side effects happen in the right order might require encoding a notion of sequence or using a monadic style interpretation (for example, treat the entire program as a single state-transformer box that wires through an implicit “world state”). Another challenge is scalability and readability. While wiring diagrams are great for high-level views, large programs could become unwieldy if fully expanded into a single diagram. Hierarchical design (the ability to collapse sub-diagrams into abstract boxes) is crucial – operads support this by nature (a sub-diagram can be considered a single box via the operad’s composition), but tool support is needed to allow zooming in and out of detail. There’s also the question of human factors: programmers are used to textual code, and while visual languages have their appeal, they can also be slower for certain tasks. A compromise might be a hybrid approach where the program is written in a high-level declarative language that is isomorphic to a wiring diagram, and one can toggle between the textual and graphical view. Ensuring the synchronization of these views and efficient editing is a software engineering challenge.

From a research perspective, another challenge and opportunity is to leverage the algebraic laws of the operad to optimize or verify programs. If two wiring diagrams are algebraically equivalent (via the axioms of the operad and possibly additional equations if the algebra has some), the system could automatically simplify the diagram or recognize a refactoring. For example, a wire that splits into two and then those two wires feed into a merging operation that just recombines them could be simplified out. These kinds of rewrites relate to classical compiler optimizations but at a diagrammatic level. Researchers in computational category theory have explored using rewrite rules on wiring diagrams as a form of equational reasoning or program optimization. One could incorporate a rewriting engine that ensures the diagram remains in a simplified or canonical form, thereby helping with efficiency or clarity.

4. Future Directions: The future of using WDs for program representation likely involves integrating with modern programming language features and paradigms. One direction is to incorporate concurrency explicitly: since WDs already look like concurrent models (multiple components operating in parallel, communicating via wires), extending the framework to reason about concurrent execution, synchronization, or even probabilistic behavior could be fruitful. Another direction is linking WDs with software architecture: at a higher level, one could use wiring diagrams to model the interaction of microservices or modules in a large software system, treating each service as a box and communication channels as wires. This becomes a blueprint of the system architecture, on top of which one can map actual implementations. Because operads allow nested diagrams, this could naturally represent a hierarchy of system -> subsystems -> components.

On the theoretical side, ongoing research is looking at polynomial functors and polynomial monads as a foundation for wiring diagrams (Spivak and collaborators have related WDs to polynomial functors, which capture the idea of “a bunch of inputs produce an output” in a type-theoretic way (Neural wiring diagrams for message passing in multiscale ...)). This could eventually lead to new type-safe programming languages where a program is literally a polynomial morphism – essentially a wiring diagram with dependent types.

Another exciting prospect is combining wiring diagrams with machine learning or synthesis. For instance, given a specification (also possibly in WD form), can an algorithm synthesize a wiring diagram (i.e., compose library components to meet the spec)? The algebraic structure might make this more tractable by providing clear composition rules and a search space structured by the operad.

In conclusion, developing a full-fledged system for modeling programs with WDs will require both theoretical insights (to handle advanced language features declaratively in the operadic framework) and practical engineering (to build user-friendly tools and efficient execution engines). The research so far provides a strong proof-of-concept that many forms of computation can be captured by wiring diagrams – from pure functions to state machines and beyond. As the field progresses, we expect to see more programming environments influenced by Spivak’s operad of WDs, especially in areas where correctness, compositionality, and clarity of design are paramount. Such a system would enable programmers to think in terms of modular, interconnected parts, using a high-level visual language underpinned by rigorous semantics, ultimately improving our ability to build and reason about complex software and systems.

Sources:

• Spivak, D.I. “The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits.” 2013. ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits) ([1305.0297] The operad of wiring diagrams: formalizing a graphical language for databases, recursion, and plug-and-play circuits)

• Rupel, D., & Spivak, D.I. “The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes.” 2013. ([1307.6894] The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes) ([1307.6894] The operad of temporal wiring diagrams: formalizing a graphical language for discrete-time processes)

• Patterson, E., Spivak, D.I., & Vagner, D. “Wiring diagrams as normal forms for computing in symmetric monoidal categories.” 2021 () ()

• Baez, J., & Fong, B. “Cospans, Wiring Diagrams, and the Behavioral Approach.” Azimuth blog. 2015 (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth) (Cospans, Wiring Diagrams, and the Behavioral Approach | Azimuth)

• Yau, D. “Operads of Wiring Diagrams.” 2018 (Lecture Notes in Math. 2192) ([1512.01602] Operads of Wiring Diagrams)

• D’Angelo, K. “Wiring diagrams for Mealy machines.” Topos Institute Blog, Aug 2024 (Wiring diagrams for Mealy machines – Topos Institute) (Wiring diagrams for Mealy machines – Topos Institute)

• Spivak, D.I. Talk: “Operads for Modular Design” (slides, 2015) () (A mathematical language for modular systems David I. Spivak Presented on 2015/01/29)

2-o1_explanation-for-python-developers.md

Key Idea: “Wiring Diagrams” as a Formal Way of Connecting Components

Imagine you have a collection of building blocks—functions, classes, or modules in Python—and you want to hook them together so the output of one block feeds into the input of another. A “wiring diagram” (WD) is a picture that shows how those blocks (like black boxes) are connected by wires that carry data from outputs to inputs.

• Example: If you have two Python functions

  def f(x):        # X -> Y
      return ...
  
  def g(y):        # Y -> Z
      return ...

  then a wiring diagram would visually show f feeding into g (the output of f is passed as input to g). It forms a composite process g(f(x)) from X to Z.

In David Spivak’s work, these wiring diagrams are treated as an operad. An operad is like a category but specialized for describing multi-input, single-output operations and how they nest inside each other. Instead of just “arrows” from one object to another, an operad has operations that can take multiple inputs (like multiple subcomponents) and produce one combined output.

So effectively, if you think of each “box” in a wiring diagram as a sub-function (or submodule), the WD as a whole is a bigger function that is composed of those sub-pieces. Spivak’s insight is that there’s a rigorous algebraic theory (“operads”) that captures exactly this “wiring” or “plug-and-play” style.

---

Why This Matters for Programming

1. Compositionality & Modularity:
   In Python, you often build functions from smaller functions—maybe you pass one function’s output into another, or chain them together in a pipeline. Wiring diagrams are a universal way to talk about that chaining. Each diagram says “which output goes where,” letting you assemble big systems from smaller pieces in a structured, visual way.

2. Declarative Dataflow:
   Instead of writing imperative code that says “call this function, store the result, then pass it to that function,” a wiring diagram just declares which connections are made. It’s like drawing a dataflow graph (something you might see in a library like Dask, Airflow, or even a neural-network library’s computation graph). You focus on what depends on what, and let an “operad algebra” handle the execution semantics.

3. Functions vs. Relations vs. State Machines:

   • If each box is a Python function, a WD describes how to compose them.
   • If each box is a relation (like a table or constraint), the WD can describe database-like joins or logical constraints.
   • If each box is a stateful process (like a discrete-time “step” function taking old state + inputs -> new state + outputs), then a WD can capture more dynamic programs with feedback loops.

   So it’s not tied to one style of computation—wiring diagrams are a “universal syntax” for hooking up some kind of components.

4. Looping & Feedback:
   If you literally draw a wire from an output of a box back to its own input, you represent a feedback loop or recursion. In Python, this could correspond to a recurrent function call or an iterative state update. Spivak’s “temporal wiring diagrams” are specifically for discrete-time processes—each “box” runs step-by-step, and you can handle loops safely without confusion.

5. Visual vs. Textual:
   You can think of a wiring diagram as a purely visual representation of program composition. But under the hood, it’s grounded in the math of operads, which ensures the diagram has a precise meaning. So you can store/handle these diagrams inside a program (e.g. in a JSON-like format describing connections), and compose them programmatically—just as you might do with ASTs (abstract syntax trees) in Python.

6. Duplication & Discarding:
   Wiring diagrams allow you to “fork” a single output into multiple inputs or to discard an input you don’t use. In normal code, that’s like writing:

   val = some_function(...)
   out1 = do_something(val)
   out2 = do_another_thing(val)

   The “fork” is happening behind the scenes by storing val in a variable and using it twice. In WD-speak, that’s an actual “split” node in the diagram. Being explicit about duplication/deletion at the diagram level can help reason about resource usage, concurrency, or partial evaluation.

---

Operads: The Algebraic Backbone

A bit more on “operads”:

• In everyday category theory, you have objects and arrows (morphisms). In an operad, instead of a single arrow ( A \to B ), you have an operation that takes a list of objects ((A_1, A_2, \dots, A_n)) and produces a single object (B). Composition means plugging the output of one operation into one “slot” of another operation.
• In wiring diagram form, each operation is literally drawn as a diagram with several sub-boxes.
• Once you fix an “interpretation” or “algebra” (e.g., interpret “a box labeled X -> Y” as a Python function type X -> Y), the resulting big diagram automatically corresponds to the composed function.

Basically, Spivak showed:

“Let’s treat the entire notion of connecting boxes by wires as a single mathematical object (an operad). Then all your usual ways of hooking up sub-systems follow standard algebraic rules.”

This ensures everything is consistent—no mismatch in the number of inputs/outputs, no confusion about nested connections, etc.

---

Links to Declarative Programming

A big theme is declarative or dataflow style:

• Declarative: You specify the structure (“output of A goes to input of B”) rather than detailing step-by-step commands.
• Dataflow: Many functional or logic-based frameworks (especially in Python’s scientific computing stack or pipeline tools) let you define how data flows between tasks or operators, and then they handle scheduling or computing.
• Logic/Database viewpoint: If each box is a “relation” or “table,” connecting outputs and inputs declares how tables share columns. Composition of those diagrams becomes a query plan.

So if you’ve used tools like pandas pipelines, Airflow DAGs, or Spark dataframes, you’ve seen the practical side of dataflow graphs. Wiring diagrams are a more mathematically precise version of those graphs.

---

Spivak’s Contributions

• He identified that these wiring diagrams can be treated as an operad, giving a general compositional rule set.
• He extended them to handle temporal (discrete-time) or stateful processes, not just static functions.
• He showed how you can interpret them in a broad range of ways: database queries, circuit diagrams, recursive functions, etc.
• He and collaborators have published on how to represent everything from finite state machines (Mealy/Moore machines) to feedback loops in a single “operadic” framework.

In short, Spivak helped unify the notion of “box-and-arrow diagrams” (common in engineering, dataflow, etc.) under a single powerful formalism that supports composition, hierarchical nesting, typed ports, duplication, and so on.

---

Why It Might Interest a Python Programmer

1. Algebraic Visualization of Code: You could imagine representing a Python program’s structure (especially if it’s mainly functional/dataflow) as a WD. It becomes easier to see how data is passed around, or to do transformations on the code base (like an optimizer or a partial evaluator) by rewriting diagrams.

2. Library Integration: Tools like Catlab.jl in Julia (and some in Python) let you define these operads programmatically. In principle, you could build a Python library that:

   • Lets you define function “boxes” with typed inputs/outputs,
   • Compose them with “wires,”
   • Execute or compile the resulting wiring diagram to normal Python code (or even to a graph-based runtime).

3. Parallelism / Concurrency: If you draw a WD with multiple separate branches, you know those computations can be done in parallel. A wiring diagram is effectively a concurrency-friendly representation. Python frameworks that do DAG-based scheduling (like Airflow, Luigi, dask, etc.) are basically using something akin to WDs behind the scenes. Spivak’s formal approach might give you an even more robust way to do that.

4. Constraint Solving and Logic Programming: By using WDs as relations, you can represent something akin to a Prolog program or a database query by hooking relations together. That’s a powerful, purely declarative style that might interest you if you do logic/constraint programming in Python.

5. State Machines and Event Loops: If you do a lot of asynchronous or stateful stuff, you can encode that as “boxes with memory” connected by wires. It can help you keep track of who sends data to whom, in a high-level but formal way.

---

In a Nutshell

• What: A “wiring diagram” is a high-level, box-and-wire visual representation of how sub-components compose.
• Operads: Provide the mathematical rules ensuring you can nest and wire components in a consistent, compositional fashion (like function composition but for multi-input, multi-output systems).
• Spivak’s Work: Showed that a lot of programming concepts (function composition, database queries, circuit design, recursion, concurrency) can be uniformly described using these wiring diagrams.
• Benefits to Programming: Declarative style, strong modularity, flexible composition for both pure and stateful code, potential for better tooling and visualization.

If you’re a Python programmer used to function chaining, dataflow DAGs, or pipeline abstractions, Spivak’s wiring diagrams give you a theoretical foundation for that kind of composition. It’s a step toward building languages and tools where you can safely and uniformly plug components together and reason about them at a high level, without losing mathematical rigor.

That’s the big picture of what the document is discussing.