6 ms·

You identified the essential qualities of spreadsheets, which many programmers fail to realize how important these are; these qualities are what make spreadshee

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/
- hathawsh 5y ago
  Great responses. Thank you. Subtext does seem like an interesting attempt to expand the kinds of problems spreadsheets can solve.
  - kragen 5y ago
    Subtext isn't a spreadsheet, so I don't think it's fair to describe it as an "attempt to expand the kinds of problems spreadsheets can solve".
    - TuringTest 5y ago
      It works to solve the same space of problems, so at least it's fair to compare it as an alternative. As I said elsewhere, it's a pity that its chosen license works directly against widespread adoption. I may take a look at how it's done to gather some implementation ideas, but I would never depend on it for any project that have a chance of growth.
      - kragen 5y ago
        It doesn't work to solve the same space of problems as spreadsheets either, nor is it fair to compare it as an alternative, except in the sense that any programming language is an alternative to spreadsheets. The thing here that's licensed in a not-very-useful manner is a prototype of a prototype, less complete than some previous iterations of Subtext, and in particular without implementation ideas.
        TuringTest 5y ago
        The author explicitly says that it "is searching for the missing link between spreadsheets and programming", so I gather form that that JonathanMEdwards actually thinks of this as fulfilling the role of spreadsheets in "build[ing] simple custom apps without learning to program". Other programming languages are not alternatives to spreadsheets in that sense.

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/

hathawsh 5y ago
Great responses. Thank you. Subtext does seem like an interesting attempt to expand the kinds of problems spreadsheets can solve.
- kragen 5y ago
  Subtext isn't a spreadsheet, so I don't think it's fair to describe it as an "attempt to expand the kinds of problems spreadsheets can solve".
  - TuringTest 5y ago
    It works to solve the same space of problems, so at least it's fair to compare it as an alternative. As I said elsewhere, it's a pity that its chosen license works directly against widespread adoption. I may take a look at how it's done to gather some implementation ideas, but I would never depend on it for any project that have a chance of growth.
    - kragen 5y ago
      It doesn't work to solve the same space of problems as spreadsheets either, nor is it fair to compare it as an alternative, except in the sense that any programming language is an alternative to spreadsheets. The thing here that's licensed in a not-very-useful manner is a prototype of a prototype, less complete than some previous iterations of Subtext, and in particular without implementation ideas.
      - TuringTest 5y ago
        The author explicitly says that it "is searching for the missing link between spreadsheets and programming", so I gather form that that JonathanMEdwards actually thinks of this as fulfilling the role of spreadsheets in "build[ing] simple custom apps without learning to program". Other programming languages are not alternatives to spreadsheets in that sense.