Skipping OOP: A 3D Editor Built on Spreadsheet Cells

The piece opens with the familiar arc of a programmer's education: from procedural code to object-oriented design, then into patterns like MVC, DI, and Observer. Each pattern solved a real problem, the author argues, but also added another layer of indirection between what a program does and what its code says. In large codebases behavior ends up scattered across a runtime-only dependency graph, and while AI has made tracing that graph cheaper, it hasn't made designing good architecture any easier — that remains a craft.

With this in mind, the author describes building a 3D mesh editor meant to grow for years (clipping, stitching, simplification operations, undo/redo, parameter UI) and deliberately rejecting the classic object decomposition (Mesh, Scene, Operation, Command classes). Instead, the design returns to the most primitive mental model of programming: a process is a set of programs, and a program is a table of named cells with explicitly declared dependencies. Cells hold either plain values or computed results, and computed cells split into formulas (which produce values) and actions (effects that run geometry mutations when triggered by the user).

This model deliberately echoes Excel and node-based tools like Grasshopper, with the author calling Excel the most successful reactive programming environment ever built. The same pattern, he notes, appears in complex manufacturing (PLM/PDM systems used to build things like rockets), where no single person holds the whole product in their head — instead, programs with declared inputs and outputs are linked by a digital thread.

A concrete C++ example — the mesh 'clip' operation — shows each input (mesh references, plane origin, rotation, epsilon) declared as a named cell. This same cell table auto-generates the UI panel, drives serialization, and feeds a uniform transaction-based undo/redo system across the whole editor, without any individual operation needing to implement it.