4 ms·

We've all seen incredible things built in spreadsheets. Spreadsheets are plenty powerful. I haven't met a clever+motivated person yet that couldn't build someth

We've all seen incredible things built in spreadsheets. Spreadsheets are plenty powerful. I haven't met a clever+motivated person yet that couldn't build something incredible in a spreadsheet. What I think is missing is a way to help the author (and other team members) make sense of the artifact as it gets more complex. Much of the development in computer languages and toolsets in the last 50 years have helped us make sense of ever-increasingly complex programs. With spreadsheets for example, you are basically forced to find a cell that seems to have data you like. Then you have to back-track formula references + check for macros/scripts and hope that no references have broken. I humbly submit this is a problem that a team like the Coda team should be solving.

infogulch 7y ago
Excel needs exactly one thing to blow open the doors on productive programming: a new "function" data type. Since it's just a data type, you put it in a cell just like any other data type. Have some way to call it, like `A1(arg1, arg2)` or something. Now you can leverage the full capabilities of Excel to manage it, name it (named ranges), etc just like other data. A more sane expression syntax might be nice too, but isn't necessary to make Excel more productive for abstract programming.
- ahane 7y ago
  sounds like a great idea
- jagged-chisel 7y ago
  Sounds like you want to move VBA into the cell. I issue no opinion on doing that, just offering an observation.
  - infogulch 7y ago
    Actually you make a great point (thank you!), but honestly I wouldn't want it to have anything to do with VBA. For a feature like this to be successful imo it needs zero sandbox concerns; a user should never be prompted to downgrade to a lower security configuration, it has to be built in and available by default in every sheet. I don't see VBA ever being safe enough to enable by default everywhere. VBA is just an escape-hatch to a 'real' programming environment; my claim is that excel sheets & formulas alone could be a 'real' programming environment in its own right, no escape hatches necessary. All just by adding one feature to the existing formula language. The reason why excel is so popular today is its simple and understandable expression language and a unified spatially-oriented layout for code and data. Just shoehorning VBA into a cell loses all of the understandability of the simple excel formula and brings with it all the baggage of the old way of needing to manage source code. I think we can do better than that for normal everyday excel documents and normal users.
    - xscott 7y ago
      I completely agree and have been thinking the same thing for a while now. Another reason you need the function language to be really integrated with the rest of the spread sheet (unlike VBA) is so that global variables are also visible in the dependency tree and topological sort. For instance, imagine a cell containing the following lambda function: function (x, y) { return A1*x + y; } It's clear that if the user changes the value in the A1 cell, any other cell which calls this function should be updated to reflect the new result. In addition to the arguments to the function (x and y), A1 is also an implicit parameter.

infogulch 7y ago

Excel needs exactly one thing to blow open the doors on productive programming: a new "function" data type. Since it's just a data type, you put it in a cell just like any other data type. Have some way to call it, like `A1(arg1, arg2)` or something. Now you can leverage the full capabilities of Excel to manage it, name it (named ranges), etc just like other data. A more sane expression syntax might be nice too, but isn't necessary to make Excel more productive for abstract programming.

ahane 7y ago
sounds like a great idea
jagged-chisel 7y ago
Sounds like you want to move VBA into the cell. I issue no opinion on doing that, just offering an observation.
- infogulch 7y ago
  Actually you make a great point (thank you!), but honestly I wouldn't want it to have anything to do with VBA. For a feature like this to be successful imo it needs zero sandbox concerns; a user should never be prompted to downgrade to a lower security configuration, it has to be built in and available by default in every sheet. I don't see VBA ever being safe enough to enable by default everywhere. VBA is just an escape-hatch to a 'real' programming environment; my claim is that excel sheets & formulas alone could be a 'real' programming environment in its own right, no escape hatches necessary. All just by adding one feature to the existing formula language. The reason why excel is so popular today is its simple and understandable expression language and a unified spatially-oriented layout for code and data. Just shoehorning VBA into a cell loses all of the understandability of the simple excel formula and brings with it all the baggage of the old way of needing to manage source code. I think we can do better than that for normal everyday excel documents and normal users.
  - xscott 7y ago
    I completely agree and have been thinking the same thing for a while now. Another reason you need the function language to be really integrated with the rest of the spread sheet (unlike VBA) is so that global variables are also visible in the dependency tree and topological sort. For instance, imagine a cell containing the following lambda function: function (x, y) { return A1*x + y; } It's clear that if the user changes the value in the A1 cell, any other cell which calls this function should be updated to reflect the new result. In addition to the arguments to the function (x and y), A1 is also an implicit parameter.