> I don't think you get it. They can just click around and see all of the numbers and all of the formulas. It's code and a UI.
I'm glad you apparently agree with my statements like "Their user-facing side is a particular form of livecode oriented around "sheets"/2D arrays of data tightly connected with reactive code -- which definitely has some legibility advantages," though that agreement does make it a bit strange to lead with "I don't think you get it."
> Everybody knows it's code
When someone enters the statement "Auditors understand and can check through Excel but they don't understand code" into the discussion -- or in other words saying that an Excel spreadsheet is not code (along with asserting that's why auditors can understand it) -- apparently not everyone does know this and so it's reasonable to reassert that a spreadsheet is made of code.
> people can flip through and check the calculations themselves if they like.
If, as in any other interpreter, they understand the spreadsheet code that's being interpreted and take the time to follow what it's doing. And that's one reason why the observation that spreadsheets are code can be helpful. The distinctive visual presentation and model of spreadsheets is a legibility convenience for sure, but it can also lull people into believing they're working with something less complex than code. It helps people keep in mind that what the spreadsheet appears to be doing may different from what it's actually doing, either because the complexity has pushed it beyond casual legibility (a common problem in all kinds of code), or perhaps because someone intentionally is using the full power of an interpreted functional reactive programming language (to say nothing of VBA macros) to intentionally hide some aspect of the spreadsheet's operations. It helps people keep in mind that whatever margin of accessibility Excel's affordances provide, it still requires some of the same kind of work to audit it that other forms of code would.
I'm glad you apparently agree with my statements like "Their user-facing side is a particular form of livecode oriented around "sheets"/2D arrays of data tightly connected with reactive code -- which definitely has some legibility advantages," though that agreement does make it a bit strange to lead with "I don't think you get it."
> Everybody knows it's code
When someone enters the statement "Auditors understand and can check through Excel but they don't understand code" into the discussion -- or in other words saying that an Excel spreadsheet is not code (along with asserting that's why auditors can understand it) -- apparently not everyone does know this and so it's reasonable to reassert that a spreadsheet is made of code.
> people can flip through and check the calculations themselves if they like.
If, as in any other interpreter, they understand the spreadsheet code that's being interpreted and take the time to follow what it's doing. And that's one reason why the observation that spreadsheets are code can be helpful. The distinctive visual presentation and model of spreadsheets is a legibility convenience for sure, but it can also lull people into believing they're working with something less complex than code. It helps people keep in mind that what the spreadsheet appears to be doing may different from what it's actually doing, either because the complexity has pushed it beyond casual legibility (a common problem in all kinds of code), or perhaps because someone intentionally is using the full power of an interpreted functional reactive programming language (to say nothing of VBA macros) to intentionally hide some aspect of the spreadsheet's operations. It helps people keep in mind that whatever margin of accessibility Excel's affordances provide, it still requires some of the same kind of work to audit it that other forms of code would.