Blurring the Line Between User and Programmer

Re:Blurring the Line Between User and Programmer by infogulch on Friday October 25, 2019 @03:33PM (#21358443)

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.

[ Parent | on HN ]

Re:Blurring the Line Between User and Programmer by xscott on Saturday October 26, 2019 @03:54PM (#21365815)

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.

[ Parent | on HN ]