Re-unifying program state and definition

Why can’t program state and source evolve together? This used to be the case in Smalltalk images and other systems, but it’s completely gone from mainstream development.

From research journal entry /journal/2023-02-24/:

I was recently helping a friend with a Python project and we had to use a variable to store some text that we’d modify later in the program. She was surprised to learn that this wouldn’t change the text in the source code as well. I had to tell her that this was a reasonable assumption but that the field of programming is not yet ready for her futuristic ideas.

Current idea for exploring solution?

Experiment with a programming system which:

• Has no concept of “state”, only one of evolving program definition.
• Has first class support for branching and joining.

Why do we have the definition/state split?

Current programming practice is to define the program as plain text files, and have parts of running program state in memory or in a database. To make progress we have to understand what is so practical and attractive about this situation:

Programs have to start with a clean state.

Or otherwise: you want multiple running instances for any program—splitting state and definition makes this very easy.

Any state can also be put in the program definition

This means that program state changing over time could also be seen as metaprogramming. (This doesn’t feel like an original idea?)

Ideally any program state can be forked/joined

This includes both definition and state. This enables:

• Distributed, collaborative development.
• Speculative development which modifies the form (cf. schema) of the state, where later you want this form to be the “release” of the program.

Editor/programming system support

To pull off the un-separation of state and definition, the way you modify the program has to understand concepts like:

• Starting a program
• Resetting the state
• Joining branches of state
• Rebasing sections of history

Current/related work

• Smalltalk-style environments
• Any image-based programming environment? Common Lisp?
• Forkable/branchable databases, e.g.: Dolt, …
• Procedural style. Can do going back and forwards into history, every point in history is tied to the program definition at the time, images/logs are easily shareable. What I think it can’t do is merge edit histories. Was made possible because the environment was designed from the ground up to support it. I think they extended an old Visual Studio version as the editor.