Lambda the Ultimate

Spreadsheets have generally been known to be a dangerous. Maureen C. Thommes has a neat history of early spreadsheet software in her book Advanced Spreadsheet Design Using Lotus Macros. Warning: Do not expect much content out of this book if you purchase it. The major discussion point centers around (1) the fact early spreadsheet software did not apply a Flyweight pattern in allocating spreadsheet cells, such that the software consumed n x m cells of addressable storage regardless of how sparse the spreadsheet was; this had the effect of macros "locking up" the user interface while they processed all the results and led to the introduction of asynchronous spreadsheet update capabilities (2) when editing spreadsheets via dynamically inserting new rows and columns, the user can make disasterous logic flaws. Thommes then explains a solution to this problem called the "staircase layout" (or something like that), which basically robs the spreadsheet of its analysis and reporting power.

A more recent book on this issue is Spreadsheet Check and Control. [Edit: Martin has fixed the link to his paper above. I'd recommend reading it for a more automated way of doing "spreadsheet check and control".]

I consider these issues to be more related to trustworthiness. It just happens to be an excessively dynamic demonstration of trustworthiness, because in a live programming language like Excel, the user is constantly flipping from execution mode to design mode and the environment is therefore constantly changing, making static determination of trustworthiness at deployment time impossible.

There are other more basic problems with spreadsheets, such as "cosmetic" rounding issues that effectively fly over my head.

I would have thought its biggest criticism is not working: users outgrow it

Outgrowing software requires having enough training and practical experience solving problems using the programming environment that they actually can outgrow it. Some of the software we write is so complex that it takes a week worth of training to master, and very few of our clients are willing to invest that much training time for employees, because they have very high turnover rates (~1 year term of employeement). This is where near-Monopolies like Microsoft are sort of cool, in that everyone can just learn Microsoft's UI and tools and then their only problem is outgrowing that stuff. So the solution there so far has been that these users buy Office plug-ins to have more advanced spreadsheet functionality.

Ah, I view spreadsheets as a very small view of what PBD can be. I'm talking more like Rob Miller's group that pushes this boundary -- stunning concepts, but, as with anything on the edge, there are basic software engineering concerns.

Ah, I view spreadsheets as a very small view of what PBD can be.

Small view, or small subset?

In terms of challenging UI problems, spreadsheets are non-trivial visual programming environments. Spreadsheets might be a small view (not sure what that means), but it does not seem like a small subset.

I am continually reminded of the incredible things I saw domain experts (particularly educators) do with HyperCard. I don't believe there's ever been a comparable, widely available, end-user programming system.

ToonTalk tries for an even higher bar than end-user programming; programming by children as their first language, to learn as a game.

This is probably why it gets left out of Ko's end-user programming survey; Ko is presumably so focused on bringing end-user programming for adults; Table 1 in the paper (on page 4) demonstrates this by only associating "Children" to "Create animations and games with Alice [Dann et al. 2006] and BASIC".