It's alive! continuous feedback in UI programming

Abstract

Live programming allows programmers to edit the code of a running program and immediately see the effect of the code changes. This tightening of the traditional edit-compile-run cycle reduces the cognitive gap between program code and execution, improving the learning experience of beginning programmers while boosting the productivity of seasoned ones. Unfortunately, live programming is difficult to realize in practice as imperative languages lack welldefined abstraction boundaries that make live programming responsive or its feedback comprehensible.This paper enables live programming for user interface programming by cleanly separating the rendering and non-rendering aspects of a UI program, allowing the display to be refreshed on a code change without restarting the program. A type and effect system formalizes this separation and provides an evaluation model that incorporates the code update step. By putting live programming on a more formal footing, we hope to enable critical and technical discussion of live programming systems.

Lessons from a web-based IDE and runtime

“…The ability to rerun the layout code without affecting program state, allows our IDE to provide "live-programming", namely editing the layout code of a "running" program and seeing the changes to the UI immediately [3].…”

Usable live programming

“…We see none of this. Our live programming system, dubbed YinYang, aims to fix this problem by focusing on debugging, which is missing from many existing live programming systems like [5,17,24,26]. Traditional debugging techniques, like breaking and stepping with a debugger, are not compatible with continuous execution: instruction stepping interferes with continuous live feedback, while a separate debugger interface to navigate and inspect execution necessarily disrupts programmer focus on code editing.…”

“…State changes performed by imperative code are final-code edits cannot change the past and time travel is impossible-while only the "present" state of the program is observed by the programmer. Work on TouchDevelop [5] formalizes this style of live programming by separating a "view," whose code is amenable to live programming, from a "model," whose initialization and mutation code is not; we can conceptualize this as: m = initial; while (true) XXClearScreen(); XXm = RenderAndHandle(m);…”

“…But what does this output look like? In many live programming systems [5,17,18,22,24,26,27], programmers only observe updated visual output while editing; many relevant intermediate results are left unseen. And what about programs like compilers whose original outputs are not even visual?…”

Live object exploration: Observing and manipulating behavior and state of Java objects

“…In general, live programming environments provide an infrastructure, that enables developers to immediately recognize how state and behavior of a running program are affected, when changing the underlying source code [11], [12]. Live programming occurs in several application scenarios, e.g., creating user interfaces [13], in continuous testing [14], or when using an insitu debugger [15]. Recent studies show that live programming significantly helps developers in finding and fixing bugs [16], [17].…”