Edit Transactions: Dynamically Scoped Change Sets for Controlled Updates in Live Programming

📝 Abstract

Live programming environments enable programmers to edit a running program and obtain immediate feedback on each individual change. The liveness quality is valued by programmers to help work in small steps and continuously add or correct small functionality while maintaining the impression of a direct connection between each edit and its manifestation at run-time. Such immediacy may conflict with the desire to perform a combined set of intermediate steps, such as a refactoring, without immediately taking effect after each individual edit. This becomes important when an incomplete sequence of small-scale changes can easily break the running program. State-of-the-art solutions focus on retroactive recovery mechanisms, such as debugging or version control. In contrast, we propose a proactive approach: Multiple individual changes to the program are collected in an Edit Transaction, which can be made effective if deemed complete. Upon activation, the combined steps become visible together. Edit Transactions are capable of dynamic scoping, allowing a set of changes to be tested in isolation before being extended to the running application. This enables a live programming workflow with full control over change granularity, immediate feedback on tests, delayed effect on the running application, and coarse-grained undos. We present an implementation of Edit Transactions along with Edit-Transaction-aware tools in Squeak/Smalltalk. We asses this implementation by conducting a case study with and without the new tool support, comparing programming activities, errors, and detours for implementing new functionality in a running simulation. We conclude that workflows using Edit Transactions have the potential to increase confidence in a change, reduce potential for run-time errors, and eventually make live programming more predictable and engaging.

💡 Analysis

Live programming environments enable programmers to edit a running program and obtain immediate feedback on each individual change. The liveness quality is valued by programmers to help work in small steps and continuously add or correct small functionality while maintaining the impression of a direct connection between each edit and its manifestation at run-time. Such immediacy may conflict with the desire to perform a combined set of intermediate steps, such as a refactoring, without immediately taking effect after each individual edit. This becomes important when an incomplete sequence of small-scale changes can easily break the running program. State-of-the-art solutions focus on retroactive recovery mechanisms, such as debugging or version control. In contrast, we propose a proactive approach: Multiple individual changes to the program are collected in an Edit Transaction, which can be made effective if deemed complete. Upon activation, the combined steps become visible together. Edit Transactions are capable of dynamic scoping, allowing a set of changes to be tested in isolation before being extended to the running application. This enables a live programming workflow with full control over change granularity, immediate feedback on tests, delayed effect on the running application, and coarse-grained undos. We present an implementation of Edit Transactions along with Edit-Transaction-aware tools in Squeak/Smalltalk. We asses this implementation by conducting a case study with and without the new tool support, comparing programming activities, errors, and detours for implementing new functionality in a running simulation. We conclude that workflows using Edit Transactions have the potential to increase confidence in a change, reduce potential for run-time errors, and eventually make live programming more predictable and engaging.

📄 Content

Edit Transactions Dynamically Scoped Change Sets for Controlled Updates in Live Programming Toni Mattisa, Patrick Reina, and Robert Hirschfelda a Hasso Plattner Institute, University of Potsdam, Germany Abstract Live programming environments enable programmers to edit a running program and obtain im- mediate feedback on each individual change. The liveness quality is valued by programmers to help work in small steps and continuously add or correct small functionality while maintaining the impression of a direct connection between each edit operation and its manifestation at run-time. Such immediacy may conflict with the desire to perform a combined set of intermediate steps, like a refactoring, without instantly taking effect after each individual edit operation. This becomes important when an incomplete sequence of small-scale changes can easily break the running program. State-of-the-art solutions focus on retroactive recovery mechanisms, such as debugging or version control. In contrast, we propose a proactive approach: Multiple individual changes to the program are collected in an Edit Transaction, which can be made effective if deemed complete. Upon activation, the combined steps become visible together. Edit Transactions are capable of dynamic scoping, allowing a set of changes to be tested in isolation before being extended to the running application. This enables a live programming workflow with full control over change granularity, immediate feedback on tests, delayed effect on the running application, and undos at the right level of granularity. We present an implementation of Edit Transactions along with Edit-Transaction-aware tools in Squeak/S- malltalk. We asses this implementation by conducting a case study with and without the new tool support, comparing programming activities, errors, and detours for implementing new functionality in a running sim- ulation. We conclude that workflows using Edit Transactions have the potential to increase confidence in a change, reduce potential for run-time errors, and eventually make live programming more predictable and engaging. ACM CCS 2012 Software and its engineering →Development frameworks and environments; Object oriented development; Keywords Live Programming, Tool Support, Immediate Feedback, Squeak/Smalltalk, Edit Transactions The Art, Science, and Engineering of Programming Submitted December 2, 2016 Published April 1, 2017 doi 10.22152/programming-journal.org/2017/1/13 © Toni Mattis, Patrick Rein, and Robert Hirschfeld This work is licensed under a “CC BY 4.0” license. In The Art, Science, and Engineering of Programming, vol. 1, no. 2, 2017, article 13; 32 pages. Edit Transactions 1 Introduction Programming environments can be classified according to the timeliness of run-time feedback. Environments that provide immediate feedback for any change at run-time are called live programming environments [26]. Examples include Lively [13], Self [28], some LISP environments, Squeak/Smalltalk [9, 12], and educational environments like Scratch [20], and Etoys [8]. Immediate feedback sustains the impression of causality between change of source code and change in run-time behavior, e.g. a previously failed unit test succeeding right after the programmer saves that change, or a button having an effect when clicked after updating its event handler. This immediacy often makes it difficult to work on a more complex change, involving more than a single edit step, such as a refactoring or implementation of a cross-cutting concern, without facing the imminent danger of breaking the running program. For example, if programmers decide to insert a call to a method that has not been implemented yet, they could do so in non-live environments and implement the missing method later before they run the program. In Smalltalk, for example, the code referring to a planned, but not yet implemented method, may fail at any moment if it is part of the control flow of a running program. This forces programmers to pause their work on the call site, implement the missing method first, and then return to the original method to save the code. From the perspective of the programming environment, the feedback cycle can be modeled as a two-stage process [19]:

1. Adaptation, the phase where a changed translation unit, e.g. a method in Smalltalk, is translated to its executable representation. The feedback programmers obtain in this phase is restricted to compile-time errors.
2. Emergence, the phase where the control flow reaches the newly translated program parts and executes them, possibly causing a change in behavior that becomes visible. In this model of immediate feedback, the problem manifests itself as the fact that the frequency of emergence is directly linked to the granularity of adaptation, i.e. after each method change in Smalltalk, the newly compiled method becomes reachable by the control flow. The following proposal focuses on separating emergence from adaptation to allow

This content is AI-processed based on ArXiv data.