5 ms·
Also because Excel is both an IDE for developing spreadsheets, and a GUI container for operating them. Splitting dev time and run time environments would help w
by osullivj 9y ago
Also because Excel is both an IDE for developing spreadsheets, and a GUI container for operating them. Splitting dev time and run time environments would help with control. When a dev supplies a user with a traditional .Net GUI app, they don't enable the user to hack the app by supplying a copy of VisualStudio alongside. Effectively, this is what Excel does.
- dalbasal 9y agoYes, but. It's no good if you fix excel by making it not excel. The whole reason excel is so popular is the intuitive, unintimidating but terribly wrong way it mixes data, code and GUI. Functions in the data, constants repeated in every row, hard coded variables all over the place. If you're just supplying a GUI and hiding the code, the user can't change, add or debug anymore. The point is that they can code, even if they don't know they are coding. The trick is to think up a way of shipping VisualStudio, but making it less terrifying to engineers, managers and such.
- osullivj 9y agoAgreed. But a different way of working the same trick is to have an alternate run time that can execute .xls[x|m] as a headless server process.