Home

Google TechTalk: The Evolution of End-User Programming

End-User Programming has been a topical discussion lately in mainstream software outlets. The IEEE journal Software recently had an issue dedicated to end-user programming challenges; see Joel Brandt's Opportunistic Programming: Writing Code to Prototype, Ideate and Discover and Martin Erwig's Software Engineering for Spreadsheets. Also, a few years ago a consortium of universities formed End-Users Shaping Effective Software, which includes Martin Erwig's PLT work on bringing type systems to spreadsheets.

Recently, Google invited Allen Cypher to give a TechTalk on The Evolution of End-User Programming, which appears to be a recapitulation of his VL/HCC paper by the same name. Allen was the editor of Watch What I Do (an LtU recommended reading).

Towards the end of the talk, Allen mentions the practical issues of knowing when to use what tool, and that novice users struggle with finding the right tool for the right job. What's notable about discussion of end-user software engineering is how little attention its proponents pay to its critics biggest criticism: Security. In the IEEE Software realm, probably the most open critic has been Warren Harrison (see: The Dangers of End-User Programming). For example, Ko's 2009 ACM Computing Survey The State of the Art in End-User Software Engineering only mentions security once, in the context of designing end-user description languages for security, but does not assess how well this technique compares to techniques software engineers might employ. It seems strange that leading researchers in visual languages and end-user programming do not discuss the potential usage of object capability systems, especially as companies try to monetize a percentage of the value added by users who mash-up their service with other services.

By Z-Bo at 2010-02-12 18:24 | General | History | Software Engineering | other blogs | 12927 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I would have thought it's

I would have thought its biggest criticism is not working: users outgrow it, and, for more recent learning/inference research, basic integration with software and reliance on learning algorithms simply doing the wrong thing. Perhaps by security you include simple safety properties (don't delete the wrong data), in which case I agree.

By lmeyerov at Fri, 2010-02-12 19:48 | login or register to post comments

Security -and- trustworthiness

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.

By Z-Bo at Fri, 2010-02-12 20:10 | login or register to post comments

Ah, I view spreadsheets as a

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.

By lmeyerov at Sat, 2010-02-13 00:34 | login or register to post comments

Ah, I view spreadsheets as a

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.

By Z-Bo at Tue, 2010-02-16 14:01 | login or register to post comments

Hypercard

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.

By mfidelman at Sat, 2010-02-13 01:46 | login or register to post comments

ToonTalk is an object-capability system

It seems strange that leading researchers in visual languages and
end-user programming do not discuss the potential usage of object
capability systems

ToonTalk is one of the most interesting systems of programming by demonstration. It has the semantics of a distributed persistent object-capability system. Its inter-machine protocol isn't actually secure. But it could be made secure, using techniques familiar from other distributed cryptographic capability systems, without affecting the semantics of ToonTalk.

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

By MarkM at Sat, 2010-02-13 00:20 | login or register to post comments

overlooking ToonTalk

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".

By Z-Bo at Tue, 2010-02-16 14:05 | login or register to post comments