[TheZenPsycho]

Another point to make is that the "Excel is functional" meme is so useful is because, as soon as you tell most programmers that "functional programming" has no variables, no state, and no side-effects, they can't imagine how it's possible to actually do anything useful in a functional language. On the other hand, most programmers do know how to do useful things in a spreadsheet program- which happens to be effectively equivalent to a stateless side-effect free "pure" functional programming language.

[ww520]

That's kind of false advertisement. Excel (or spreadsheet in general) is great and easy to use because of declarative programming, not because of functional programming. The functional programming aspect of it is minimal. No variables, no state, and no side-effects are mainly attribute of declarative programming.

The most important aspect of being functional, high order function, is completely missing.

[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.

[erichocean]

From Wikipedia[0]:

Common declarative languages include those of database query languages (e.g., SQL, XQuery), regular expressions, logic programming, and functional programming.

I guess you're both right then. :)

[0] http://en.wikipedia.org/wiki/Declarative_programming