Reasoning about stateful programs is difficult, especially if they are long-lived or extensible. Reactive Demand Programming (RDP) helps by obviating or statelessly supporting many traditional uses of state that do not truly need to be stateful.
- real-time queues and caching are well served by signals in RDP. A stateful queue is only needed for tasks that take much longer than the queuing action (e.g. playing a list of songs). Signals are even better than simple value caches, since they tell us what the future of a value will look like, making the system very tolerant to ‘brief’ disruption.
- event detection and interpolation are both achievable by idiomatic use of
anticipate. Use of
delaywill buffer observations about the future, then
anticipatewill peek into that buffer. This is useful for gesture recognition, activity notifications, interpolating or smoothing animations, scheduling future use of resources, sharing and coordinating plans.
- reactive semantics allow RDP behaviors to statelessly maintain intermediate data models, scene-graphs, and decisions, so long as the source data remains available.
- RESTful semantics: RDP behaviors and idioms are eventless. Developers do not need to waste their efforts accumulating a signal just to keep a view of system state. They do need to accumulate signals to build new state (e.g. observe keyboard state to accumulate text), but not to view system state.
- duration coupling, a constraint in RDP where the response signal has the same duration as demand signal, eliminates need for reference-counting resource management and timeout lists. This idiom is further enhanced by use of
anticipatesince we can hold onto a resource that will be needed again in the near future.
- temporal semantics, with ad-hoc
delay, support a high level of parallelism and consistency, without relying on stateful synchronization primitives (no need for semaphores, mutexes, locks, transactions). Snapshot consistency (aka, glitch freedom) and even full determinism (with limited scope) are achievable with simple disciplines. Eventual consistency, exhibited by all RDP behaviors, makes a very nice safety-net. I will explain how this works in a later article on ‘vats’.
Use of state is still essential for many applications – e.g. there is no way to develop a text-editor without state. However, reducing need for these ‘accidental’ uses of state opens other doors in language design. Live programming, for example, benefits if all state is logically outside the application (allowing developers to maintain state across transitions), but putting state outside the application is difficult if developers are using a lot of volatile state in their idioms. I will write another article regarding state for RDP.