Saturday, December 31, 2016

Spreadsheet programming

People who don't call themselves programmers can build sophisticated programs using spreadsheet programs. How come? And what implications does it have for building better programming tools?

1. Normal programming deals with control flow. Spreadsheets deal with data flow. That means that sequencing issues disappear. In a procedural language, you have to call a function at the right place in the program: after all its inputs have been set and before its outputs are needed. In a spreadsheet, this happens automatically.
2. Spreadsheets give fast feedback. Some development environments, like JSFiddle, JSBin, CodePen, Plunker, and other javascript playgrounds do this. So do various interpretive languages. But as programs grow, feedback slows. Spreadsheets, on the other hand, give fast feedback to small changes with low impact, slower feedback to changes that have global impact.
3. Spreadsheets know when you're finished with a change. As soon as you move out of a cell, the spreadsheet recalculates (assuming no errors). Playgrounds need to decide whether you're finished editing or not. If they guess wrong, there's a noticeable penalty.
4. Spreadsheets let you organize information multi-dimensionally. Normal programming languages are entirely linear. Spreadsheets give you two dimensions, at least. Within a sheet's two dimensions you can chunk information arbitrarily.
5. Spreadsheets make it easy to visualize information. You can grab key parameters and put them all in one area.
6. Spreadsheets help you see dependencies.
7. Spreadsheet cells are pure functions. There are no side effects.

Of course, there are disadvantages. You can only put so much logic in a cell before you need to resort to a scripting language. And then you have the usual problems of dealing with procedural languages. And you can only transfer a single value--a number or a string. No structures allowed. And the spreadsheet grid limits presentation options. And binding is one-way.

But imagine a spreadsheet-like model that removed some of these limitations. A 2D area might be subdivided into a "model" section and a "view" section. Values in the model would be bound to areas in the view so that, by default, changing the model would change the view, and vice-versa.

Widgets in the view might have property sets that were, themselves, represented by subordinate spreadsheets, and every value in the property set could contain a simple formula.

As the system scales the number of cells grows, unmanageably so we need a way to restrict our view to only those elements of interest at a given moment. 

This starts to look a bit like a standard GUI-building environment, with widgets with property sheets. There are important differences, though. One is: