4 ms·

In my experience working in some "speadsheet heavy" businesses: - complecting 'data' and 'presentation of data' together - lack of tools to help with 'correct

by s_kilk 11y ago

In my experience working in some "speadsheet heavy" businesses: - complecting 'data' and 'presentation of data' together - lack of tools to help with 'correctness' - lack of version control - horrifying and error-prone programming model, both hard to write and hard to reason about. - spreadsheets full of pivots and charts rapidly become the 'truth' of a business, but without any checks and balances to ensure that what they show is actually true, leading to confusion and great badness.

harperlee 11y ago
I would add a couple of things: I'd like asserts / rules / invariants / constrains that alert me when they are no longer valid. Everyone implements this with conditional formatting to get them red. Related, I don't like having three coding spaces: the cell value, the format formula, and possibly vba. Also, the whole book/sheet/cell hierarchy is very limited. Complex formatting is complicated when a simple fix would do: just let me compose views of several sheets, so I can put tables side-by-side without the need for them to be aligned, break when I add columns to one table, etc. Support for tree-like structures is done typically by merging parent cells to span more. Just support trees as an alternative to tables! If the layout on point 3 would exist, this would be beautiful. A structure would be book/object-set-layout/cell, where objects can be: a tree, a table, etc. Formatting is part of an object and can be more easily templated, code is referenced, not created, in the objects, and is all apart - vba style. ResolverOne had this last one right. Having all code apart would mean easier version control, and easier separation of logic/presentation/data. Lastly, you could link objects from separate locations and authorization, and have a federated data model. But now I'm just overarchitecting :).
noxToken 11y ago
> horrifying and error-prone programming model, both hard to write and hard to reason about. I don't remember where I read this, but I heard that the basic Office Suite (Word, Excel, PowerPoint) is written with office workers in mind first. That is, Word isn't written for authors, Excel isn't written for database managers/big data specialists, and PowerPoint isn't written for motivational speakers. I think the idea of the basic Office Suite is that a user could grasp the basic functionality of the software without having to undergo any training. Second to that, tools and other functionality for those with specific needs (e.g. pseudo-database functionality, basic data visualization in Excel) could use the software where the project was small enough. Excel was given great programming features without a proper programming language to support it. This isn't to say that these programs are not feature packed or bad. They're kitchen sinks that want to make everyone happy.
- collyw 11y ago
  The problem is that they are too easy to use. As such Excel gets used for everything data related. Access would be a far better choice in many of the cases I have seen, but it just doesn't make any sense unless you have had some sort of introductory course on databases.

by s_kilk 11y ago

harperlee 11y ago

I would add a couple of things: I'd like asserts / rules / invariants / constrains that alert me when they are no longer valid. Everyone implements this with conditional formatting to get them red. Related, I don't like having three coding spaces: the cell value, the format formula, and possibly vba. Also, the whole book/sheet/cell hierarchy is very limited. Complex formatting is complicated when a simple fix would do: just let me compose views of several sheets, so I can put tables side-by-side without the need for them to be aligned, break when I add columns to one table, etc. Support for tree-like structures is done typically by merging parent cells to span more. Just support trees as an alternative to tables! If the layout on point 3 would exist, this would be beautiful. A structure would be book/object-set-layout/cell, where objects can be: a tree, a table, etc. Formatting is part of an object and can be more easily templated, code is referenced, not created, in the objects, and is all apart - vba style. ResolverOne had this last one right. Having all code apart would mean easier version control, and easier separation of logic/presentation/data. Lastly, you could link objects from separate locations and authorization, and have a federated data model. But now I'm just overarchitecting :).

noxToken 11y ago

> horrifying and error-prone programming model, both hard to write and hard to reason about. I don't remember where I read this, but I heard that the basic Office Suite (Word, Excel, PowerPoint) is written with office workers in mind first. That is, Word isn't written for authors, Excel isn't written for database managers/big data specialists, and PowerPoint isn't written for motivational speakers. I think the idea of the basic Office Suite is that a user could grasp the basic functionality of the software without having to undergo any training. Second to that, tools and other functionality for those with specific needs (e.g. pseudo-database functionality, basic data visualization in Excel) could use the software where the project was small enough. Excel was given great programming features without a proper programming language to support it. This isn't to say that these programs are not feature packed or bad. They're kitchen sinks that want to make everyone happy.

collyw 11y ago
The problem is that they are too easy to use. As such Excel gets used for everything data related. Access would be a far better choice in many of the cases I have seen, but it just doesn't make any sense unless you have had some sort of introductory course on databases.