#### Effective visualisations of exploratory program execution

Modern programming languages and environments (e.g. REPLs and notebooks) often encourage an incremental style of programming in which programs are developed in a step-by-step fashion and programmers receive immediate feedback in response to the execution of individual program fragments. This style of programming is especially useful to experiment with new functionality, optimisations or (external) libraries. Exploratory programming is a style of programming going beyond incremental programming in which programmers experiment without developing towards a clearly specified goal, often undoing previous executions and executing alternative code fragments. Exploratory programming is especially popular among users without (extensive) software engineering expertise such as scientists, data analysts or other domain experts. However, existing programming environments have little support for this style of programming [1,2]. The goal of this project is to empower programmers by designing interface components and functionality that support exploratory programming and can be used in computational notebooks or integrated development environments (IDEs).

Earlier research at the Informatics Institute has resulted in a language-parametric back-end for exploratory programming maintaining a so-called execution graph: a structure that records all executed program fragments alongside the context in which they are executed and their effects [3,4]. As such, the execution graph contains all information needed to retrace the entire execution history. However, presenting all this information to the user is inefficient and potentially overwhelming. As a first step in this project, you can experiment with alternative presentations of the execution graph. For example, how can the entire execution graph be presented visually, given that it can potentially grow very large? Should perhaps only a certain portion of the graph be presented? What is the most effective way to give insight into the current execution state? And into the history of executed programs leading to the current state? These questions are to be answered through the design and evaluation of visual representations of (information in) the execution graph. These visualisations can then be made interactive, for example by allowing the programmer to revisit a previous program state or by running a replay of a chosen execution path in a step-by-step fashion.

[1] The Story in the Notebook: Exploratory Data Science using a Literate Programming Tool. https://doi.org/10.1145/3173574.3173748
[2] Exploration and Explanation in Computational Notebooks. https://doi.org/10.1145/3173574.3173606
[3] A principled approach to REPL interpreters. https://doi.org/10.1145/3426428.3426917
[4] A Generic Back-End for Exploratory Programming. https://doi.org/10.1007/978-3-030-83978-9_2