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.

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.

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.

Game development benefits from short iterations, as it is often concerned with how a game will feel like; something that is hard to anticipate. Live programming aims at reducing the length of iterations during software development to allow for faster exploration and improve program comprehension. We propose a live game development environment providing a more general live programming workflow in game prototyping. The environment supports developers in two aspects: how will a code change affect the look and feel of the game and how does the behavior of the game relate to its code? The proof-of-concept environment ensures short feedback cycles by always keeping the game running while it is being developed. We propose several mechanisms to work with the running game, for example, programmers can automatically replay situations in the game by using an explicit notion of snapshots. We tentatively demonstrate the effectiveness of the live programming features in the context of the development of game prototypes of different genres.