Various programming environments feature live programming as a central part of their programming experience. Liveness in these environments is analyzed by several theories, which describe the different forms of liveness and how they influence the programming experience. Unfortunately, these are isolated theories only concerned with live programming features. They can not explain liveness in terms of general interactions with programming tools.One theory that has successfully explained how programmers interact with various kinds of tools is information foraging theory (IFT). In this paper, we propose an IFT interpretation of liveness. By interpreting liveness in terms of a more comprehensive theory of programmer behavior, we can explain the role of liveness in common software development activities such as debugging.We have explored our IFT interpretation of liveness in a first controlled experiment. We investigated the hypothesis that when we remove liveness from live dynamic introspection tools, programmers will use them less often, as using them has a higher cost. We have conducted a post hoc analysis of the results for which we used the edit-run-cycle model adapted to analyze the usage of live programming tools. The post hoc results hint that programmers did shift away from introspection tools. While our study only features post hoc results, it suggests that the IFT interpretation of liveness is a fruitful avenue.

Formal specifications like TLA+ support software developers in formulating and verifying properties of their systems as state machines. Writing specifications helps software developers incrementally develop an understanding of their systems' domains. However, according to our formative study, while reading such specifications authored by others, software developers tend to struggle to build comprehension. To overcome the limitations of text, participants visualized specifications and manually constructed concrete example sequences of actions. We propose an approach that visualizes state-machine-based specifications to better support software developers in reading, exploring, and understanding them. Our tool, SpecTacles, generates and presents interactive visualizations derived from a specification's state space next to its original source text. Users can formulate example sequences of actions, which are synchronized between all visualizations. To explore how and why such interactive visualizations help, we conducted a user study (n=12) with software developers who had no prior training in formal specifications, and explored how they use our tool in a set of comprehension tasks. Participants used the source text to obtain local and definitive information, for example, to validate an assumption, but they referred to the visualizations to gain an overview and to compensate for the lack of control flow information in the source text. Given the strengths of both visualizations and source text, participants found SpecTacles useful for their comprehension and indicated that they would like to use it in other software engineering contexts.

Programmers regularly explore the execution of code examples to verify assumptions by adding print statements or commenting in and out setup code in their implementation to isolate code paths of interest. In our formative study on developing embedded programs, where proximity to hardware dictates low abstraction levels, we observed that wrong assumptions occur frequently. However, traditional editors for embedded programs lack support for such explorations. Consequently, programmers have to re-create and clean up setup and print statements in their code for each example. M mu SE supports isolated explorations of code examples by promoting examples to frst-class entities that allow for the mocking of side effects from code and hardware, which could interfere with examples, and automatically showing values of expressions, replacing print statements for debugging. Our exploratory study found that M mu SE supports participants in developing an understanding of software and hardware components and identifying false assumptions from observation of incorrect behavior.

Live programming provides feedback on run-time behavior by visualizing concrete values of expressions close to the source code.When using such a local perspective on run-time behavior, programmers have to mentally reconstruct the control flow if they want to understand the relation between observed values.As this requires complete and correct knowledge of all relevant code, this reconstruction is impractical for larger programs as well as in the case of unexpected program behavior.In turn, cross-cutting perspectives on run-time behavior can visualize the actual control flow directly.At the same time, cross-cutting perspectives are often difficult to navigate due to the large number of run-time events.We propose to integrate cross-cutting perspectives into live programming environments based on local perspectives so that the two complement each other: the cross-cutting perspective provides an overview of the run-time behavior; the local perspective provides detailed feedback as well as points of interest to navigate the cross-cutting perspective.We present a cross-cutting perspective prototype in the form of a call tree browser integrated into the Babylonian/S live programming environment.In an exploratory user study, we observed that programmers found the tool useful for debugging, code comprehension, and navigation.Finally, we discuss how our prototype illustrates how the features of live programming environments may serve as the basis for other powerful dynamic development tools.

Programmers regularly explore the execution of code examples to verify assumptions by adding print statements or commenting in and out setup code in their implementation to isolate code paths of interest. In our formative study on developing embedded programs, where proximity to hardware dictates low abstraction levels, we observed that wrong assumptions occur frequently. However, traditional editors for embedded programs lack support for such explorations. Consequently, programmers have to re-create and clean up setup and print statements in their code for each example. MµSE supports isolated explorations of code examples by promoting examples to first-class entities that allow for the mocking of side effects from code and hardware, which could interfere with examples, and automatically showing values of expressions, replacing print statements for debugging. Our exploratory study found that MµSE supports participants in developing an understanding of software and hardware components and identifying false assumptions from observation of incorrect behavior.

Live programming features can be found in a range of programming environments, from individual prototypes to widely used environments. While liveness is generally considered a useful property, there is little empirical evidence on when and how liveness can be beneficial. Even though there are few experimental studies, their results are largely inconclusive. We reviewed existing experiments and related studies to gather a collection of potential effects of liveness and moderating factors. Based on this collection, we concluded that **task complexity** and **prior experience addressing liveness** are potentially essential factors neglected in previous experiments. To fill this gap, we devised and conducted a controlled experiment (N = 37) testing the hypothesis that task complexity moderates the effects of live introspection tools on participants? debugging efficiency, given participants with prior experience with liveness. Our results do not support the hypothesis that task complexity moderates the effect of live introspection tools. This non-significant moderation effect might result from the low number of participants, as the data suggests a moderation effect. The results also show that in our experiment setting, live introspection tools significantly reduced the time participants took to debug the tasks. For researchers interested in the effects of liveness, our findings suggest that studies on liveness should make conscious choices about task complexity and participants' prior experience with liveness. For designers of programming environments, the results of our experiment are a step toward understanding when and how programming tools should be live to become more helpful to programmers.

Live programming provides feedback on run-time behavior by visualizing concrete values of expressions close to the source code. When using such a local perspective on run-time behavior, programmers have to mentally reconstruct the control flow if they want to understand the relation between observed values. As this requires complete and correct knowledge of all relevant code, this reconstruction is impractical for larger programs as well as in the case of unexpected program behavior. In turn, cross-cutting perspectives on run-time behavior can visualize the actual control flow directly. At the same time, cross-cutting perspectives are often difficult to navigate due to the large number of run-time events. We propose to integrate cross-cutting perspectives into live programming environments based on local perspectives so that the two complement each other: the cross-cutting perspective provides an overview of the run-time behavior; the local perspective provides detailed feedback as well as points of interest to navigate the cross-cutting perspective. We present a cross-cutting perspective prototype in the form of a call tree browser integrated into the Babylonian/S live programming environment. In an exploratory user study, we observed that programmers found the tool useful for debugging, code comprehension, and navigation. Finally, we discuss how our prototype illustrates how the features of live programming environments may serve as the basis for other powerful dynamic development tools.

Source code is inherently abstract. While this is necessary to capture the generality of a program, it poses a barrier to understanding and learning to use the underlying concepts. In education, especially in abstract subjects like maths, the use of concrete examples is considered instrumental to the acquisition of knowledge and a frequently explored direction for teaching computational concepts. Besides concreteness, the importance of examples being close to their abstract descriptions as well as the immediacy of feedback has been highlighted. Babylonian Programming (BP) is a type of example-based live programming that fulfills all three criteria by introducing concrete values, moving them as close as possible to the code, and updating them immediately in response to changes of either the example or the code. This makes BP a promising tool in education, yet no studies on the suitability of BP in a learning context have been conducted. Hence, we propose to (1.) investigate usability of state-of-the-art BP to minimize the friction of introducing BP in education, and (2.) measure the learning effectiveness and quality of experience of a BP environment in undergraduate software engineering education. For these studies, we will use the Smalltalk-based Babylonian/S as our environment. Besides clearer guidelines on the design of BP and example-based systems in general, we expect to shed light on the qualities that teacher-provided examples need to exhibit and the opportunities for learners to create their own examples during experimentation with unknown concepts.

Programming environments that provide a feeling of liveness help professionals and amateurs alike to approach unfamiliar domains with ease through short feedback loops. Exploration and experimentation are promoted because any change to the program under construction can be observed immediately. However, live-programming systems such as Squeak/Smalltalk struggle with the predictable emergence of adapted program behavior as object communication can be unconstrained and diverse. While programmers wish for immediate effects, it would be helpful to at least know whether anything will happen after some time. In this chapter, we take a closer look at the means available in Squeak to explore and adjust object state and object behavior so that programmers can ensure the system's responsiveness and hence observe gradual or even induce eventual emergence. We argue that these design strategies are sufficient to architect communication patterns that reward changes with immediate effects. We believe that our work can help programmers to better understand their leverage toward a predictable emergence in systems whose liveness stems from objects and messaging in a space where tools and applications live side by side.

Structured editing can show benefits in learnability, tool building, and editing efficiency in programming. However, creating a usable structured editor is laborious and demanding, typically requiring tool builders to manually create or adjust editing interactions. We present Sandblocks, a system that allows users to automatically generate structured editors for every language with a formal grammar available. Our system's input reconciliation process acts onarbitrary syntax trees to provides consistent interactions across our generated editors. Our editors' editing experience is designed to be familiar to users from textual editing but, compared to previous work, requires no manual annotation in the grammars. We demonstrate our editors' usability across languages through a user study (N=18). Compared to conventional text editors, even with minimal training, participants only took on average 21% (JS), 34% (Clojure), and 95% (RegExp) longer and reported that editing felt natural with a score of 6/7.

Researchers conducting studies on programming tools often make use of maintenance tasks. The complexity of these tasks can significantly influence how participants behave. At the same time, the complexity of tasks is difficult to pinpoint due to the many sources of complexity for maintenance tasks. As a result, researchers may struggle to deliberately decide in which regard their tasks should be complex and in which regard they should be simple. To help researchers deliberately influence task complexity, we discuss different factors of task complexity. We draw these factors from 23 selected and 39 surveyed studies on programming tools. We arrange the factors according to a task complexity model from ergonomics research that we adapt for maintenance tasks. We illustrate the application of the factors through an example critique of a task design. In the end, task complexity might always be too complex to be fully controlled. Nevertheless, we hope that our discussion helps other researchers to decide in which dimensions their tasks are complex and in which dimensions they want to keep them simple.

Code itself is abstract, which makes it often difficult to understand – sometimes even by the programmers that wrote it. When working with or thinking about code, programmers thus often resort to concrete values and execution traces to make the abstract more tangible. Such approaches like exploration scripts in a workspace or unit tests of a test suite are already very helpful, but still lack a convenient conceptual and technical integration into core development tools, leaving such examples and the code they refer to too far apart. Example-based programming like Babylonian Programming aims at offering the benefits of concrete, live examples directly in program editors, interleaved with the code it supports, to shorten feedback loops and reduce the need for context switches coming with changing tools. However, Babylonian Programming and its tools currently focus on a local perspective on code exploration, but do not yet extend to messages sent outside a particular unit of code and with that do not yet directly support feedback on more dynamic properties of a running program / system. We developed Probe Log, a Babylonian Programming tool that extends the benefits of example-based programming to scenarios that span across multiple procedures. It provides a linear view on the dynamics of evolving examples beyond a local perspective.

Researchers conducting studies on programming tools often make use of maintenance tasks. The complexity of these tasks can influence the behavior of participants significantly. At the same time, the complexity of tasks is difficult to pinpoint due to the many sources of complexity for maintenance tasks. As a result, researchers may struggle to deliberately decide in which regard their tasks should be complex and in which regard they should be simple. To help researchers make more deliberate decisions about the complexity of their tasks, we discuss different factors of task complexity. We draw these factors from previous user studies on programming tools as well as from a task complexity model from ergonomics research that we apply to maintenance tasks. In the end, task complexity might always be too complex to be fully controlled. Nevertheless, we hope that our discussion helps other researchers to decide in which dimensions their tasks are complex and in which dimensions they want to keep them simple.

Debugging is an essential part of software development. Numerous tools and techniques to improve debugging have been proposed in research or developed in the industry. However, only a few of those see widespread use, and debugging only rarely is a primary teaching subject. To promote debugging as a distinct skill, we propose Competitive Debugging , where participants compete on who can repair a failure the fastest or the most comprehensively. We further propose a format for debugging contests aimed at attracting and engaging participants to motivate them to improve their debugging skills. In our proposed format participants simultaneously work on the same failure or observe fellow participants during their debugging activity. To evaluate the format, we ran two pilots and one main event. We found that the format prompted participants to reflect on their debugging process, that the format allowed them to compare their debugging approaches to others through post-round discussions on their various approaches, and that the format was enjoyable and engaging for all participants. We present our format of a debugging contest, an evaluation of the trial runs we performed, and give guidance for other people who consider hosting a Competitive Debugging event. Ultimately, we aim to provide developers with opportunities to improve their debugging skills. Our observations indicate that Competitive Debugging can provide such opportunities to train debugging techniques and learn new tools.

Programmers often use examples with concrete values to better understand code. Code by itself is abstract, which empowers it to be used for a variety of uses, but can be difficult to grasp by developers. Babylonian Programming addresses this by allowing programmers to concretize their code by defining and visualizing examples directly in the code itself while editing.

Programmers often use examples with concrete values to better understand code. Code by itself is abstract, which empowers it to be used for a variety of uses, but can be difficult to grasp by developers. Babylonian Programming addresses this by allowing programmers to concretize their code by defining and visualizing examples directly in the code itself while editing. Currently, Babylonian Programming implementations such as Babylonian/S require programmers to define examples manually. For examples containing small objects this is straightforward, however when creating large or complex objects it is not. Sometimes, workarounds such as copying existing code pieces or trying to recreate existing objects are used to reuse information already present in the system, but these workarounds can be error-prone and also time-consuming. In this paper, we propose Example Mining to address this issue by providing techniques and integrated tools to mine examples from existing sources similar to concepts from run-time tracing and test case extraction. Example mining introduces concepts to mine examples from tests, debugging sessions, and traces of actual usage of the system under development. All tools were implemented for Babylonian/S in Squeak/Smalltalk. We demonstrate the usefulness of the tools through walkthroughs. Our tools provide examples for many methods immediately and automatically. As a consequence, programmers have more immediate access to dynamic feedback on their abstract code, making code comprehension and debugging more effective.

Ideally, programs are partitioned into independently maintainable and understandable modules.As a system grows, its architecture gradually loses the capability to accommodate new concepts in a modular way.While refactoring is expensive and not always possible, and the programming language might lack dedicated primary language constructs to express certain cross-cutting concerns, programmers are still able to explain and delineate convoluted concepts through secondary means: code comments, use of whitespace and arrangement of code, documentation, or communicating tacit knowledge.Secondary constructs are easy to change and provide high flexibility in communicating cross-cutting concerns and other concepts among programmers.However, such secondary constructs usually have no reified representation that can be explored and manipulated as first-class entities through the programming environment.In this exploratory work, we discuss novel ways to express a wide range of concepts, including cross-cutting concerns, patterns, and lifecycle artifacts independently of the dominant decomposition imposed by an existing architecture.We propose the representation of concepts as first-class objects inside the programming environment that retain the capability to change as easily as code comments.We explore new tools that allow programmers to view, navigate, and change programs based on conceptual perspectives.In a small case study, we demonstrate how such views can be created and how the programming experience changes from draining programmers' attention by stretching it across multiple modules toward focusing it on cohesively presented concepts.Our designs are geared toward facilitating multiple secondary perspectives on a system to co-exist in symbiosis with the original architecture, hence making it easier to explore, understand, and explain complex contexts and narratives that are hard or impossible to express using primary modularity constructs.

Creating structured editors, which maintain a valid syntax tree at all times rather than allowing to edit program text, is typically a time consuming task. Recent work has investigated the use of existing general-purpose language grammars as a basis for automatically generating structured editors, thus considerably reducing the effort required. However, in these generated editors, input occurs through menu and mouse-based interaction, rather than via keyboard entry that is familiar to most users. In this paper we introduce modifications to a parser of general-purpose programming language grammars to support keyboard-centric interactions with generated structured editors. Specifically, we describe a system we call partial parsing to autocomplete language structures, removing the need for a menu of language constructs in favor of keyboard-based disambiguation. We demonstrate our system's applicability and performance for use in interactive, generated structured editors. Our system thus constitutes a step towards making structured editors generated from language grammars usable with more efficient and familiar keyboard-centric interactions.