1. Demonstration of Chords

One important aspect of composition in Expressions of Change is the idea of “history at any level”. A visual demonstration of that idea has been given in a previous article.

An even more direct mechanism is that of Chords: arbitrary hierarchical groupings of multiple related notes. The history pane of the editor already supports expansion & collapsing of chords. I would like to demonstrate this in a separate post (which should include animated gifs or a video).

2. Demonstration of static analysis

As part of Nerf 0 I have added quite a few examples of Static Analysis, such as unused variable analysis and undefined variable analysis.

One of the ideas of Expressions of Change is that the approach of the project makes it possible to say when an error occured as well as where. I would like to prove this idea “by example”.

For this it is necessary to create a visual representation of the static analyses, as well as a visual representation of their “deltas” (such as “variable becomes defined in this change”, “variable becomes undefined in this change”).

3. Demonstrate “understanding through refactoring”

It is one of the core tenets of Expressions of Change that code is in part understood in its historical context.

To illustrate this idea, as well as illustrate some cool CS concepts, it would be nice to record a number of explanations-through-refactoring using the editor.

Examples could be: the derivation of the Y Combinator by Mike Vanier, or my own explanation of the concept of a catamorphism using consecutive refactorings

4. Animations of “structure”

Expressions of Change introduces a full new dimension to programming: that of the time of programming construction. One question that follows directly from this observation is: “how can we visualize this dimension for our users?”

One answer is: by using animations, an example being the animations of how various histories relate to each other.

An even more direct animation would be: animating program change itself (rather than the more traditional form of visualising program change: the diff).

Such animations would at least provide an answer to the question: “how can be visualize that a move is just a move, rather than the combination of removing something and then re-adding it elsewhere?”

4.b] Such animations can also be tied to the idea of a (secondary) tree “following history”, i.e. showing the state at whatever point in time was selected in the history cursor.

5. Demonstration of self-applicability

I have complained in the past that modern Version Control Systems cannot be applied to themselves, i.e. that when rewriting history in Git, you lose precisely the ability to undo mistakes that Git gives you.

Expressions of Change does not suffer from this limitation: it is trivially possible to edit the expressions that constitute the description of history by using another layer of history.

It would be nice to actually demonstrate this in the editor.

//: # X. ‘Loosely coupled’ static analysis