I'd be curious to know: does your friend make much use of names in Excel (i.e. assigning names to ranges and then using the names as variables in formulas)? and does she write VB code to do things that can't be done in cells?
The analogy to FP is striking, but not quite that complete. Excel doesn't let you define functions (i.e. it doesn't let you lay out formulas in cells and then call them repeatedly with different data) or types (i.e. it doesn't let you make multiple instances of a common model). It has variables, but the naming mechanism is primitive and not well integrated, so most people just work with raw cell addresses. And it arguably does have mutable data, because you can change what's in any cell at any time. I say "arguably" because one can argue the opposite: a spreadsheet defines one big pure function and if you change a cell then you're really just calling that function with a different input or changing the definition of the function. But I don't think anybody "feels" (or, for that matter, implements) spreadsheets that way. The cell contents feel like state and editing them feels like altering a machine as it runs.
To some extent it's a matter of how you frame it. If one expanded the identity of, say, a Haskell program to include both its code as it changes over time in the editor and the data that it gets applied to over time, it would seem mutable. No one looks at a Haskell program that way because we draw sharp lines between editing it, compiling it, and running it. But in spreadsheets those lines don't really exist. The program, the data it's applied to, and the editor are all together and the whole thing is live.
You define your own functions with IF/ELSE and the like and then replicate that function by dragging it to other cells I suppose. So that is kind of an anonymous function that you map to a vector of data.
So instead of mutable data, lets call it side effects: There are certainly no side effects. One sheet defines a complete set of data that does not change at run time and nothing besides that sheet determines the outcome of the calculation.
Funny enough, she immediately understood the concept of mutable data and claimed that she is not thinking about her Excel sheets as mutable -- she is mostly doing data analysis and reports, so she considers her inputs very much immutable.
Well, the analogy is not perfect. But the similarity is striking.
Although the thread is old I want to add something:
"There are certainly no side effects. One sheet defines a complete set of data that does not change at run time"
-- this is not true. Just changing an input somewhere (and triggering any related recalc) counts as a side effect. Your view requires "freezing" the spreadsheet at a given point in time. This is misleading, because spreadsheets are so interactive. Even your friend, who doesn't change the inputs after entering them, still has to enter them in the first place. There are a whole lot of side effects happening while she does that.
The Achilles' heel of pure functional programming, I/O, is not a problem for spreadsheets, which are a kind of REPL. Their way of doing I/O is highly specialized (you can edit a cell but reading from a file is not so easy). But that's fine: the fact that spreadsheets aren't general-purpose computing environments is part of their strength.
It's a mistake to look at spreadsheets qua programming language without taking the UI into account, and once you do take it into account, the FP analogy breaks down. In my view, a more reliable way to understand spreadsheets is as belonging to the class of interactive computing environments populated by Lisp, Smalltalk, APL, and Forth.
I use Excel a ton and do quite a bit VBA programming in my workbooks. I don't know what I'd do without names. I cant recall the last time I used a raw cell address. It is a nightmare trying to keep track of the ranges and gets exponentially worse when you have a multisheet workbook that has many references to cells on other sheets.
What's the maximum number of named ranges you've used in a spreadsheet? Don't you find the interface for defining names, or viewing them, inconvenient? It's completely divorced from the rest of the program IIRC.
The analogy to FP is striking, but not quite that complete. Excel doesn't let you define functions (i.e. it doesn't let you lay out formulas in cells and then call them repeatedly with different data) or types (i.e. it doesn't let you make multiple instances of a common model). It has variables, but the naming mechanism is primitive and not well integrated, so most people just work with raw cell addresses. And it arguably does have mutable data, because you can change what's in any cell at any time. I say "arguably" because one can argue the opposite: a spreadsheet defines one big pure function and if you change a cell then you're really just calling that function with a different input or changing the definition of the function. But I don't think anybody "feels" (or, for that matter, implements) spreadsheets that way. The cell contents feel like state and editing them feels like altering a machine as it runs.
To some extent it's a matter of how you frame it. If one expanded the identity of, say, a Haskell program to include both its code as it changes over time in the editor and the data that it gets applied to over time, it would seem mutable. No one looks at a Haskell program that way because we draw sharp lines between editing it, compiling it, and running it. But in spreadsheets those lines don't really exist. The program, the data it's applied to, and the editor are all together and the whole thing is live.