[gruseom]

Even "no variables" and "no state" are arguably untrue. The state of a spreadsheet consists of the values sitting in its cells. You mutate them by editing them.

One FP attribute that spreadsheets do have is referential transparency: the same inputs given to the same formula will always produce the same result.

[qu4z-2]

But it only recomputes them when you edit them. It's like changing the source code of the program and rerunning it.

  let x = 3, y = 5 in
    x + y

No (mutable) variables there, but if I change the y = 3 bit to y = 4, the value of the expression changes. That's what it's like in excel, as well.

[gruseom]

I was wondering if someone would point that out! That's why I hedged with "arguably". :)

You're right, of course. But it depends on how you draw the boundaries of the system. If you think of the numbers in your example as code, then the program is stateless, and each time you change a number you get a new program. But if you think of them as parameters that live outside the code, then the edit-recompute cycle is a state change. In a similar if trivial way, if you take (say) a Java program running over a database and decide that the data in the database is "code", that "program" (consisting of Java code plus database) is now "stateless" too, and anyone who updates a database record is changing the "program".

Given that "stateful" vs. "stateless" depends on how you draw the boundaries of the system, the question is how best to draw the boundaries of a spreadsheet. I'm not arguing there's a single correct way to do that, but in my view the user's mental model of a spreadsheet is closer to "a calculating machine with state that I can update" than it is to "a stateless calculating machine with a lot of hard-coded literals".

Psychologically, updating the numbers in a spreadsheet doesn't feel like editing the source code of a program and re-running it. It feels stateful, like mutating something that triggers a cascade of side effects (recalculation). For this reason I think that spreadsheets are closer to the Smalltalk vision of a world of objects that respond to user interaction (as well as to each other) than they are to the functional programming vision of pure code. Put differently, the spreadsheet's I/O, its grid UI, is part of its essence. You can't abstract away from that without losing the heart of the thing. So the analogy with functional programming, though tempting, leads in the wrong direction. Every individual formula that lives in a cell is certainly a functional program when taken in isolation—but the memory model by which the cells reference one another and get updated is stateful.