Liveness in Programming

Bret Victor does not like to write code. "It sounds weird," he says. "When I want to make a thing, especially when I want to create something in software, there's this initial layer of disgust that I have to push through, where I'm not manipulating the thing that I want to make, I'm writing a bunch of text into a text editor."¹

This disgust is the engine of one of the most important critiques in computing. Victor's principle — "Creators need an immediate connection to what they're creating" — sounds obvious, but its implications are radical. If you take it seriously, it suggests that the way we've been making software since the late 1950s is fundamentally broken. We write code in text files, compile or interpret it, observe the results, and iterate. The gap between writing the code and seeing the behavior is the gap where bugs live, where misunderstandings fester, where the programmer's mental model diverges from the machine's actual state.

The WYSIWYG Analogy

The Immediate Feedback article covers Victor's principle and demos in depth; here I want to focus on where the idea leads when pushed to its logical conclusions.

Victor draws an analogy to word processing. Before WYSIWYG, formatting a document meant writing control codes — invisible instructions that you could only see the effects of after printing. You had to play computer in your head, imagining how the codes would be interpreted. Then WYSIWYG came along, and suddenly the document on screen was the document. Italics tilted right there. Margins dragged in real-time. The control of a sophisticated system was made accessible to anyone who could click around on a page.

Victor's claim is that programming itself should work like this. The code and its behavior should be visible simultaneously, and changing one should instantly update the other. His most famous demo showed a Mario-like game on one side of the screen and its code on the other. Change a number controlling gravity, and Mario floats. Change the player's speed, and Mario races. But the real trick was mapping time to space: hitting a button showed not just where Mario was now, but where he would be at every moment in the future — a curve of shadow Marios stretching into the distance, reactive to parameter changes. The audience gasped. They knew they were looking at the future of their industry.¹

The Ladder of Abstraction

Victor's "Ladder of Abstraction" essay develops this into a design methodology.² The central idea: understanding a system requires moving fluidly between levels of abstraction. At the bottom, you see a concrete instance — one run of a simulation, one execution of an algorithm. At the top, you see the space of all possible runs, abstracted over time, parameters, and input data.

The technique works by progressively abstracting over variables. First, control time — instead of watching in real-time, scrub through the simulation with a slider. Then abstract over time — show the entire trajectory at once, not just the current state. Then control parameters — interactively adjust the algorithm's behavior. Then abstract over parameters — overlay trajectories for many parameter values to reveal high-level patterns. The deepest insights come not at any single level, but in the transitions between them: step up to see a pattern, step down to explain it.

This isn't just a nice visualization technique. It's an argument about how humans think. We can't hold complex dynamic behavior in our heads as text. We need to see it, manipulate it, explore it. Victor's frustration is that programmers have been content to work in the dark — staring at text, playing computer in their heads — when we have the technology to illuminate the behavior directly.

Dynamicland: Computing in Physical Space

Victor eventually became frustrated that people interpreted his work as being about programming tools when he was really interested in how people see and understand systems. He founded Dynamicland, a research lab in Oakland that reimagines computing as a communal, physical activity.³

In Dynamicland, programs live on sheets of paper. Cameras scan the room, detect the pages, read the code printed on them, and project their output back onto the table. Moving a page moves the program. Placing two pages next to each other can make their programs interact. Omar Rizwan's Geokit project illustrates the concept: a set of paper cards that, when laid on a table, display maps. Place the "transit routes" card on the map, and bus routes appear. Turn a physical dial, and the map zooms. A real estate developer visiting the space used Geokit without instruction to discover a gap in bus route coverage she'd never noticed in years of working with the data.

The key properties that make this work are what Ink & Switch calls embodiment (manipulating something tangible, not icons on a screen), living systems (seeing the effects of changes immediately, in the real world), and in-place toolchains (the tools for modifying the system are the system itself). These properties are strikingly absent from conventional programming, where the code is text in a file, the output is somewhere else entirely, and the tools for modifying the program are an entirely separate stack of software.⁴

End-User Programming's Broken Promise

The vision of end-user programming — that all computer users could reach in and modify their applications — is forty years old and has been forty years from realization the entire time.⁴ Its history is studded with genuine successes: Unix pipes, spreadsheets, HyperCard, HTML. And the successes share a common pattern: they let people manipulate live data in a domain they understand, with feedback loops tight enough that trial-and-error works.

Spreadsheets are the most successful programming environment ever built — over a billion users — and they embody liveness perfectly. You type a formula, and the result appears instantly. Change a cell, and every dependent cell updates. The program is the data, visible and manipulable in the same interface. This is Victor's principle incarnated, and it works because the domain (tables of numbers) is concrete enough that the abstraction gap between intent and mechanism almost vanishes.

But spreadsheets also illustrate the limits. They don't compose well. They don't scale. The code (formulas) is scattered across cells, making it nearly impossible to understand a large spreadsheet as a whole. And they provide no abstraction mechanisms — no functions, no modules, no way to build reusable components. Every successful end-user programming system has hit similar walls.

Modern attempts — Zapier, Coda, Airtable, iOS Shortcuts — try different tradeoffs. Zapier chains together API calls with minimal programming. Coda adds calculations and automation to documents. But none has achieved the breakthrough that would make programming truly accessible, because the hard problem isn't making code easier to write — it's making systems easier to understand. And understanding requires the kind of interactive exploration that Victor has been advocating for over a decade.

The Programmer's Resistance

Jack Rusher's Strange Loop talk "Stop Writing Dead Programs" makes the cultural argument.⁵ Most programmers write code in text editors, compile it, run it, observe the results, kill it, and start over. This edit-compile-run loop is the defining rhythm of modern software development. But it's also insane, if you think about it. The program is "dead" most of the time — it exists as inert text that has no connection to the running system. When it's alive, the programmer can barely interact with it.

Contrast this with Immediate Feedback systems like Smalltalk, where the program is always running and the development tools are part of the running system. Or Lisp, where you can redefine functions in a running process. Or Erlang, which can hot-reload code on running nodes. These systems make the program alive — it's never just text, always a running process that you can inspect, modify, and extend.

The resistance to liveness in mainstream programming is partly technical (live systems are harder to build) and partly cultural. Programmers are used to text. They're comfortable with the abstraction gap. They've internalised the edit-compile-run cycle so deeply that alternatives feel disorienting. But as systems grow more complex — as 100 million lines of code control our cars, our planes, our financial systems — the gap between the code and its behavior becomes increasingly dangerous. The Software Correctness At Scale problem is, in many ways, a liveness problem: we can't keep complex systems correct because we can't see what they're doing.