Live Programming Environments Research Articles

Babylonian-style Programming: Design and Implementation of an Integration of Live Examples into General-purpose Source Code

When working on a program, developers traditionally have to simulate the behavior of the abstract code in their heads until they can execute the application. Live programming aims to support the development and comprehension of programs by providing more immediate feedback on program behavior, but the divide between code and behavior often remains. The goal of example-based live programming is to remove this gap by allowing programmers to explore the actual behavior of their code during development. This is achieved by defining live examples for parts of the application. The idea of live examples has been already addressed in other tools and environments. However, most of those solutions are limited to specific domains and are suitable only for small programs. Thus, we aim to extend the application of example-based live programming to more complex programs potentially spanning multiple modules. We investigate existing solutions to derive a set of requirements for an integration of live examples into source code. Based on these requirements we propose a new approach to live examples and present a prototype in its support. We reproduce, discuss, and extend scenarios from related work to show the practicality of our approach in the context of larger, more complicated, and with that also more realistic scenarios. Also, we measure and evaluate the system response time of our prototypical implementation. Our first results show that example-based live programming can provide more insights into the run-time behavior of parameterized code for non-trivial programs. They also reveal unsolved and new challenges affecting example-based live programming environments. In presenting this more general approach to example-based live programming, we hope to motivate further research into this area and to make practical solutions available.

Live functional programming with typed holes

Live programming environments aim to provide programmers (and sometimes audiences) with continuous feedback about a program's dynamic behavior as it is being edited. The problem is that programming languages typically assign dynamic meaning only to programs that are complete, i.e. syntactically well-formed and free of type errors. Consequently, live feedback presented to the programmer exhibits temporal or perceptive gaps. This paper confronts this "gap problem" from type-theoretic first principles by developing a dynamic semantics for incomplete functional programs, starting from the static semantics for incomplete functional programs developed in recent work on Hazelnut. We model incomplete functional programs as expressions with holes, with empty holes standing for missing expressions or types, and non-empty holes operating as membranes around static and dynamic type inconsistencies. Rather than aborting when evaluation encounters any of these holes as in some existing systems, evaluation proceeds around holes, tracking the closure around each hole instance as it flows through the remainder of the program. Editor services can use the information in these hole closures to help the programmer develop and confirm their mental model of the behavior of the complete portions of the program as they decide how to fill the remaining holes. Hole closures also enable a fill-and-resume operation that avoids the need to restart evaluation after edits that amount to hole filling. Formally, the semantics borrows machinery from both gradual type theory (which supplies the basis for handling unfilled type holes) and contextual modal type theory (which supplies a logical basis for hole closures), combining these and developing additional machinery necessary to continue evaluation past holes while maintaining type safety. We have mechanized the metatheory of the core calculus, called Hazelnut Live, using the Agda proof assistant. We have also implemented these ideas into the Hazel programming environment. The implementation inserts holes automatically, following the Hazelnut edit action calculus, to guarantee that every editor state has some (possibly incomplete) type. Taken together with this paper's type safety property, the result is a proof-of-concept live programming environment where rich dynamic feedback is truly available without gaps, i.e. for every reachable editor state.

Live programming in practice: A controlled experiment on state machines for robotic behaviors

Abstract Context Live programming environments are gaining momentum across multiple programming languages. A tenet of live programming is a development feedback cycle, resulting in faster development practices. Although practitioners of live programming consider it a positive inclusion in their workflow, no in-depth investigations have yet been conducted on its benefits in a realistic scenario, nor using complex API. Objective This paper carefully studies the advantage of using live programming in defining nested state machines for robot behaviors. We analyzed two important aspects of developing robotic behaviors using these machines: program comprehension and program writing. We analyzed both development practices in terms of speed and accuracy. Method We conducted two controlled experiments, one for program comprehension and another for program writing. We measured the speed and accuracy of randomized assigned participants on completing programming tasks, against a baseline. Results In a robotic behavior context, we found that a live programming system for nested state machine programs does not significantly outperform a non-live language in program comprehension nor in program writing in terms of speed and accuracy. However, the feedback of test subjects indicates their preference for the live programming system. Conclusions The results of this work seem to contradict the studies of live programming in other areas, even while participants still favor using live programming techniques. We learned that the complex API chosen in this work has a strong negative influence on the results. To the best of our knowledge, this is the first in-depth live programming experiment in a complex domain.

Dynamic Software Update from Development to Production.

Dynamic Software Update (DSU) solutions update applications while they are executing. These solutions are typically used in production to minimize application downtime, or in integrated development environments to provide live programming support. Each of these scenarios presents different challenges, forcing existing solutions to be designed with only one of these use cases in mind. For example, DSUs for live programming typically do not implement safe point detection or instance migration, while production DSUs require manual generation of patches and lack IDE integration. Also, these solutions have limited ability to update themselves or the language core libraries, and some of them present execution penalties outside the update window. We propose a DSU (gDSU) that works for both live programming and production environments. Our solution implements safe update point detection using call stack manipulation and a reusable instance migration mechanism to minimize manual intervention in patch generation. Moreover, it also offers updates of core language libraries and the update mechanism itself. This is achieved by the incremental copy of the modified objects and an atomic commit operation. We show that our solution does not affect the global performance of the application and it presents only a run-time penalty during the update window. Our solution is able to apply an update impacting 100,000 instances in 1 second. In this 1 second, only during 250 milliseconds the application is not responsive. The rest of the time the application runs normally while gDSU is looking for the safe update point. The update only requires to copy the elements that are modified.

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

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.