This goes back to my old quip of the easiest way to increase GDP to 5% would be to force everyone to learn how to actually use Excel. HT "You Suck at Excel" - JS https://www.youtube.com/watch?v=0nbkaYsR94c
Agreed! But the trouble for me with Excel is that it has an incredibly low ceiling. There are so many people out there doing what is essentially app development but with terrible tools. Tools that give them the wrong habits and mental models for working at scale.
I would love to see the spreadsheet reinvented to be a) collaboration-oriented, and b) a good on-ramp to ever-growing programming skills. So that when Bob in the next department over makes that crucial internal spreadsheet, you can safely and usefully interact with it from your crucial internal spreadsheet. Basically, to make every spreadsheet a potential microservice.
I've spent some years failing to figure out how to make that work. So if anybody manages, please let me know.
I have thought about this myself too, so I'll offer my two cents: Spreadsheets are really versatile, but they're a victim of their own versatility. You need to build something that is similar enough that people understand the concepts, but different enough so that people don't get frustrated by the fact that it's not Excel/Google Docs.
I always envisioned something that functioned like a Jupyter notebook, and pulled some pages from the MatLab debugger tool ...kind of like how Light Table implemented them, but don't get too caught up in that analogy. That way, you could create and define tables that are stand alone objects, and run [code] operations on data in those objects to create new tables. Everything that is processed from the tables is it's own [new object] entity, and can be [output or not] viewed or hidden. It would move away from the idea of having few tabs of large continuous spreadsheets in favor of having many small tables [matrices] that would have identifiers [variable names]. And if the user really wanted, they could drag around tables on a spreadsheet like grid, but the data in those tables would not be editable in that view. Oh, and graphs are their own entity too. Users can use a GUI editor to make graphs, but the graph properties will be user accessible in some sort of markup language for the edge case where the user needs to make a ton of graphs, and then needs to make some styling change to every graph. Not something I've ever experienced though... \s
This will:
1. Reduce the need for Excel's reference gymnastics that are performed when you move or insert rows/columns in to referenced data.
2. reduce the headache that is excel formulas. Since each object will be a formula instead of every cell. Also, the formulas don't have to be a single line, so it will be more readable.
The trick is finding a good language to use - Julia maybe? and designing a good GUI for helping non programmers do useful things like accessing and referencing data from objects in an intuitive way. This could be where the traditional spreadsheet view could come in handy. I like how you mentioned that it needs to serve as a good on ramp for ever growing programming skills, because it needs to be intuitive enough that non programmers can understand the basics and accomplish something useful, but powerful and hackable enough that the mental models can transfer.
We're definitely thinking along the same lines. I agree entirely about many small spreadsheets and the like. Another inspiration for me here is the long-lost Lotus Improv, which instead of being a blank page was more like a table, with explicit, named rows and columns. For me a general principle is to look at what people mostly do with spreadsheets and make explicit support for that.
You're very right that choosing the right language is important. As much as I love the languages I know, most of them are incredibly fiddly. E.g., things like dealing with "if a=b" are fine for those of us steeped in the mysteries, but a nightmare for more casual users. I'll have to check Julia out. Thanks for mentioning it!
There was also something called "Framework" that went a bit farther than spreadsheets. Of course when I write Spreadsheet here I mean "Spreadsheet products available in the 80s": https://en.wikipedia.org/wiki/Framework_(office_suite)
If you haven't used it, Google Sheets is worth looking at closely. It's good for collaboration (within the boundaries of a "normal" spreadsheet interface), and has a lot of options for integrating with external systems
I have used it, and it's definitely a step in the right direction. But it lacks a lot for me, in that the meaning of the system somebody builds is implicit and contingent.
E.g., in an OO language, I can be very clear about what a MailingAddress is. I can say what makes it well-formed. I can give rules about how it can be changed, and what happens when it does change.
But in a spreadsheet, that concept is mostly implicit. A human can look at it and say, "Oh, the mailing address is columns C-G, starting at row 2 and down to just before the first blank line." Until somebody edits the spreadsheet and inserts a phone number column, anyhow.
That means a Google Sheet can't really serve as a reliable microservice that knows about all the customer addresses, letting one's colleague's sheets read and update things. Sheet authors have all the necessary domain knowledge, but not enough of the technical knowledge, so at some point they have to bring in a professional programmer to re-express the domain knowledge in a language inaccessible to the people who formerly had control over their data and business processes.
FWIW Google Sheets does have the ability to write macros in JavaScript. They even have an npm tool [0] that will let you edit offline via your preferred IDE and then push to your sheet.
I can imagine though, that there's a real chance that the "fear" of people having their jobs automated would cause them to cut back on spending, perhaps causing an immediate recession!
Funny enough, I had a class on this in grade school, taught by the school librarian. It included quoting, AND, NOT and OR style stuff you could use in library search systems and it is pretty much all irrelevant now, but it was cool at the time and I wonder if it helped to be exposed to that kind of boolean logic early.
Same, this was common in the late 70s and early 80s. Sure, you were on a mainframe terminal or a PC with a cd-rom, but the search principles are the same.
I was thinking more about the thought process for how to come up with the right words to begin with and for refinements to make to yield better results rather than the boolean operators although I think they are good for the young minds, too.
Funny you should mention this; we learned this in high school, 2 decades ago now. Quotes and OR and all. The task was to find some info on the teacher. It was in "computer science" class. Good fun.
