Aspect-oriented programming: Some have suggested that the professional development of a programmer moves from procedural programming to object-oriented programming, then to aspect-oriented programming, and finally to functional programming. A canonical example of an aspect-oriented concern, for an aspect that is spread through the program in naïve usage, is logging. Aspect-oriented programming deals with cross-cutting aspects of programming, such as security, the diagnostic exposure of a state, and logging.

Declarative programming: One of the key concepts of functional reactive programming is that it is declarative rather than imperative. In other words, c = a + b does not mean take the present value of a, add the present value of b, and store their sum in c. Instead, we declare a lasting relationship that works a bit like C1 = A1 + B1 in a spreadsheet. If A1 or B1 changes, C1 is immediately affected by the change. What is stored in C1is not the value of A1 plus the value of B1 at the time of assignment, but something more lasting from which individual values may be obtained in a print on demand fashion.

Defensive programming: Analogous to defensive driving, defensive coding means writing code that behaves correctly when it is given something defective. Functional reactive programming is, among other things, an approach to either functioning correctly or degrading gracefully in the face of network issues and nonideal, real-world conditions.

Functional programming: Here, the term function has its mathematical rather than programming meaning. In imperative programming, functions can (and most often, they do) manipulate states. Hence, aninit()
function might initialize all of the data that a program initially needs to run initially. A function is something that takes zero or more inputs and returns a result. For example, f(x) = 3x+1, g(x) = sin(x), and h(x, y) = x'(y) (the derivative of x at y) are all mathematical functions; none of them command any manipulation of stateful data. A pure function is a function under a mathematical definition that excludes telling how to deal with states. Functional programming also allows and often includes, with the last derivative-based example, higher order functions, or functions that act on functions (in calculus, a derivative or an integral represents a higher order function, and iterative integration includes a higher order function that takes another higher order function as the input). Problems whose solutions center on abstract functions that operate on abstract functions tend to be more appealing to computer science types than something really used in the business world. The higher order functions explored here will be relatively concrete. You need not use higher order functions all the time, and once you've grasped the core concepts, they are not hard to use.

Imperative programming: Imperative programming is a common way of programming, and for the majority of programmers who are first taught imperative programming, it may seem the most natural way to work. Functional reactive programming's marketing proposal includes a live alternative to this basic approach. An alternative to the natural-seeming tendency towards imperative programming is found in functional reactive programming's declarative programming, pure functions (including higher order functions) in functional programming, and the time series of reactive programming.

Information hiding: Steve McConnel's Code Complete describes several methodologies, and tells us which are optimal for different settings (the sweet spot for procedural programming is on smaller projects than on object-oriented programming, for instance). For information hiding alone, his recommendation wasuse this as much as possible. In generic information hiding developments, a large project is approached by walling off secrets within the larger area, and larger secrets are divided by walling off subsecrets. A large portion of procedural programming, object-oriented programming, and functional programming alike is intended to facilitate information hiding. Information hiding is the software engineering concern behind the Law of Demeter, for example, you may have up to one dot in a method call (foo.bar())
, but not two(foo.baz.bar())
.

Object-oriented programming: Instead of having a monolithic architecture, a program is segmented into objects. These objects have their own methods and fields and may in turn be segmented into further objects. This offers an acceptable level of information hiding for larger projects than procedural programming, even if object-oriented programming more or less starts with procedural programming and builds on top of it.

Patterns: Patterns are not a recipe for good software, but at a higher level of human abstraction, they provide a way of talking about the best recurring solutions so as to avoid reinventing from scratch what has already been solved. Also, specific patterns are taken into the limelight, including MVC and now the Observerpattern, which is often not mentioned in relation to reactive programming despite being a founding ingredient.

Procedural programming: Procedural programming is one of the oldest of the methodologies mentioned, and it was meant to provide some order to the spaghetti code fostered by the even older goto-based flow control. Perhaps we can criticize procedural programming for not doing enough once object-oriented programming, aspect-oriented programming, and object-oriented design patterns are available. It is the right thing to move on from procedural programming when you have tools to push further than procedural programming from a rat's nest of gotos, the pointer as the goto of data structures, and so on.

Reactive programming: Suppose functional programming is, in large measure, programming where functions have first-class status and it is possible to make higher order functions (functions that act on other functions as input). Then reactive programming is, in large measure, programming where time series (functions that have different values over time) have first-class status. For music, games, user interfaces, and some other use cases, calculating the right value for the present moment is an area where reactive programming shines.

Functional reactive programming: Functional reactive programming is reactive programming built onfunctional building blocks, and in which both functions and time series are first-class entities. There are some useful, and surprisingly simple, functions that act on one time series to provide another time series from it (either of these series can be acted on by other functions on time series). One of the major selling points of functional reactive programming is that it provides a more graceful and much more maintainable approach than following your nose straight into the callback hell.