After Object-Oriented Programming and Functional Programming, Is Temporal Programming Next?
Ever since the first compiler was developed in 1952, the software industry has been on a relentless quest to keep software development from becoming out of control.
However, after nearly seven decades of software engineering, there seems to be one problem that our industry still has difficulty solving: (application) state management. When we realized that global state was a problem, we tried to manage state by fragmenting it into objects. When that didn’t work, some people decided that state was immutable anyway, while others started to explore a (reactive) programming model where state mutations are automatically bound to property changes via rigid relations/formulas. Even in finite “state” machines, state mutation is subordinate to any action taken, as if every system were as simple as a light switch. So, as of early 2018, we are still missing a uniform, agreed-upon way of managing application state!
Yet managing state is what makes computers valuable, far more than computation itself. The modern world only exists because of our ability to program computers to manage state; the reason why we have money in the bank, food on the shelves of grocery stores, or gas at the gas station is because computer systems enable us to know where things are, i.e. their state. We don’t go to the ATM with the apprehension of not being able to withdraw money, we don’t send trucks to pick up empty palettes, and airplanes don’t run out of fuel because they cannot land at congested airports.
Let’s try to sort this out. State management has three facets:
- Mutation
- State alignment (across processes)
- Persistence
Persistence is, for all intent and purposes, solved. SQL has won. Data is relational.
State alignment has been solved too (PouchDB/CouchDB being a great example), and is used increasingly due to the distributed nature of modern systems, but is not generally well understood or supported.
On the other hand, application state mutation is a mess. Of all the popular programming languages, none of them has provisions that would make a distinction between assignments and mutation, let alone being able to restrict mutations in relation to temporal constraints.
Turing Award winner Dr. Leslie Lamport has developed a robust theory of computation (TLA+) which provides some definitive insights on the way we could approach application state mutation. Dr. Lamport has, in essence, invented a new kind of state machine, quite different from finite-state machines, though the observable behavior (a graph of actions and control states) would be identical. Its core difference from any other programming model is the precise semantics of temporal logic which control the “steps” of a behavior.
- A state is an assignment of values to variables
- A step is defined as a pair of states
At a high level, the temporal logic is composed of three new operators:
- ‘ (Prime)
- ⌷ (Always)
- ∃ (different from the ordinary existential quantification operator)
At the core of the mutation model of TLA+ is the precise definition of an action:
- An action represents a relation between old states and new states, where the unprimed variables refer to the old state and the primed variables refer to the new state
and a behavior:
- The state function as an expression built from variables and constant symbols
- Next-state relation as all the possible atomic operation of the program
I have translated the TLA+ semantics into a software engineering pattern called the SAM Pattern (State-Action-Model). SAM decomposes business logic into actions, acceptors (next-state relation) and reactors (state function). The key to properly mutating the application state is to realize that the mutations happen as part of a formal “step” (action, mutation, state) and the role of actions is to compute a proposal to mutate the state (primed variables), not to mutate it directly. As such, actions can be checked for affordances, mutations can be isolated in a critical section of the program, and the resulting “state” can be communicated to any observer.
You can learn more about the SAM Pattern in this passion talk I shared at Offline Camp Oregon:
Editor’s Note: Participants at Offline Camp Oregon had diverse backgrounds and interests, ranging far beyond the Offline First approach that we came together to discuss. Through short passion talks, campers shared with us some of the hobbies, projects, and technologies that excite them. We’re sharing a taste of that passion with you here as a preview to our upcoming events.
