Can Programming Be Liberated from the von Neumann Style?
The father of Fortran, the first widely used programming language, used his Turing Award lecture to question everything he had built.
Backus argued that conventional programming languages were prisoners of the von Neumann architecture — one instruction at a time, one word at a time — and that this "word-at-a-time bottleneck" infected not just performance but the way programmers think.
He proposed functional programming as the escape route.
The paper is remarkable as an act of intellectual honesty: the man who defined an era of programming stood up and said the paradigm was wrong.
For anyone in product or technology leadership, it is a masterclass in the discipline of questioning your own most successful work.
Central argument
Backus argues that conventional imperative languages — Fortran included, his own creation — are fundamentally crippled by their architectural dependency on the von Neumann machine: they process state one word at a time through a bottleneck between CPU and memory, and this physical constraint has been mistakenly absorbed into the conceptual structure of programming itself. The result is code built around assignment statements and mutable state, which Backus calls 'the von Neumann style' — a paradigm that makes programs hard to reason about, hard to verify, and hard to parallelise. His proposed alternative, functional programming based on algebraic combination of functions, treats programs as mathematical objects that can be manipulated, proved correct, and composed without side effects.
Critique
Backus's critique is structurally compelling but his proposed solution — FP, his specific applicative system — never gained traction, which raises a question the paper cannot answer: whether the von Neumann style persists because of institutional inertia and tooling lock-in, or because it genuinely maps better onto how humans reason about sequential, stateful processes. The paper also underestimates how much of programming's difficulty is accidental complexity in problem domains rather than a consequence of the paradigm itself — replacing assignment with function composition does not dissolve the complexity of business logic, distributed systems, or human ambiguity in requirements. Decades of functional programming's partial adoption suggest the binary framing of 'liberated vs. imprisoned' may obscure a more pragmatic truth: most paradigms are tools with different fitness landscapes, not ideological positions to be won.
Why it matters for product
Backus's core move — publicly dismantling the paradigm he himself built at the height of its dominance — is the most practically instructive thing in the paper for a product leader: the discipline of distinguishing between 'this is successful' and 'this is right' is exactly what separates product strategy from product inertia. The 'word-at-a-time bottleneck' has a direct organisational analogue in how many product teams are structured around ticket-by-ticket delivery, where local optimisation of individual features substitutes for systemic thinking about how the product composes as a whole. If your team's planning process cannot reason about the product as a system of interacting capabilities — only about isolated increments — you have imported the von Neumann architecture into your roadmap.