Reactive programming
Reactive programming is a programming paradigm oriented around interactive data flows. This means that it should be possible to express interactive data flows with ease in the programming languages used.
For example, in an imperative programming setting, would mean that a is beeing assigned the result of in the instant the expression is evaluated. In reactive programming it could instead mean that we set up a dynamic data-flow from and to . Whenever the value of or is changed, then is automatically updated.
Reactive programming has foremost been propposed as a way to simplify the creation of interactive user interfaces and animations, but is essentially a general programming paradigm.
Data flow differentiation
In RP, ideally all data changes are propagated instantly, but this can generally not be assured in a realistic computational environment. So in the reactive programming paradigm, it might be necessary to distinguish different parts of the data flow graph, which have different evaluation priority. This could be called as diffrentiated reactive programming.
For example, in a word processor the marking of spelling errors need not be total in synch with the inserting of characters. This is a case where diffrentiated reactive programming potentially could be used, so that we could describe which data-flow that needs to be instant, and which can be delayed.
However, diffrentiating different areas of the data flow graph introduces a lot of additional design complexity. For example, how to define the different data flow areas, and how to handle invalidation in the border between different data flow areas.
Evaluation models of RP
Evaluation of FRP programs is not necessarily based on how stack based programming languages are evaluated. Instead, when some data is changed, the change is propagated to all data that is derrived partially or completley from the data that was changed. This change propagation could be achieved in a number of ways, where perhaps the most natural way is an invalidate/lazy-revalidate scheme.
One reason it would be problematic to just naively propagate a changes using a stack, is because of potential exponential update complexity if the data structure has a certain shape. One such shape can be described as "repeated diamonds shape", and has the following structure: An->Bn->An+1, An->Cn->An+1, where n=1,2...
One inherent problem for RP is that most computations that would be evaluated and forgotten in a normal programming language, needs to be represented in the memory as data-structures. This could potentially make RP memory consuming. However, research on what is called Lowering, could potentially overcome this problem. [1]
On the other side, RP is a form of what could be described as "explicit parallellism", and could therefore be beneficial for use on parallell hardware.
Reactive Imperative Programming
It is possible to fuse reactive programming with ordinary imperative programming. In such a paradigm, there would be imperative programs operating upon reactive data structures. Such a setup is analogous to constraint imperative programming, but where constraint imperative programming manages bi-directional constraints, reactive imperative programming just manages a-cyclic data-flows. Reactive imperative programming could be seen as the smaller brother of constraint imperative programming.
Object Oriented Reactive Programming (OORP)
OORP is a combination of object oriented programming and functional reactive programming. Perhaps the most natural way to make such a combination is as follows: Instead of methods and fields, objects have reactions that automatically reevaluate when the other reactions they depend on have been modified.
If an OORP programming language maintains its imperative methods, it would also fall under the category of imperative reactive programming.
Functional Reactive Programming
Functional reactive programming is reactive programming in the settings of functional programming langauges.
Similarities with Observer pattern
No doubt, reactive programming has principal similarities with the Observer pattern commonly used in OOP. However, integrating the data flow concepts into the programming langauge would make it easier to express them, and could therefore increase the granularity of the data flow graph. For example, the observer pattern commonly describes data-flows between whole objects/classes, whereas OORP could target the members of objects/classes.
The stack based evaluation model of common object orientation is also not entirely suitable for data flow propagation, as occurances of the "repeated diamond shape" in the data structures could make the program face exponential complexities. But because of its relatively limited use, and low granularity, this is rarely a problem for the observer pattern in practice.