Explaining Functional Programming to Non-Programmers (It's Just Excel) · cekrem.github.ioA few days ago someone at work asked me what I actually do. Not my job title — they had that — but what functional programming is. I started in on the usual mumble about pure functions and immutability, watched their eyes begin the slow slide toward the exit, and then they rescued both of us with a guess:<br>“Functional programming… does that mean you write the code yourself, instead of having Claude do it? Is that the thing?”<br>Well, yes. But also no; that has nothing to do with it really.<br>And later that day I saw a feature inside the client’s document management software where you could click a button to sync the document’s metadata title/subtitle with what was actually visible within that document. I tried to explain that in a more functional paradigm, the title within the document would be calculated based on the metadata rather than having a procedure mutate it in place .<br>Didn’t quite succeed with that explanation, I think, though it’s more helpful than the Claude question.<br>But I’ve been asked some version of this enough times now that I’ve at least stopped reaching for monads and category theory, which is roughly like answering “what’s a car?” by opening the hood. But let’s do better. Lo and behold, I’ve discovered a tool that every non-technical person I work with understands better than I do. Most of them could run circles around me in it. They probably have it open right now.<br>“You already know functional programming. You’ve just been calling it Excel. ”<br>The man who built Haskell agrees
Link to heading<br>Simon Peyton Jones — one of the principal designers of Haskell, the language that functional programmers light candles to — has said it plainly. In an oral-history interview he describes spending years on Excel “because it is the world’s most widely used functional programming language.”<br>He’d know. Back in 2003 he co-wrote a paper at Microsoft Research with the unglamorous title A User-Centred Approach to Functions in Excel (ICFP ‘03, if you want the PDF — it’s a good read). The whole premise is that the spreadsheet is already a functional language, used daily by hundreds of millions of people who would never describe themselves as programmers and would be mildly offended if you did.<br>Microsoft eventually leaned all the way into it. When they shipped the LAMBDA function in late 2020, the research team — Andy Gordon and, yes, Peyton Jones again — noted that the Excel formula language had become Turing-complete. You can now, in principle, compute anything in it. They called these “functional programming features,” in the same breath as calling Excel “the world’s most widely used programming language.” Felienne Hermans, a researcher who has spent a career studying spreadsheets, gave a whole talk titled “Pure Functional Programming in Excel”. (Bloomberg reckons Excel has somewhere on the order of a billion users. Haskell, last I checked, does not.)<br>So when I tell a non-programmer “you already do this,” I’m not being nice. I’m being literal. Here’s the proof, in three parts.<br>One: every cell is a little function
Link to heading<br>Click on a cell. Either someone typed a value straight into it — 1337, a name, a date — or there’s a formula, something like =A1+B1.<br>That formula does exactly one thing. It looks at A1, looks at B1, hands you back the sum. That’s it. It doesn’t matter what time of day you open the sheet, who’s logged in, or which cells you happened to click first. Same inputs, same answer, every single time. And if you ever wonder where a number came from, you click it and the formula bar tells you, all of it, no secrets. The grid never lies.<br>That property has an intimidating name — “referential transparency” — and a very simple meaning: a cell’s value depends only on what you can see flowing into it, and nothing else. There is no hidden “it depends.” This is the first thing functional programmers chase, and most of us spend our careers trying to make ordinary code behave as honestly as a column of =A1+B1.<br>Two: no cell reaches across the grid
Link to heading<br>Cell C1 cannot reach over and change A1.<br>A formula computes its own value out of other cells. It never mutates them. There is simply no way to write something in B7 that means “give me the total, and also, while you’re in there, set A1 to zero and bump C4 by three.” Causation points one direction only: a cell sits downstream of the cells it reads, never upstream. No cell reaches across the grid and meddles with another.<br>Compare that to how most software is written. In an ordinary program, almost any line can change almost any value, anywhere, at any time. Some function buried four files...