Open Grasshopper for the first time and the honest reaction is: where is the code? There are no lines, no semicolons, no indentation. Just a white canvas, some coloured boxes, and wires you drag between them. It looks like a diagram a colleague sketched on a napkin. And yet a napkin does not compute a NURBS surface. So what, exactly, is doing the work?

The answer is the thing most tutorials skip past on the way to the pretty façade: a directed acyclic graph, evaluated in dependency order. That is the concept under every node-based tool you will ever touch — Grasshopper, Dynamo, n8n, ComfyUI, LabVIEW, Max/MSP. Learn the graph and you have learned all of them at once. Miss it, and you will spend years wiring boxes you cannot debug.

←TODAY: In 2026 the same node-and-wire paradigm that draws a parametric roof in Grasshopper now orchestrates LLM calls in n8n and image pipelines in ComfyUI — one idea, three industries. →3012: The offices whose logic still runs in Zurich-3012 are the ones who wrote their graph’s evaluation order down, not the ones who trusted a plugin to remember it. Fulcrum: A visual program is only “visual” on the surface; underneath it is a strict mathematical object, and that object is what survives.

What it is: Visual programming — visual scripting, node-based programming, dataflow programming — is a way of building a computation by connecting operations with wires instead of writing statements in a text file. Each box is a function: it takes inputs on the left, does one thing, and hands a result out on the right. A wire is not decoration; it is a declaration that this output feeds that input. String enough boxes together and you have not drawn a picture of a program — you have written the program. The picture is the source code. As the PAZ archive piece “Universal glue” puts it, the process itself becomes visible and editable in real time, with input parameters flowing in and output values flowing out, “in a circuit-like schema.”

Why it works: The elegance is not the boxes — it is the constraint on the wires. A valid Grasshopper canvas is a graph that is directed (wires have a direction, output→input) and acyclic (you cannot wire an output back into its own upstream, no feedback loops without an explicit timer). That single restriction — no cycles — is what makes the whole thing computable. Because there are no loops, the graph has a topological order: a sequence in which every box is evaluated only after all the boxes feeding it are done. Kahn’s algorithm (1962) finds that order in linear time. The engine sorts the graph once, walks it front to back, and every component fires exactly when its inputs are ready. That is why a change to one slider does not re-run the entire definition — only the boxes downstream of the edit are marked dirty and recomputed. Dependency, not sequence, is the organising principle. In text programming you spend real effort managing order of execution by hand; in a dataflow graph the order is derived from the wiring, for free. This is also why data trees exist: Grasshopper’s paths are how the DAG carries structured collections along its edges without collapsing them into a flat list. The AAD reference — Arturo Tedeschi’s Algorithms-Aided Design: Parametric Strategies using Grasshopper — spends its opening chapters on exactly this, because data trees are where beginners drown and where the graph’s logic actually lives.

Origins: The lineage is older than architecture’s use of it. Ivan Sutherland’s Sketchpad (1963) already treated a drawing as a network of constraints rather than dumb lines. Dataflow as a formal model came from Jack Dennis at MIT in the 1970s; LabVIEW brought it to instrumentation engineers in 1986; Max, by Miller Puckette at IRCAM, brought it to musicians the same decade. For the AEC industry the pivotal moment came when architect-programmer David Rutten released Grasshopper (then “Explicit History”) for Rhinoceros — the non-uniform rational B-spline (NURBS) modeller from Robert McNeel & Associates — integrated with Rhino since September 2007, the date the PAZ archive marks as the breakthrough. Rutten’s real contribution was not inventing dataflow; it was packaging it so that an architect could learn to program while developing a real project, not before it. That is the point the PAZ series “Diseño paramétrico y programación visual” keeps returning to: the value was making parametric thinking intelligible to non-specialists. Dynamo followed for Revit; today n8n wires business logic and ComfyUI wires diffusion models — the same acyclic graph, evaluated the same way, wearing different node libraries.

In practice: A Swiss studio reaches for the graph the moment a problem has more than one variable and more than one iteration — a façade panel that must adapt to a curved envelope, a stair whose riser count follows a floor-to-floor height, a daylight study across forty floor plates run through Ladybug Tools. The graph pays off because the intent stays legible. Six months later a different team member opens the canvas and can read the dependency chain: this slider drives that count drives that schedule. Contrast a black-box AI generation with no derivation — a beautiful guess you cannot defend in a structural review. Offices that have been through a plugin’s end-of-life report the same regret: not the ugly form, but the form whose logic died with the file format. So the Monday move is a discipline, not a download.

Atelier: For a Büro adopting visual scripting — or now wiring an AI step into an n8n flow beside it — the trap is the same one every ops team hits with no-code tools, the pattern the 2026 AppSheet-alternatives write-ups keep documenting: the honeymoon build works in an afternoon, then month six needs a branch the canvas can’t express cleanly and nobody can read the spaghetti. This Monday, set one rule for every shared definition: group and label each cluster of nodes by the question it answers (“panel count from area”, “sun hours per floor”), so the graph documents its own dependency chain. A named group is the cheapest structural review you will ever run.

Hack: See the canvas for what it actually is — a directed acyclic graph the engine sorts before it computes anything. Here is the whole evaluation model in five lines of Python: give it who-feeds-whom, and it hands back the exact order Grasshopper fires your components in.

from graphlib import TopologicalSorter
# edges: node -> the nodes it depends on (its inputs)
graph = {"panels": {"grid"}, "grid": {"srf"}, "count": {"panels"}, "srf": set()}
order = list(TopologicalSorter(graph).static_order())
print(order)   # ['srf', 'grid', 'panels', 'count'] — dependency order, not draw order

Change one input and only the nodes after it in that list need recomputing — that is the dirty-propagation your slider triggers, made explicit. Run it once and the mystery of “why did my whole definition not re-solve” dissolves. The picture was never the program; the ordering was.

So before you wire the next box: name your groups, and know your graph is acyclic. Draw the dependency, not the decoration — the file format will not survive you, but the logic will.

Sources & Further Reading

• PAZ context: Universal glue — parametric design as a generative process
• Reinforcing: Diseño paramétrico y programación visual — PAZ Kaffi