5 ms·

I once built a complex spreadsheet for my colleagues. When I had to leave, what I built for them was almost instantly useless because there was too much they ne

I once built a complex spreadsheet for my colleagues. When I had to leave, what I built for them was almost instantly useless because there was too much they needed to understand. That got me thinking about the gulf between spreadsheets and programming languages. There are important differences: - Spreadsheets don't separate code from data, which is an important aspect of programming. Blending the two is a nice shortcut for spreadsheets, but it ruins maintainability. - Naming is important for programming, but spreadsheets encourage users to not bother with names and fall back to cell coordinates like "A10" instead. It's a great shortcut, but again, it ruins maintainability. - Spreadsheet formulas operate on scalar values, while programming languages operate on nested data structures. Data structures are a key to managing complexity, yet the spreadsheet paradigm has only a very limited view of them. If users are ever going to be able to use a spreadsheet-like interface for serious programming, most of those issues will need to be addressed in a way that doesn't hurt usability. That's a tall order! Users already struggle with function calls in formulas. At some point it's smarter for users to just pay a programmer to figure out how to build it.

stormbrew 5y ago
> the gulf between spreadsheets and programming languages There is no gulf. Spreadsheets just are programming languages. You've certainly identified problems or at least quirks of spreadsheets as a 'language', but I think people do a huge disservice to their own ability to understand programming as a field when they try to carve out exclusions for languages and environments on the basis of who uses them. Lots of things no one would ever argue aren't a programming language have all these flaws and more. When people make a big ass complicated spreadsheet, they are programming. They are doing so whether they're a seasoned professional or an accountant or a lawyer or a homemaker.
- TuringTest 5y ago
  Of course people who use spreadsheets are programming; they're building data structures (with columns as object fields), generating values from formulas, and debugging the program's execution when editing cells. What develops typically don't get is that the paradigm of the programming language and environment matters a lot, triple so for people without formal training in coding. Most people who can code with a spreadsheet would be totally unable to create a very simple shell script, because the paradigm of imperative, syntax-led classic programming languages require building a mental model of a whole Turing machine in your head, which requires years of training. That's the gulf the GP was referring to; not from which people happen to use them, but from how they think about coding. The functional-reactive paradigm (and spreadsheets in particular) avoid that need, because they're highly composable so you can truly think of each part of the program in isolation, something which side-effects and program flow in imperative programs won't allow.
  - stormbrew 5y ago
    > That's the gulf the GP was referring to; not from which people happen to use them, but from how they think about coding. I'm calling out an implicit bias that always comes up in discussions like these and I see lurking behind this sentiment, because these two things are inextricably related, not an accidental correlation. They think better in this paradigm because its a better suited paradigm to their actual work, and it fits better with things they understand already because of their experiences and knowledge. When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people outside of it. Our solutions, when we look at it this way (with a stark divide between "programmers" and "non-programmers"), end up demanding that they come to our understanding instead of us to theirs. And that's basically always doomed to fail. This is important.
    - TuringTest 5y ago
      > When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people outside of it. Our solutions, when we look at it this way (with a stark divide between "programmers" and "non-programmers"), end up demanding that they come to our understanding instead of us to theirs. And that's basically always doomed to fail. I concur, that's a good way to put it. The "way of the programmer" requires an unnatural way of reasoning that takes a lot of effort to master, and requires a lot of short-term memory effort to mentally simulate how the code behaves. I don't even think this programming style is truly required for professional programmers either; more a by-product of how programming started as a way to feed instructions to mono-processors in the context of mathematics and physics computations on limited hardware. Symbolic business logic doesn't typically depend so strongly on the specifics of runtime execution, and recently there has been a very active movement to build new programming environments which emphasize the relationship between code and data, rather than between code and intermediate states of computation as in classical programming languages.
TuringTest 5y ago
You identified the essential qualities of spreadsheets, which many programmers fail to realize how important these are; these qualities are what make spreadsheets so useful to non-programmers. A successful development tool for non-coders should retain these, and explore alternative ways to add all the benefits of IDEs without the burden of classic programming languages. - Spreadsheets don't separate code from data, and that's the single most important reason why they're easy to use and allow non-developers to build automations. They work like an always-on debugger, so normal users can work like a programmer works when exploring and/or fixing a program's behaviour. Practically no other coding tool for non-developers allow this. - Naming is important for code reuse, not necessarily for one-shot functions; positional reasoning can work equally well there. Spreadsheets do allow naming cells and accessing them by name when needed; but the option not to, which classic PLs don't allow, lowers the entry barrier. Programmers could also name all their parameters 'a', 'b', 'c'; that they learn to use better names is a matter of discipline, not a limitation of the tool. - Scalar vs ranges: this one is actually the most limiting part of spreadsheets. They are great for tabular data structures (doh!), but nested structures are tricky. There are research projects to improve this (Microsoft hosts a lot of them on this line, specially around ML and Programming By Example), but in the end you need to overcome the paradigm and apply spreadsheet-like programming concepts to tools allowing hierarchical, nested structures. That lies the future of computation for the masses.
- kragen 5y ago
  - You can have an always-on debugger while still factoring common code out of varying data. Subtext does this. - You can give things names after you create them instead of before, and it's not clear that argument names are necessarily either necessary or sufficient for code reuse. Subtext makes it easy to change argument names whenever you want. - It's reasonable to describe Subtext as a programming-by-example environment, and it does support nesting—in fact, it's rather pervasively nested. An alternative approach is to solve your problems without hierarchical, nested structures. SQL and co-dfns are two interesting directions there. I wrote an overview of this kind of thing five years ago: http://canonical.org/~kragen/memory-models/ http://canonical.org/~kragen/memory-models/

stormbrew 5y ago

> the gulf between spreadsheets and programming languages There is no gulf. Spreadsheets just are programming languages. You've certainly identified problems or at least quirks of spreadsheets as a 'language', but I think people do a huge disservice to their own ability to understand programming as a field when they try to carve out exclusions for languages and environments on the basis of who uses them. Lots of things no one would ever argue aren't a programming language have all these flaws and more. When people make a big ass complicated spreadsheet, they are programming. They are doing so whether they're a seasoned professional or an accountant or a lawyer or a homemaker.

TuringTest 5y ago
Of course people who use spreadsheets are programming; they're building data structures (with columns as object fields), generating values from formulas, and debugging the program's execution when editing cells. What develops typically don't get is that the paradigm of the programming language and environment matters a lot, triple so for people without formal training in coding. Most people who can code with a spreadsheet would be totally unable to create a very simple shell script, because the paradigm of imperative, syntax-led classic programming languages require building a mental model of a whole Turing machine in your head, which requires years of training. That's the gulf the GP was referring to; not from which people happen to use them, but from how they think about coding. The functional-reactive paradigm (and spreadsheets in particular) avoid that need, because they're highly composable so you can truly think of each part of the program in isolation, something which side-effects and program flow in imperative programs won't allow.
- stormbrew 5y ago
  > That's the gulf the GP was referring to; not from which people happen to use them, but from how they think about coding. I'm calling out an implicit bias that always comes up in discussions like these and I see lurking behind this sentiment, because these two things are inextricably related, not an accidental correlation. They think better in this paradigm because its a better suited paradigm to their actual work, and it fits better with things they understand already because of their experiences and knowledge. When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people outside of it. Our solutions, when we look at it this way (with a stark divide between "programmers" and "non-programmers"), end up demanding that they come to our understanding instead of us to theirs. And that's basically always doomed to fail. This is important.
  - TuringTest 5y ago
    > When we prioritize the "thought patterns" of professional programmers we forget this, and then we lament the lack of understanding for our field from people outside of it. Our solutions, when we look at it this way (with a stark divide between "programmers" and "non-programmers"), end up demanding that they come to our understanding instead of us to theirs. And that's basically always doomed to fail. I concur, that's a good way to put it. The "way of the programmer" requires an unnatural way of reasoning that takes a lot of effort to master, and requires a lot of short-term memory effort to mentally simulate how the code behaves. I don't even think this programming style is truly required for professional programmers either; more a by-product of how programming started as a way to feed instructions to mono-processors in the context of mathematics and physics computations on limited hardware. Symbolic business logic doesn't typically depend so strongly on the specifics of runtime execution, and recently there has been a very active movement to build new programming environments which emphasize the relationship between code and data, rather than between code and intermediate states of computation as in classical programming languages.

TuringTest 5y ago

You identified the essential qualities of spreadsheets, which many programmers fail to realize how important these are; these qualities are what make spreadsheets so useful to non-programmers. A successful development tool for non-coders should retain these, and explore alternative ways to add all the benefits of IDEs without the burden of classic programming languages. - Spreadsheets don't separate code from data, and that's the single most important reason why they're easy to use and allow non-developers to build automations. They work like an always-on debugger, so normal users can work like a programmer works when exploring and/or fixing a program's behaviour. Practically no other coding tool for non-developers allow this. - Naming is important for code reuse, not necessarily for one-shot functions; positional reasoning can work equally well there. Spreadsheets do allow naming cells and accessing them by name when needed; but the option not to, which classic PLs don't allow, lowers the entry barrier. Programmers could also name all their parameters 'a', 'b', 'c'; that they learn to use better names is a matter of discipline, not a limitation of the tool. - Scalar vs ranges: this one is actually the most limiting part of spreadsheets. They are great for tabular data structures (doh!), but nested structures are tricky. There are research projects to improve this (Microsoft hosts a lot of them on this line, specially around ML and Programming By Example), but in the end you need to overcome the paradigm and apply spreadsheet-like programming concepts to tools allowing hierarchical, nested structures. That lies the future of computation for the masses.

kragen 5y ago
- You can have an always-on debugger while still factoring common code out of varying data. Subtext does this. - You can give things names after you create them instead of before, and it's not clear that argument names are necessarily either necessary or sufficient for code reuse. Subtext makes it easy to change argument names whenever you want. - It's reasonable to describe Subtext as a programming-by-example environment, and it does support nesting—in fact, it's rather pervasively nested. An alternative approach is to solve your problems without hierarchical, nested structures. SQL and co-dfns are two interesting directions there. I wrote an overview of this kind of thing five years ago: http://canonical.org/~kragen/memory-models/ http://canonical.org/~kragen/memory-models/