One of the big ideas I see circulated around this community is the power of spreadsheets. I've used spreadsheets for keeping track of some numbers, but I haven't used spreadsheets in any serious capacity. I have maybe a small sense of what makes spreadsheets compelling, but I suspect I'm missing some things. I'm curious if there are any "canonical" articles out there that describe the core ideas about spreadsheets and their relevance for the future of coding. If not, I'm curious how members of this community came about these ideas, and what we would say those ideas are.

Without being technical, it's important to understand the social role. There is a certain class of people for whom their entire professional life revolves around Excel, Outlook, and to a lesser degree Word. Excel is their outlining, calculating, charting, and programming environment. People have told me that, from their business's perspective, Excel is Microsoft's primary product with Windows as the Excel delivery mechanism.

Since I’ve been building a commercial “future of coding” style platform, I’ve formed a few opinions on this. IMHO apart from all the declarative formula based stuff its important to realize one really powerful thing about spreadsheets - they let people just get going inputting data in a free form fashion. There is really no cognitive burden around app design, screen building, metadata notions, any of that stuff. The problem of course is that as a result it is difficult to take the spreadsheet to the next level. Therefore the spreadsheet stays at that limited but very valuable use case - initial data entry, lightweight compute, and some level of collaborative information curation and syndication.

And cleaning them up is difficult. Excel for instance has a lot of mostly hidden state above the level of individual formulas. So you end up with weird path dependencies where the way you build the sheet so far affects what will happen when you introduce new rows and columns.

See https://www.miramontes.com/writing/spreadsheet-eup/

What @Vijay Chakravarthy says about spreadsheets also applies to the "computational notebooks" (Jupyter etc.) that are becoming very popular in computational science and data science. For both tool families, the initial barrier to becoming productive is low, but there is no support for managing the evolution (and in particular growth) of the software artefact. Which has as a net result the establishment of bad practices. The lesson for FoC projects, in particular in the category of "end-user programming" (much as I dislike that term) is that such systems need to consider growth paths from the start. Which means pointing out the limits of a particular interface early on, and facilitating the migration to more complex but also more powerful tools.

The solve (or at least I’m hoping is the solve) we have undertaken is to build our system in such a way that the onboarding toolset is itself an app built using our system. And that it facilitates a seamless move into more powerful tooling.

On a similar note to what @Vijay Chakravarthy mentioned, I think their appeal also comes in the form of the "progressive disclosure of complexity": that is, for a user who just wants to use the tool to manipulate data (without even using formulas, ranges, etc), it's possible to do so very easily, but for the advanced user who wants to create macros, pivot tables, and even full-fledged GUI construction (if we're talking about Excel and VBA), the tool offers little to no "resistance". What's so intriguing is that it does this in a nearly "modeless" way (or at least the modes that do exist are relegated to a few relatively transient contexts): that is to say, there's no explicit "beginner mode" or "advanced mode" in Excel, it's all just there, out in the open. Another notable principle is that the abstractions that exist in the app aren't particularly "leaky" (unless we're talking about pivot tables, or the things that @wtaysom mentioned, in which case, oh boy, haha), but this is certainly not the primary draw.

Two resources: 1. Bonnie Nardi's "A Small Matter of Programming" is largely a case-study of spreadsheets and CAD systems, which Nardi identifies as the two most successful (by far) end-user programming systems. 2. @stevekrouse started a nice Twitter thread about this: https://twitter.com/stevekrouse/status/1076979937440161793.

I think there are some experiments you could repro and find how spreadsheets can be objectively 10-100x+ better programming UI experience than traditional linear documents for certain use cases. First there's nothing you can do in a spreadsheet language that you can't do in a linear language, and vice versa, in terms of functionality. The only difference is in terms of User Experience, and the time it takes to build things in one environment vs the other. A very common operation is to work with tables of data. Making easily parseable tables of data is dead simple in Excel, very difficult in linear langs. In the latter you have really primitive tools for filling, selection, etc. It is easy to misalign things. You don't get good secondary notations (conditional highlighting in excel, for example), which can be great visual aids. And you often have to insert noisy delimiters like commas, and worry about escapes. You are definitely talking about on the order of at least a 10x speed up in user time to do these kinds of things, and more realistically on the order of 100x. Not just for tables, though. The information density of spreadsheets can be really high (you can arrange your programs into tiles, tabs, kanban boards, gantt charts, etc, not just a single linear sequence of token). Massively more combinatorics to make a visual DSL that fits your problem domain better. I could go on. But those 2 UX advantages, one in table manipulation and one in the visual arrangement of a project, alone hint at some pretty big non-linear differences in spreadsheet programming paradigms vs text editor paradigms. Things that can be numerically and objectively measured and have orders of magnitude differences, and are not matters of opinion.

@Breck Yunits Sorry, this is OT, but I can’t help it and need to know: how did you manage to screw up your post with all these additional line breaks?

Does it not look like this to you? I generally write in an editor and copy/paste

this is how it looks

I read it on mobile and it looked even worse with my font size settings, mostly single words every second line. Anyway, I was mostly curious about some Slack thing I didn’t know about, but you explained it and I totally get why you’d want an external editor instead of Slack's built-in abomination of system controls (might want to update your editor to the 21st century — we have automatic line breaks now ;). Well, don’t want to derail this thread further. Thanks for explaining! To bring this back on topic: Spreadsheets were invented at a time where there wasn’t such a huge distinction between users and developers, and it shows. Today we seem to focus so tightly on specific use cases that most apps offer extremely specific and therefore limited workflows and deviating just a little from what's been envisioned by the developer is either impossible or extremely annoying at best. Back then, use cases were much broader and more open-ended and offered much more latitude for users to try out different things. Perhaps because tech was much more limited back then; perhaps because developers trusted users to be much more technical back then. Bottom line: I think we need more tools that leave room for end users to discover the use cases they need for themselves. Developers are seldom user domain experts and that’s where a lot of the friction comes from. Precisely why I think the future of programming will be determined by end users and not today's developers.

I really like Dan Bricklin's TED talk: https://www.ted.com/talks/dan_bricklin_meet_the_inventor_of_the_electronic_spreadsheet#t-413373 I started playing around with Excel at a very young age. Like others have said already, it's really easy to get started. Just point somewhere and enter some text or numbers. You can then gently discover more and more functionality just by searching through the menus and lists of formulas. By the age of 14, I knew more about Excel than my IT teacher in school. Excel is an environment in which you can discover new things and try if they do what you want. I was able to learn about much of Excel's functionality without using external sources. I didn't need to use google often and didn't even know what stackoverflow was at that time. This is a large contrast to learning a "proper" programming language where you start on an empty text buffer and need to research what you may put into it. Using Excel requires so much less computer science knowledge than mainstream programming languages (e.g. "what's the difference between an int and a float?"), and yet you can solve a lot of real-world problems with it. This focus on end-user problems and abstraction of technical details (e.g. "what is execution?") is a big part of Excel's success and something we still don't really see in mainstream programming languages. That being said, you'll reach the ceiling of what Excel is good at sooner or later. This is where macros, VBA and friends come in and ruin the experience. A lot of future of coding ideas want to improve on this, making spreadsheets scale gracefully to more complex use cases while retaining the low barrier of entry.

I found this a fun read: https://www.notboring.co/p/excel-never-dies