There is a quiet revolution hiding in plain sight on millions of desktops around the world. It lives in the humble spreadsheet cell—a rectangle so commonplace that we rarely stop to consider just how remarkable it truly is.
A spreadsheet cell is magical. Not in the sense of parlor tricks or illusions, but in the deeper sense of something that accomplishes the seemingly impossible with effortless grace. The cell combines input, output, computation, and storage into a single unified object, eliminating entire categories of work that plague conventional software development.
To understand why this matters, consider how a typical IT system is constructed. You have a GUI library to display and enter data. You have a programming language—COBOL, dBase, Java, or countless others—to perform calculations. And you have some storage mechanism, a database or filesystem, to persist your data across sessions.
These are three separate kingdoms, each with its own customs, languages, and expectations. And it falls to the programmer to build bridges between them. Data must be shuttled from the database into memory structures the programming language can manipulate. Those structures must then be translated into forms the GUI can display. When the user edits something, the process reverses: GUI events must be captured, transformed back into program data, validated, computed upon, and finally persisted to storage.
This bridge-building code—this glue—constitutes the majority of code written in the world. It adds no business value. It implements no novel algorithm. It merely adapts, transforms, and copies data from one layer to another. It is the bureaucratic paperwork of software development: necessary, tedious, and prone to error.
The spreadsheet cell abolishes this bureaucracy through a radical act of unification. The cell is the input field. The cell is the display. The cell is the computation engine. The cell is the storage. There are no layers to bridge because there is only one thing: the cell itself.
When you type a number into a cell, you are simultaneously entering data, displaying it, storing it, and making it available for computation. When you type a formula, you are writing a program that executes immediately, displays its result in the same location where you wrote it, and persists automatically. The traditional boundaries between user interface, business logic, and data storage simply dissolve.
This is why spreadsheets are so phenomenally productive. All that glue code—the code that programmers spend most of their careers writing—simply goes away. The spreadsheet user doesn’t need to think about data binding, or serialization, or event handling, or state management. They just work with cells.
Here is a fact that should give every software developer pause: spreadsheets are, by any reasonable measure, the world’s most popular programming language. There are over a billion Microsoft Office users worldwide, and a substantial fraction of them write formulas in Excel. Google Sheets adds hundreds of millions more. The total number of people who have written =SUM(A1:A10) dwarfs the population of developers who have ever written a line of Python, JavaScript, or Java.
These spreadsheet users are programming. They are writing expressions, defining dependencies, building computational models. They are doing it productively, often without realizing they are programming at all. The spreadsheet has democratized computation in a way that no traditional programming language has ever achieved.
And yet—and here is the puzzle—the insights that make spreadsheets so successful have been remarkably slow to trickle down to the second, third, and fourth most popular programming languages. Python does not work like a spreadsheet. Neither does JavaScript, nor Java, nor C++. These languages still demand that programmers manually shuttle data between layers, still require explicit event handling for reactivity, still maintain the rigid separation between data and computation that spreadsheets so elegantly dissolve.
Why? The benefits are obvious. The productivity gains are proven by decades of spreadsheet use. Yet mainstream programming languages have largely ignored the lesson, continuing to burden developers with glue code and ceremony that spreadsheet users have never had to endure.
There is another subtle magic at work in spreadsheets: the transparency of computation. If I reference cell B13, I have no idea whether B13 contains a static value or a computed formula. Nor do I need to know. The cell presents a uniform interface regardless of what lies beneath.
Contrast this with traditional programming languages, where the distinction between data and computation is fundamental and inescapable. Accessing a variable—a—is syntactically and semantically different from calling a function—f(). The programmer must always know which is which. This distinction leaks into APIs, into documentation, into the mental model required to understand any piece of code.
The spreadsheet’s uniform access model means that implementation details stay hidden. A cell that today contains a static value can tomorrow contain a formula, and nothing that references it needs to change. This is referential transparency made tangible, accessible to anyone who can click on a cell.
Perhaps the most impressive magic is the spreadsheet’s reactive computation model. When you change a cell, every cell that depends on it automatically recomputes. Change the tax rate in B1, and every tax calculation throughout the entire spreadsheet updates instantly. This happens without callbacks, without event listeners, without observer patterns, without any of the ceremonial complexity that reactive programming typically demands.
In traditional software, achieving this kind of automatic propagation requires elaborate infrastructure. You must define events, register listeners, manage subscription lifecycles, handle circular dependencies, and debug mysterious sequences of callbacks firing in unexpected orders. It is a mess—error-prone, difficult to understand, and a fertile source of bugs.
The spreadsheet simply does it. Dependency tracking is automatic. Propagation is automatic. The user never thinks about it, and yet it works, reliably, every time.
For all their magic, spreadsheets have a significant limitation: they confine us to a two-dimensional grid of cells. This structure works beautifully for many problems but becomes awkward or impossible for others. Complex data relationships, hierarchical structures, and rich domain models strain against the grid’s constraints.
This is where FOAM enters the picture. FOAM attempts to capture the essential magic of spreadsheet cells—the elimination of glue code, the reactive computation, the unified model—but without the confines of a two-dimensional grid. More importantly, FOAM aims to address the curious failure of mainstream programming languages to learn from the spreadsheet’s success.
Where spreadsheets achieve their magic through cells, FOAM achieves it through FObjects. An FObject is not a cell; it does not try to be everything at once. But the effect is the same: no glue code is required to view or edit FObjects, to store them in any number of underlying storage mechanisms, or to have them compute dynamic values.
FObject properties can be defined as expressions, which work precisely like spreadsheet formulas. They can reference other properties, and when those dependencies change, the expressions automatically recompute—all without callbacks or event listeners. The reactive magic of the spreadsheet, liberated from the grid and brought into a general-purpose programming context.
The ultimate benefit of both spreadsheets and FOAM is the same: they let you concentrate on what you’re trying to accomplish. The accountant building a financial model in a spreadsheet thinks about revenue projections and cost structures, not about data binding frameworks. The developer building an application with FOAM thinks about domain models and business rules, not about shuttling data between layers.
This is what the elimination of glue code truly means. It is not just about writing less code, though that is certainly welcome. It is about removing cognitive burden, about clearing away the underbrush so you can see the forest. It is about spending your time on the problem you’re trying to solve rather than on the incidental complexity of the tools you’re using to solve it.
The spreadsheet cell discovered this magic decades ago and has been quietly revolutionizing how ordinary people work with data ever since. It became the world’s most popular programming environment not through marketing or mandate, but because it made hard things easy. FOAM carries this magic forward into a more general and powerful format, extending the spreadsheet’s gift to professional software development—finally bringing to traditional programming languages the lessons that a billion spreadsheet users learned long ago.
The cell is magical. And that magic, properly understood and properly generalized, points the way toward a better kind of programming—one where the work that matters gets done, and the work that doesn’t simply disappears.