There are a bunch of comments saying "Why not just learn python or R?"
But as a programmer, I still use excel (actually open office now I'm on Linux full time) as a brainstorming numbers based scratch pad. Somthing about the infinite grid, auto fill, not having to figure out all the parts of a 2D array allow me to chase an idea in its initial stages.
Eventually, when I have a handle on the problem and all the variables involved I will switch to jupyter notebooks or something else.
I still think we as an industry are still missing the point of why are so many people using excel, especially in areas it shouldn't be used in. There is some hidden UI/UX point we're subtlely missing.
> I still think we as an industry are still missing the point of why are so many people using excel, especially in areas it shouldn't be used in. There is some hidden UI/UX point we're subtlely missing.
I think there's a kind-of necessary trade-off between flexibility and maintainability. And a similar trade-off between flexibility and robustness. Spreadsheets are flexible, but often not very maintainable, evolvable, or robust.
Ideally you would want a tool that allows you to move along the spreadsheet <-> statically typed language continuum without much pain. So when you finish the spreadsheet prototyping, you can kind of transform that into more robust and maintainable code. But that might have the same inherent short comings as trying to convert a prototype into a production product...
If my conjecture is true -- and I'm not at all sure it is -- then we're not missing a UI/UX point. We're just building tools for people with different priorities.
There is some hidden UI/UX point we're subtlely missing
It's not subtle, at all. Table layout is intuitive and Lua proves that tables can be a first class data type. Therefore, database normalization is important, and since it isn't enforced, easily messed up.
Spread sheets fundamentally hide the control flow, needed to grasp the normalization order of the table, in a second layer. That is a virtue, when the program is small enough, but a burden otherwise.
Comments
There are a bunch of comments saying "Why not just learn python or R?"
But as a programmer, I still use excel (actually open office now I'm on Linux full time) as a brainstorming numbers based scratch pad. Somthing about the infinite grid, auto fill, not having to figure out all the parts of a 2D array allow me to chase an idea in its initial stages.
Eventually, when I have a handle on the problem and all the variables involved I will switch to jupyter notebooks or something else.
I still think we as an industry are still missing the point of why are so many people using excel, especially in areas it shouldn't be used in. There is some hidden UI/UX point we're subtlely missing.
> I still think we as an industry are still missing the point of why are so many people using excel, especially in areas it shouldn't be used in. There is some hidden UI/UX point we're subtlely missing.
I think there's a kind-of necessary trade-off between flexibility and maintainability. And a similar trade-off between flexibility and robustness. Spreadsheets are flexible, but often not very maintainable, evolvable, or robust.
Ideally you would want a tool that allows you to move along the spreadsheet <-> statically typed language continuum without much pain. So when you finish the spreadsheet prototyping, you can kind of transform that into more robust and maintainable code. But that might have the same inherent short comings as trying to convert a prototype into a production product...
If my conjecture is true -- and I'm not at all sure it is -- then we're not missing a UI/UX point. We're just building tools for people with different priorities.
It's not subtle, at all. Table layout is intuitive and Lua proves that tables can be a first class data type. Therefore, database normalization is important, and since it isn't enforced, easily messed up.
Spread sheets fundamentally hide the control flow, needed to grasp the normalization order of the table, in a second layer. That is a virtue, when the program is small enough, but a burden otherwise.