Journal entry for


I asked on the Future of Coding Slack whether anyone had ideas relating to the program state vs definition idea and some interesting links came up.

The entangled strands of time in software development

Nick Smith linked his Twitter thread, which shared many of the same thoughts I’m having, links to a paper: “The entangled strands of time in software development”, Matthias Hauswirth and Mohammad Reza Azadmanesh 2017.

This paper looks at what programmers need from their environment. I took some notes below.

Time travel & altering the past

On undo/redo resulting in a tree of history:

[…] keeping a mental model of the tree, and one’s place in that tree when undoing and redoing, is too taxing. After all, life is a sequence, not a tree. But then, life doesn’t even have an undo.

This quote makes it clear that making this tree user friendly is high priority if you want to build a system in which exploration is cost-free. Achieving this will make collaboration cost-free as well. Git has a hard time with this because of it’s lowest common denominator text support.

Reading this makes me remember my interest in non-linear undo work. I’ve seen some older papers on this but I don’t know how much it’s supported in actual applications these days. I wonder what a modern denotative approach looks like.

Source & documentation navigation

This reminds me of how even with a functional programming you want identity and relations to be able to address things like looking up which functions refer to which etc.

Program execution/testing/debugging

I’ve written about this here.

Source editing & version control

VC and edit history are currently not integrated. Instead they could present a unified interface with classic VC features such as commits being an extra feature on top of regular work.

Source editing & source navigation

Here they arguing that you could unify navigation with editing. Navigation usually has a separate web browser-like interface (back/forward). This means that “looking at something” should be in the history?

Same for documentation.

My thoughts

I love all the concerns put forward in this paper. It seems hard to implement without deeply integrating with the actual programming language being used. For example, to rebase history well, you have to know whether the history you’re copying makes sense in the current context.