Avoiding State with RDP

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 delay and anticipate. Use of delay will buffer observations about the future, then anticipate will 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 anticipate since 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.

This entry was posted in Language Design, Reactive Demand Programming, State. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s