Data Flow

Data flow is the movement, transformation, and consumption of data through a system — the path that information takes from its source, through intermediate processing stages, to its destination. Where control flow asks 'what happens next,' data flow asks 'what moves where, and how does it change along the way.' In the narrow sense, data flow is the subject of compiler analysis: tracking how values propagate through variables, expressions, and memory locations. In the broad sense, data flow is the defining characteristic of reactive systems, stream processors, signal-processing pipelines, and any system whose behavior is driven by the availability of data rather than by a sequential program counter.

Data Flow in Compilation

A compiler's data flow analysis is the static determination of facts about how data moves through a program at runtime. The compiler constructs a control flow graph and propagates information along its edges: which definitions reach which uses (reaching definitions), which variables are live at which points (liveness analysis), which expressions are available for common subexpression elimination (available expressions). These analyses are the foundation of modern compiler optimization. Without them, the compiler cannot know whether a value computed in one basic block is still valid in another, or whether a store to memory can be safely elided because the stored value is never read.

The most profound data-flow transformation in compiler design is the conversion to Static Single Assignment (SSA) form, in which each variable is assigned exactly once. SSA makes data flow explicit: the flow of each value is represented by a direct edge in the SSA graph, and the convergence of values from different control-flow paths is represented by φ-functions. In SSA form, the program is no longer a sequence of instructions that happen to manipulate data; it is a graph of data dependencies that happens to be scheduled into a sequence. This inversion — data first, control second — is the compiler writer's secret weapon. It reveals optimization opportunities that are invisible in the imperative view.

Data flow analysis is also the basis for alias analysis (do two pointers refer to the same memory?), escape analysis (does a reference escape its allocating scope?), and type inference in polymorphic languages. Each of these is a data-flow problem dressed in different clothing: information propagates through a graph until it reaches a fixed point, and the fixed point is the answer.

Data Flow as Systems Architecture

Beyond compilation, data flow is an architectural paradigm. In a dataflow architecture, computation is triggered by the arrival of data rather than by the ticking of a program counter. The canonical example is the spreadsheet: cells contain formulas, and when a cell's input changes, the change propagates through the dependency graph, recomputing every dependent cell. The spreadsheet is a dataflow machine disguised as a grid of cells. Its users are doing dataflow programming without knowing the term.

Modern reactive systems extend this principle. Stream processing frameworks like Apache Flink and Kafka Streams model computation as directed graphs of operators, each consuming data from upstream operators and producing data for downstream ones. Backpressure — the mechanism by which a slow consumer signals its upstream producers to slow down — is a data-flow phenomenon: it is the propagation of capacity information in the reverse direction of data flow. The system self-regulates not through a central controller but through the structure of the flow itself.

Signal-processing pipelines, hardware description languages, and functional reactive programming (FRP) all share this data-first architecture. The common pattern is that the program is not a recipe for producing output but a description of how output depends on input — a declarative graph that an execution engine can schedule, parallelize, or distribute however it sees fit.

The Tension with Control Flow

Data flow and control flow are not alternatives; they are dual descriptions of the same computation. Every program has both a control-flow graph and a data-flow graph, and the two graphs encode different information. The control-flow graph captures the order of operations; the data-flow graph captures the dependencies between values. A program can be control-flow dominated (imperative code with complex branching) or data-flow dominated (matrix operations with regular memory access patterns), and the optimal execution strategy depends on which graph is denser.

This duality is the source of the perennial tension between imperative and declarative programming. Imperative languages optimize for control flow: they give the programmer fine-grained control over the order of operations, at the cost of obscuring data dependencies. Declarative languages optimize for data flow: they make dependencies explicit, at the cost of ceding control over execution order to the runtime. The debate between the two paradigms is not about aesthetics; it is about which graph should be primary and which should be derived.

The rise of GPU computing and tensor-processing hardware has shifted the balance toward data flow. These architectures are designed for regular, data-parallel workloads where the control flow is trivial (every thread executes the same instruction) and the data flow is complex (each thread reads and writes different memory locations). The compiler's job on these machines is not to optimize control flow but to map data-flow graphs onto physical memory hierarchies. The program counter, that ancient locus of sequentiality, becomes a mere formality.

The history of computing is the history of a gradual shift from control-flow primacy to data-flow primacy. We began with Turing machines, where control was everything and data was a passive tape. We moved to von Neumann architectures, where control and data shared a bus. Now we are entering an era of dataflow accelerators, reactive systems, and differentiable programming, where the data-flow graph is the primary artifact and the control-flow graph is an implementation detail. The program of the future will not be a sequence of instructions. It will be a graph of differentiable, reactive, stream-processing operators — and the compiler's job will be to find a control schedule that respects the data dependencies, not the other way around.