I enjoyed the post, but I think the proposed scope of reactive programming is a bit limited. What the author describes is, I think, more related to the concerns of "bidirectional programming"[1] and lenses[2]. Granted, I think those concerns do fit broadly under the umbrella of reactive programming.
Below is Prof. David Harel's (the inventor of statecharts, formalized as UML State Machines) general characterization[3] of a reactive system; reactive programming would then be any programming methodology, language or environment which aims to service those characteristics.
* It continuously interacts with its environment, using inputs and outputs that are either continuous in time or discrete. The inputs and outputs are often asynchronous, meaning that they may arrive or change values unpredictably at any point in time.
* It must be able to respond to interrupts, that is, high-priority events, even when it is busy doing something else.
* Its operation and reaction to inputs often reflects stringent time requirements.
* It has many possible operational scenarios, depending on the current mode of operation and the current values of its data as well as its past behavior.
* It is very often based on interacting processes that operate in parallel.
Comments
I enjoyed the post, but I think the proposed scope of reactive programming is a bit limited. What the author describes is, I think, more related to the concerns of "bidirectional programming"[1] and lenses[2]. Granted, I think those concerns do fit broadly under the umbrella of reactive programming.
Below is Prof. David Harel's (the inventor of statecharts, formalized as UML State Machines) general characterization[3] of a reactive system; reactive programming would then be any programming methodology, language or environment which aims to service those characteristics.
* It continuously interacts with its environment, using inputs and outputs that are either continuous in time or discrete. The inputs and outputs are often asynchronous, meaning that they may arrive or change values unpredictably at any point in time.
* It must be able to respond to interrupts, that is, high-priority events, even when it is busy doing something else.
* Its operation and reaction to inputs often reflects stringent time requirements.
* It has many possible operational scenarios, depending on the current mode of operation and the current values of its data as well as its past behavior.
* It is very often based on interacting processes that operate in parallel.
[1] http://www.cs.cornell.edu/~jnfoster/papers/jnfoster-disserta...
[2] http://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides...
[3] http://www.wisdom.weizmann.ac.il/~harel/reactive_systems.htm...