What is differential execution?

Question

I stumbled upon a Stack Overflow question, How does differential execution work?, which has a VERY long and detailed answer. All of it made sense... but when I was

Answer 1

I read all the stuff I can find and watched the video and will take a shot at a first-principles description.

Overview

This is a DSL-based design pattern for implementing user interfaces and perhaps other state-oriented subsystems in a clean, efficient manner. It focuses on the problem of changing the GUI configuration to match current program state, where that state includes the condition of GUI widgets themselves, e.g. the user selects tabs, radio buttons, and menu items, and widgets appear/disappear in arbitrarily complex ways.

Description

The pattern assumes:

1. A global collection C of objects that needs periodic updates.
2. A family of types for those objects, where instances have parameters.
3. A set of operations on C:
   • Add A P - Put a new object A into C with parameters P.
   • Modify A P - Change the parameters of object A in C to P.
   • Delete A - Remove object A from C.
4. An update of C consists of a sequence of such operations to transform C to a given target collection, say C'.
5. Given current collection C and target C', the goal is to find the update with minimum cost. Each operation has unit cost.
6. The set of possible collections is described in a domain-specific language (DSL) that has the following commands:
   • Create A H - Instantiate some object A, using optional hints H, and add it to the global state. (Note no parameters here.)
   • If B Then T Else F - Conditionally execute command sequence T or F based on Boolean function B, which can depend on anything in the running program.

In all the examples,

• The global state is a GUI screen or window.
• The objects are UI widgets. Types are button, dropdown box, text field, ...
• Parameters control widget appearance and behavior.
• Each update consists of adding, deleting, and modifying (e.g. relocating) any number of widgets in the GUI.
• The Create commands are making widgets: buttons, dropdown boxes, ...
• The Boolean functions depend on the underlying program state including the condition of GUI controls themselves. So changing a control can affect the screen.

Missing links

The inventor never explicitly states it, but a key idea is that we run the DSL interpreter over the program that represents all possible target collections (screens) every time we expect any combination of the Boolean function values B has changed. The interpreter handles the dirty work of making the collection (screen) consistent with the new B values by emitting a sequence of Add, Delete, and Modify operations.

There is a final hidden assumption: The DSL interpreter includes some algorithm that can provide the parameters for the Add and Modify operations based on the history of Creates executed so far during its current run. In the GUI context, this is the layout algorithm, and the Create hints are layout hints.

Punch line

The power of the technique lies in the way complexity is encapsulated in the DSL interpreter. A stupid interpreter would start by Deleting all the objects (widgets) in the collection (screen), then Add a new one for each Create command as it sees them while stepping through the DSL program. Modify would never occur.

Differential execution is just a smarter strategy for the interpreter. It amounts to keeping a serialized recording of the interpreter's last execution. This makes sense because the recording captures what's currently on the screen. During the current run, the interpreter consults the recording to make decisions about how to bring about the target collection (widget configuration) with operations having least cost. This boils out to never Deleting an object (widget) only to Add it again later for a cost of 2. DE will always Modify instead, which has a cost of 1. If we happen to run the interpreter in some case where the B values have not changed, the DE algorithm will generate no operations at all: the recorded stream already represents the target.

As the interpreter executes commands, it is also setting up the recording for its next run.

An analogous algorithm

The algorithm has the same flavor as minimum edit distance (MED). However DE is a simpler problem than MED because there are no "repeated characters" in the DE serialized execution strings as there are in MED. This means we can find an optimal solution with a straightforward on-line greedy algorithm rather than dynamic programming. That's what the inventor's algorithm does.

Strengths

My take is that this is a good pattern for implementing systems with many complex forms where you want total control over placement of widgets with your own layout algorithm and/or the "if else" logic of what's visible is deeply nested. If there are K nests of "if elses" N deep in the form logic, then there are K*2^N different layouts to get right. Traditional form design systems (at least the ones I've used) don't support larger K, N values very well at all. You tend to end up with large numbers of similar layouts and ad hoc logic to select them that's ugly and hard to maintain. This DSL pattern seems a way to avoid all that. In systems with enough forms to offset the DSL interpreter's cost, it would even be cheaper during initial implementation. Separation of concerns is also a strength. The DSL programs abstract the content of forms while the interpreter is the layout strategy, acting on hints from the DSL. Getting the DSL and layout hint design right seems like a significant and cool problem in itself.

Questionable...

I'm not sure that avoiding Delete/Add pairs in favor of Modify is worth all the trouble in modern systems. The inventor seems most proud of this optimization, but the more important idea is a concise DSL with conditionals to represent forms, with layout complexity isolated in the DSL interpreter.

Recap

The inventor's has so far has focused on deep details of how the interpreter makes its decisions. This is confusing because it's directed at trees while the forest is of greater interest. This is a description of the forest.