SpaceTime Programming: Live and Omniscient Exploration of Code and Execution

Abstract

Programming environments typically separate the world of static code from the dynamic execution of programs. Developers must switch between writing code and observing its execution, often with limited tools to understand the relationship between code changes and runtime behavior. Several paradigms and approaches exist to bridge this gap, including exploratory programming for comparing code variants, live programming for immediate feedback, and omniscient debugging for exploring execution history. However, existing solutions tend to focus on specific aspects and one specific paradigm rather than providing a fully integrated environment with multiple capabilities. This paper introduces \spacetime Programming, a novel approach that unifies these paradigms to create a programming model for exploring both code modifications and execution flow. At the core of our approach is a trace mechanism that captures not only execution state but also the corresponding code changes, enabling developers to explore programs in both space (code variants) and time (execution flow). As a proof of concept, we implemented a Python library supporting SpaceTime Programming and applied it in two contexts: a live omniscient debugger and a Pygame game development tool, showcased through a Flappy Bird-like game. We further evaluated SpaceTimePy on five real-world Python projects, finding performance overhead ranging from 35% to 150% on test suites.

Figures (12)

• Figure 1: Example of exploration of time (states of the program) and space (variants of code) on a binary search function.
• Figure 2: Exploration through time and space: current approaches address either the space dimension (exploratory/live programming) or the time dimension (omniscient debugging), but not both simultaneously
• Figure 3: The SpaceTime development workflow in four steps. ① The developer runs the program and records an execution trace. ② The developer selects an execution frame (a sub-portion of the trace) and inspects states to understand program behavior over time. ③ The developer modifies the code and replays the selected execution frame with the new code variant $C'$, while mocking external events from the original trace. ④ The two execution branches are aligned in time and compared state by state, allowing the developer to observe how the code change affects behavior within the same execution context.
• Figure 4: Illustration of the three operations defined on traces. The blue box represents the inspection of a state ($view(s_4)$), the red box shows a comparison between different code variants ($compare(s_2, s'_2)$), and the green arrow illustrates a replay starting from a given state with replication of selected events ($replay(\{s_1, s_2, s_3\},\{E_1, E_2, E_3\}, C_1)$).
• Figure 5: SpaceTimePy instrumentation example for move_player: function-level monitoring (left) records one state per call, while line-level monitoring (right) records one state per executed line.