Target
Bc. thesis, Master thesis or Research project
Contact

Programs are created not just by writing code, but by interacting with rich stateful programming systems or developer environments. Programming systems still include code, but they also encompass live interactive previews, structure editors, runtime environment and other developer tools. Thinking about programming systems, rather than just languages, can give us new ideas about making programming easier, trustworthy and accessible.

The ideas below are open-ended. They can be used as a starting point for designing a novel programming system. For a project or thesis, we could focus on one or two of those, build a prototype for a suitable application domain and evaluate the result in an appropriate way, e.g. by formailizing the design or developing substantial case study.

If you are interested, please get in touch to discuss the details!

  • Simplifying programming by working with concrete values - When we program, we typically work with abstract variables. But what if we were writing code only once we have concrete values for all our variables? That way, the programming environment could help us by looking at the concrete (sample) inputs. Something like this already happens in a number of places. A debugger may let you inspect values and edit code, a Jupyter Notebook lets you load concrete data before writing more code, and the Darklang project uses this idea when writing REST handlers (see Office Sign-in Application demo). The idea is to design a programming system that lets you easily construct programs by starting form concrete values.

  • Understanding programs by treating them as sequences of interactions - When programming, we invoke refactoring tools, copy code snippets, write and run tests or paste code into a REPL to test it, but the programming environment does not know about this! The idea of this project is to represent programs not as source code but as sequences of interactions with environment. This allows many interesting things. The programming environment can give you better hints (based on the result of running a code snippet or a test), merge conflicts get easier (renaming a variable in many places is just a single edit) and you can display a single program in multiple different views. The idea would be to develop a prototype programming system and explore capabilities of this new representation. See also the Histogram project for a few more ideas.

  • Bringing together program evaluation and editing - As a variation on the above, it would also be possible to use the “sequence of interactions” idea not just to represent a program, but also its execution. That is, when a program runs, the execution would generate a sequence of edits that enact the evaluation step-by-step. This would make debugging easier (you can manually replay programs) and allow you to define logic by something like “macro recording”. The idea may be applicable, for example, to programming education (you can manually simulate execution to understand it better).

  • Explainability via meta-programming over execution traces - In LISP, code is data and so you can write code that manipulates code (meta-programming). But what if the execution trace of a program was also data, accessible to the program? This way, you could write programs that analyze (or even modify) their own execution. This can be used for explainable data visualizations (see Fluid: data-linked visualisations), to track provenance (explain what inputs contributed to what outputs) or analyze test failures (what part of execution invalidated the test assumption).

  • Tree-based Turing machine models of programming systems - Languages like Subtext represent programs as documents - tree structures that include both data and code (and possibly also the execution trace as in the project above). Execution of such programs is done by rewriting the document (tree). The idea of this project is to define minimal formal model of such execution - a “Turing machine” that operates on a tree (can shift to parent/child nodes and rewrite values in nodes) and use the formalism to define the meaning of a small Subtext-like programming language.

References