Reactive Programming¶
A programming paradigm that declares dependencies among changing values or events and lets an execution model propagate their effects to derived computations.
Core Idea¶
Reactive programming expresses computations as relations among values or events that change over time, while a language or runtime manages how changes affect derived computations. A programmer declares a relation such as total = price * quantity; if price changes, the execution model knows that total depends on it and arranges evaluation of the relevant derived value. The crucial distinction from an ordinary one-time assignment is that the relation remains live rather than leaving the programmer to issue each downstream update manually. Bainomugisha and colleagues identify time-varying values and automatic dependency management as the paradigm's center and explicitly use spreadsheet formulas as an analogy.[1]
The paradigm does not prescribe one graph representation, one event-stream API, or one scheduling strategy. A system may push changes to dependents, pull an updated result when demanded, or combine both; these are implementation choices. Nor does the name promise that every intermediate state is glitch-free. In push-based propagation, a dependent may temporarily combine a new input with a stale derived input unless the implementation orders updates appropriately; the surveyed distributed approaches did not generally assure global glitch avoidance. The stable core is a declared dependency plus managed propagation, not a particular perfection guarantee.[1]
Structural Signature¶
Sig role-phrases: changing source → declared dependent computation → automatic propagation semantics → observable derived state.
- Changing source. A cell, time-varying behavior or discrete event can change and thereby affect computations that refer to it. The source need not be a particular stream class; the dependency must have an input that can vary.[1][2][3]
- Declared dependent computation. A formula, expression or composed behavior specifies how an output depends on sources or other derived values. It persists as a relation rather than being a single past assignment followed by handwritten update calls.[1][2][3]
- Automatic propagation semantics. The execution model tracks or otherwise honors that dependency, deciding when and how affected computations are re-evaluated. Push, pull and hybrid evaluation can all serve this role; explicit materialization of a graph is a common technique, not a universal requirement.[1]
- Observable derived state. A formula result, display or animation makes the propagated relation visible at an observation point. The observed value can be delayed or temporarily inconsistent under some implementations, so quality claims must state the relevant scheduling and consistency contract.[1][2]
What It Is Not¶
It is not every system that reacts to an event. A button callback that manually assigns a new value to every downstream field responds to a change, but it has not delegated a declared dependency among derived values to a reactive execution model. Similarly, a generic device called “reactive” may have no programming-language/dataflow model at all. The admission test asks who owns propagation of the relation, not whether some output eventually changes.[1]
It is not identical to Functional Reactive Programming (FRP). Elliott and Hudak's Fran models interactive animation with composable behaviors and events and a functional interpretation; the survey treats Fran and its relatives as an important family within a wider landscape of reactive approaches. A spreadsheet calculation model has the broad dependency-and-propagation pattern without becoming Fran or adopting functional behavior/event combinators. The existing catalog's FRP node is therefore a narrower neighbor, not a duplicate or proposed parent of this broad node.[1][3][2]
It is not necessarily push-driven or universally glitch-free. Push, pull and mixed evaluation are distinct choices. The survey treats glitch avoidance as a comparison axis and notes that globally avoiding mixed old/new observations in distributed reactive programs was not assured by its surveyed techniques. A single-machine implementation may arrange dependencies to prevent a particular glitch without establishing a universal guarantee for all reactive systems.[1]
It is not an assertion that every spreadsheet workbook immediately recalculates. Microsoft's own Excel documentation distinguishes automatic mode, where formulas recalculate after changes, from manual mode, where the user requests recalculation. Both may retain formula dependencies, but the automatic spreadsheet example below specifically assumes automatic calculation mode.[2]
Scope of Application¶
In spreadsheets, a cell formula refers to other cells, and the calculation engine tracks precedents and dependents. Excel's automatic mode recalculates affected formulas when an input changes; its manual mode can defer actual recalculation. This is a concrete dependency-driven setting with cell values as sources and formula results as derived state. Microsoft's implementation also maintains a calculation chain, but that particular structure is not the definition of reactive programming.[1][2]
In interactive animation, Fran composes time-varying behaviors and discrete events. The author-hosted Elliott–Hudak abstract identifies those as the primitives of Functional Reactive Animation. Bainomugisha and colleagues reproduce a Fran example in which left/right mouse-button events switch a color behavior, and a circle image that depends on the behavior updates when its color changes. This is a genuinely different medium from spreadsheet cells, while remaining a narrower functional-reactive instance of the broad paradigm.[3][1]
Other uses may include user interfaces and distributed event-driven applications, but application topic alone is not evidence of the paradigm. A positive case must declare and manage dependencies; the precise update timing, error behavior and consistency semantics need separate inspection.[1]
Clarity¶
The term “reactive” has two levels. A reactive system may simply respond to its environment; reactive programming says how a programmer expresses relationships and how an execution model propagates their changes. The contrast resolves why event-handler code is not automatically an instance, and why an Excel formula in automatic mode can illustrate the paradigm despite lacking a fashionable stream-library API.[1][2]
It also separates a steady relation from an observation guarantee. If c = a + b is live and changes in a propagate to c, the program is reactive in the broad sense. A transient c computed from fresh a but stale intermediate b is a glitch under a particular evaluation order. Avoiding that transient view is a design property to establish, not part of the minimal identity. The survey's own three-variable example demonstrates this distinction.[1]
Manages Complexity¶
In a network of dependent computations, manual event handlers must decide which values to update and in what order whenever an input changes. Declared dependencies transfer that bookkeeping to the execution model. The programmer works with relations; the implementation determines affected computations and a push/pull/hybrid evaluation schedule. Microsoft documents that Excel tracks precedents and dependents to limit recalculation rather than recomputing every formula on every edit in its smart recalculation process.[1][2]
The complexity has moved, not vanished. Dynamic dependencies, cycles, recomputation costs and inconsistent intermediate states still require semantics and engineering. A dependency graph may be built, maintained and topologically scheduled, but other approaches differ; the survey explicitly compares evaluation, lifting, glitch avoidance and distribution as separate axes. Calling all implementations “automatically consistent” would hide precisely the problems this abstraction helps expose.[1]
Abstract Reasoning¶
To test an instance, identify a changing source, a dependent expression/behavior and the observable result. Then change the source and ask whether the system—not manually replicated assignment code—manages the dependency's effect on the result. This is stronger than seeing an event handler run. Next ask whether evaluation is pushed at change time or pulled at observation, and which states an observer can see during propagation.[1]
For a spreadsheet, verify automatic calculation is enabled before claiming immediate formula refresh; Microsoft's manual mode changes the timing without erasing cell references. For an FRP animation, identify the button event, the color behavior and the dependent image; do not infer that its functional primitives are necessary in every other reactive language. For a distributed implementation, demand a specific consistency contract rather than importing single-machine glitch avoidance by analogy.[2][1][3]
Knowledge Transfer¶
The declared-source/dependent-result pattern transfers literally inside computing from a cell formula to a composed animation behavior. What does not transfer unchanged is the representation: one system stores cell references and a calculation chain, another composes first-class behaviors and events. Nor do their update-timing or consistency contracts transfer automatically. The broad abstraction makes these implementations comparable without asserting they are one API.[1][2][3]
“Changing input causes downstream change” may recur outside programming, but without program expressions and execution semantics it is only an analogy or a candidate broader future-prime question. The named identity remains domain-specific. Live Programming Paradigm supplies the actual strict genus; no speculative prime is needed to make the DAG look connected.
Examples¶
Spreadsheet formula in automatic mode¶
Consider an Excel workbook in automatic calculation mode with input cell A1 and formula cell B1 = 2*A1. Changing A1 marks dependent formulas for recalculation; Excel's engine tracks formula precedents/dependents and calculates the affected formula result. The small two-cell formula is a constructed illustration of Microsoft's documented mechanism, not a quotation from its workbook. If the workbook instead uses manual calculation, the formula relation persists but the observed value can wait until recalculation is requested.[2][1]
Mapped back: Changing source → A1; declared dependent computation → B1 = 2*A1; automatic propagation semantics → Excel's automatic-mode dependency tracking and recalculation; observable derived state → updated B1 value.
Fran circle color behavior¶
The Bainomugisha survey's Fran example starts with a red circle. A left-button event switches a colour behavior to green; a right-button event switches it to red. The circle image is composed with that behavior, so a new color value updates the image without a separate imperative assignment to the rendered circle on each event. The example is grounded in a functional-reactive lineage documented by Elliott and Hudak, not a claim that all reactive programs use Fran's stepper or button-event operators.[1][3]
Mapped back: Changing source → left/right mouse-button events; declared dependent computation → switched color behavior and circle image depending on it; automatic propagation semantics → Fran's behavior/event composition carries the new color to the image; observable derived state → rendered circle colored red or green after the relevant event.
Structural Tensions¶
T1: Prompt propagation versus demand-sensitive work. Push evaluation can make a changed result available promptly, but may recompute dependents nobody observes and requires care about intermediate ordering. Pull evaluation may avoid unused work by waiting for a demand, but can defer the visible update and move work to observation time. Hybrid designs combine costs and benefits rather than dissolving the choice. Diagnostic: Are changes more frequent than observations, and what latency or wasted work is acceptable?[1]
T2: Distributed responsiveness versus consistent joint observation. Letting related computations reside on different hosts supports distributed interaction, yet message delays, failures and no shared clock complicate any claim that all observers see one coherent update. Stronger ordering/synchronization can cost responsiveness or availability. The survey specifically says its then-current distributed techniques did not assure global glitch avoidance; that historical evidence is not an assertion that every future distributed system must fail. Diagnostic: At what observation boundary, and under which communication assumptions, is a no-mixed-old/new guarantee actually established?[1]
Structural–Framed Character¶
Reactive Programming sits near the structural end, but within a constitutive programming-language frame. Evaluative weight: reducing manual update bookkeeping is a motivation, not evidence that every reactive program is faster, easier or glitch-free. Human-practice dependence: programmers choose which dependencies to declare and when outputs matter, but propagation semantics are part of the computational model, not a social convention. Institutional origin: Fran, Excel and survey taxonomies document realizations; no institution's label alone confers membership. Vocabulary travel: “reactive” occurs in control systems, chemistry and ordinary event handling; only a declared computational dependency with managed propagation matches this node. Import versus recognition: a new language/library must actually own change propagation for dependent computations; describing any callback-driven program as reactive does not establish that behavior.[1][2][3]
Its character: a reusable computational structure with several implementation styles, but domain-specific because programmed expressions, changing values/events and execution-model propagation are constitutive. A generic propagation-of-change metaphor remains a future-prime question, not this entry's type.
Structural Core vs. Domain Accent¶
The core is a changing source, a declared dependent computation, runtime/language-managed propagation and an observable result. Spreadsheet cells and recalculation chains, or Fran behaviors and interactive images, are domain realizations of that core. Push versus pull, explicit graph materialization, first-class event streams, lifting syntax and glitch-avoidance guarantees are important variant properties, not universally required membership roles.[1][2][3]
The portable skeleton “dependency change propagates to dependents” might warrant a future cross-domain prime, but it is explicitly a future-prime question here. Live Programming Paradigm is the defensible upward node: it encompasses coherent computational entities, composition and execution semantics, while reactive programming restricts those to time-varying declared dependencies. The semantic boundary, not the word “reactive,” supports the proposed edge.
Instantiates / Related Primes¶
This entry is a kind of Programming Paradigm. Dependency-driven reactive composition and execution are a particular programming paradigm.
Relationships to Other Abstractions¶
Current abstraction Reactive Programming Domain-specific
Parents (1) — more general patterns this builds on
-
Reactive Programming is a kind of Programming Paradigm Domain-specific
Dependency-driven reactive composition and execution are a particular programming paradigm.The child organizes changing computational values/events, declared dependent computations, and automatic propagation semantics across spreadsheet and language/library implementations. This entails the live Programming Paradigm genus's computational entities, composition/control model and reasoning constraints, while adding reactive restrictions.
Hierarchy path (1) — routes to 1 parentless root
- Reactive Programming → Programming Paradigm
Neighborhood in Abstraction Space¶
Reactive Programming sits in a sparse region of the domain-specific corpus (71st percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Cognitive & Behavioral Theories (16 abstractions)
Nearest neighbors
- Dynamic Problem — 0.85
- Stream Abstract Data Type — 0.84
- Efficient cause — 0.83
- Rematerialization — 0.83
- Program Transformation — 0.83
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
- Generic event-driven callbacks: a response to an event can be hand-coded without any declared dependency or automatic propagation.[1]
- Functional Reactive Programming: a narrower functional formulation with behaviors/events, not the entirety of reactive programming.[1][3]
- A universal glitch-free guarantee: glitch avoidance varies by implementation and was especially unsettled for distributed approaches in the surveyed literature.[1]
- Immediate recalculation in every spreadsheet: Excel manual mode defers formula evaluation even though dependency information persists.[2]
- The calculation chain itself: an Excel implementation structure, not a required representation of all reactive programs.[2][1]
References¶
[1] Engineer Bainomugisha, Andoni Lombide Carreton, Tom Van Cutsem, Stijn Mostinckx and Wolfgang De Meuter, “A Survey on Reactive Programming”, author-hosted technical-report preprint (2012), §§1–4, especially definition on PDF pp. 2–3, glitch discussion pp. 5–6 and Fran circle example pp. 12–13. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y ↩z ↩27 ↩28 ↩29
[2] Microsoft, “Excel performance—Improving calculation performance”, “The importance of calculation speed,” “Full calculation and recalculation dependencies,” and “Calculation process”; original platform documentation. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o
[3] Conal Elliott and Paul Hudak, “Functional Reactive Animation”, ICFP (1997), author-hosted abstract; the linked full PDF's text extraction was unusable, so detailed circle-code claims above are grounded in the directly inspected survey by Bainomugisha et al. (2012). registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j