A heavy-duty principle of functional programming is flows, or piping data in the same vein as Unix console programs pipe data. In functional programming currying and composition facilitate the piping of data. The data we're referring to is usually some sort of sequence like an array or a vector. It's a data structure with a limited supply of items. Let's ignore lazy sequences. Having a limited supply of items, we use a pull model; each item in the data source is pulled and processed and passed through the processing pipeline.

Functional Reactive Programming is the same concept, but rather than thinking in terms of a data structure with a limited supply of items, one thinks of the data source as having a potentially infinite number of items. We flip control. Instead of the pipeline pulling items from the source. The originator pushes items into the pipeline at some future time. There is a potential that the flow will be depleted. (This is signaled with a closed message of some sort.)

The key idea here is that we still have input, process, and output. In normal FP we pull items into the process. In FRP we push items onto the process asynchronously in most cases. All of it is functional. All of it is flow based. In both situations one has the ability to compose the transformations of data that are flowing along the pipelines.

If you look at Clojure's core.async, you'll see that originally the design attempted to include all the typical tools for pipeline processing as part of its api. Eventually Hickey realized the redundancy and developed transducers, a mechanism which allows one to build pipeline processors that are oblivious the manner of input (pull or push).

Functional Programming

There is a fairly long explanation to what is functional programming, but I will try and keep it short.

In functional programming, you manipulate functions just as easily as you manipulate other data values like integers and strings, we call this functions being a first class citizen. The concept behind functional programming is that each time you call a function with the same parameters, it returns the same result. In order to accomplish this, functional programming languages must not hold any kind of state. The advantage of this is that it makes code easier to test, more predictable, and therefore, in theory, more reliable.

Reactive Programming
Reactive programming is programming with asynchronous data streams. For example, your twitter feed would be a data stream, your click events, user inputs, caches, data structures. You listen to that stream and 'react' accordingly. So, reactive programming involves programming with time flow and computational events.

Functional Reactive Programming

With the two above concepts in mind, the idea behind FRP is to model things like user input in a more direct declarative way by making their behavior more explicit. FRP models change over time by introducing two data types 'events' and 'behaviors'. Where events represent a value at a particular time, and behavior represent values that vary continually over time. When combined this concepts in a functional way, your entire program becomes a combination of events and behaviors. FRP raises the level of abstraction of your code, so you can focus on interdependence of events that define business logic, rather than a bunch of fiddling around implementation details.

Fundamentally, functional reactive programming (FRP) is programming declaratively with time-varying values. The idea is to model things like user input and animations in a more direct, declarative way by making their behavior over time more explicit.

In a normal imperative program for something like a GUI, you model change over time implicitly in two ways: using mutable state and using callbacks. FRP models the same notions by introducing two data types representing values that change over time, events and behaviors:

• events represent a value at a particular time. For example, a keypress would be represented as an Event Char. Pressing the a key at time t would be represented as the pair (t, 'a'). In practice, we never program directly with events; instead, we deal with potentially infinite streams of events ordered by time. So a keyboard input would be a stream of Char events. You can think of streams as representing a value which only exists sometimes: the typed character only exists when the key is struck.
  
• behaviors represent values that vary continually over time. These are values that always exist but can be constantly changing. The mouse position is a perfect example: it would be a Behavior Point. The mouse always has a position, but when it's moving that position is constantly changing.

Conceptually, you can think of event streams as infinite lists of time value pairs and behaviors as functions from a time to a value. However, time is not usually explicit; instead, it is managed by the FRP runtime system. This means that your entire program is made by combining behaviors and events in different ways--you never ask for the value of something now but instead define how it behaves based on other time-varying values.

The advantage of this sort of programming is that it abstracts over managing values that change with time. It makes dependencies between different values more explicit and allows you for some very nice combinators. This makes it fairly easy to express your logic at a higher level instead of dealing with the implementation details of mutable state and callbacks.

My favorite combinator for illustrating the declarative nature of FRP is when. The idea is simple: given a Behavior Bool--a continuouisly varying boolean--we can use it to filter a stream of events. Here's an example adapted from a very simple game of life applet I wrote:

when (not <$> paused) (step <$ time) 

The idea here is very simple. paused is a behavior that tells you whether the game is paused or not. time is a stream of events from a timer with one event every n seconds. step <$ time just creates a stream of functions that advance the simulation by one turn every n seconds. The entire expression creates a stream of step functions every n seconds as long as the game isn't paused.

I like this particular example because it's simple and easy to relate to. Most of the other combinators are in a similar vein.

Your entire program in FRP ends up being a combination of events and behaviors like this--you start with some primitive ones like mouse actions and combine them to create your own. Finally, you just plug the events/behaviors into outpus as appropriate. For example, if you have a Behavior String, you can just plug that into a label and have the label update to the correct value automatically.

While FRP is probably most often used for GUIs, it can also be used for things like games, synthesizing music or even controllers for robots. It's a very nice technique for specifying reactive systems in general, which are systems that can continually respond to inputs.

Let's think about every line of code in programming as data. For example, the two variables declared below are data :

int x = 5;
int y = 2 + x;

Some data is hardcoded (like x), but most data has dependencies, it is computed from other data (like y). Let's illustrate this chain as y -> x.

Here's another example : when we click on the screen, we compute a color based on the click location, and display that color. The dependency chain would look like :

displayColor -> setActiveColorFromLocation -> clickEvent

How would this manifest as code? Well, we could, at some interval, query what the color to display should be. From this we need to call the function setActiveColorFromLocation, which will call the function clickEvent which could either block until the next mouse click or return the latest mouse click. This approach is used in games.

So we have that displayColor calls setActiveColorFromLocation calls clickEvent.

The more natural way to think about this, however, is not to have the display ask for a color, but have the mouse tell the display something has happened. The chain of dependency remains the same, but instead, we have a function call graph that is reversed : clickEvent calls setActiveColorFromLocation calls displayColor.

This reversed way of propagating events, the dataflow that goes from events to reactions, is the idea behind reactive programming.

The example above is commonly known as the publisher/subscriber model. In OOP, this is often implemented using the observer pattern and in functional programming, monads are a way to do this.

We have a publisher, which generates mouse click events. We have a subscriber, which wants to be updated whenever a mouse click happens. We can have multiple subscribers to one publisher (mouse clicks could also display a number on the screen). A subscriber can be a publisher at the same time, and trickle down events further down a chain of dependencies.

In summary, reactive programming is about writing code that define how to react to changes : user input, data coming from a stream, a change in the state of a system, etc.

Hopefully that makes sense, this is my first time attempting to explain reactive programming.

FRP's primitive is a signal: a value that changes over time. You know all about them.

Consider the cascading update of a spreadsheet as one plugs in different values. Each cell represents a signal (a value, usually a number in a spreadsheet) that changes over time (in response to other cells being changed elsewhere). Consider the grand utility of spreadsheets and how people from all walks have leveraged them. A spreadsheet is a composed formula with a grid-like representation, but the idea of a signal is neither bound nor constrained to spreadsheets. It can also be use in writing business applications or games. The key thing to consider when writing your program is what signals make sense in your domain.

In the domain of a business application, your primary signal is what the user is doing. Where is the mouse pointer, what buttons is he clicking, what actions is he initiating, etc. FRP is especially good at user interfaces.

In the domain of a game, you have all the same user-based signals you would have had in your business application. Additionally, you now have a time-based signal. This signal is constructed from the ticking of a clock. Each tick (passing second) sends out a series of signals known as frames per second. That time-passing signal is used to temporally transform the state of the game (e.g. apply the effects of gravity, velocity, etc.). From these signals the characters and props of your game spring to life. They're animated. Thus, FRP is good at animating.

Don't think of FRP as anything special. FRP is at it's heart just good old-fashioned Unix piping. You build FRP from feeds (i.e. inputs). Take all of things that a program is able to detect and use them to define signals. A signal is hardly more than your ordinary event (something happened!). All it adds in is some value. Thus, a signal is the offspring some determinate value and the events that tell us it changed.

Consider the mouse pointer position on the screen. It has some X and Y coordinates. When do these coordinates change? Well, obviously, when the user moves his mouse. Thus, whenever the user moves his mouse you just have to note the X and Y coordinates.

Throw out FRP. Write an old school program that just processes user activity inside an event loop. You still have the ability to track the X and Y of the pointer. You just do it on every iteration of the loop. In many of those iterations, the user may not be moving his mouse and thus there is no relevance to the X and Y, because it has not changed since a prior frame in which we will have already dealt with the effect. To get past this, you might track the last known position of the pointer and compare it to the position on the current iteration. Then whenever a change is noticed you will allow the program to process the effect.

The point is FRP is not magic. It's doing the same things we used to do from a different position. It is a style of writing programs. The same programs can be written without it using loops. Moving a step beyond loops, you add events (which just invert loops). Moving a step beyond events, you identify what values are meaningful to your program (these become your signals). Having signals, you have streams. Streams are like sequences (even arrays). The difference is that an array is finite where a stream is potentially infinite. Both are similar; however, one is processed via pulls (array) and the other via pushes (signal).

Having sequences (either arrays or signals) we can start building pipelines (mapping, filtering, mapcatting, etc.). This is where the "functional" part of FRP comes in. So while FRP is nothing special, it does by inverting the event loop offer a particularly interesting way of writing programs. It allows programmers to make further use of piping/flowing data. And from my perspective, programs that stream data are among the most beautiful. Why? They're supremely composable.

A signal is good for emitting a value an indeterminate number of times. If your program is using primarily signals that emit just once, FRP may not be the best fit. What you may want are promises.

FRP is good for programs where the input sources produce values in an erratic or unpredictable manner. We cannot predict what a user will do and when, thus FRP is good for programs that interact with users (or with outside forces). A microservice, for example, listens to the outside world, but has no idea of when it will be called upon.

Batch jobs, on the other hand, are less erratic, have known data sources and can be processed on schedule. The processing path is mostly linear. Functional programming pipelines remain useful, but the reactive part is missing.

Reactive, being the key word, implies that we're waiting to see what happens and responding to it. So whenever you have a program that is waiting around to process whatever might happen, turn to FRP.

Reactive programming solves a very trivial problem, i.e. handling data updates.

Let me elaborate this. let’s say you have an expression a = b + c, which means a is assigned the value of b+c . now let’s say some where in the code base b gets updated, and we want a to be always be updated whenever b or c is updated.

to solve this problem we use reactive programming. i.e. we employ some functions which tracks the changes in the application state, and whenever b or c is updated it updates a as well.

We can easily add reactiveness via RxJs (for javascript) or its derivatives.

As for the applications, it has many, to name a few, they would be Animation updates, data streams via sockets, mouse events, drag events, etc

What is Reactive Programming?

I really liked the definition given in the link Herhangi Biri posted (staltz/introrx.md).

Reactive programming is programming with asynchronous data streams.

To make the leap to what that means, you can think of how another asynchronous code, like Javascript, works.

In Javascript you have promises and callbacks. A promise/callback could be thought of as data streams that emit one event (the event which represents the completion of the previous function).

You could draw this on a timeline like so:
------------P>

Where:

• "---" is time passing
• "P" is the time when an event is triggered to run the promise
• ">" is the end of the stream

Reactive Programming takes this concept to the next level. Rather then having streams that close after 1 event, what if we had streams that could fire multiple events before closing? For instance:

• A stream of events every time your mouse moved
• A stream for when a key is pressed on the keyboard
• A stream for when network requests are initiated
• etc.

Those might look like this:
-----M---M----M--->
---K---K---K-------->
--R---------------R-->
(Where M is a mouse event, K is a key event, R is a request event)

Once you have all these things, you can then use operations like "map", "filter", "merge" (and more!) to transform these streams into other streams.

• You could merge the keyboard and mouse streams into a single stream representing keyboard and mouse events.
• You could filter the keyboard stream to create a stream which only contains 'enter' key events.
• You could map the network requests to a set of response handlers.

Reactive Programming is the process of setting up these data flows and linking their events to actions in the system.

I like to think of it like laying wires down in hardware. As soon as you change the signal on a wire, that change propagates to all the other connected components.

Why Should You Use It?

1. Reactive Code is easier to reason about
   Reactive code allows you to focus on interdependent events. This makes separation of concerns easier then reasoning about implementation details in a large system.
   
2. You avoid "Callback Hell"
   Events abstract away the need for explicit callbacks and the awful amount of nesting that comes with them. The result is cleaner, more readable code.
   
3. Models interactive apps nicely
   Modern apps are highly interactive. There's live feeds, ajax calls when buttons are clicked, synchronization of state between multiple clients. Data streams capture this functionality really nicely without having to build out your own massaging systems from scratch.
   
4. Better Usage Of Resources
   Since all your code is asynchronous, multiple tasks can be accomplished at the same time. This better utilizes your computers resources and makes your applications run faster.
   

Where Should You Use It?

That's really up to you. It's a tool like anything else and you should apply it where it fits. Knowing where to apply it may be hard at first, but as it becomes more familiar, you'll gain a better intuition on how to use it.

No need to be like this :)

Good luck!

Edit/Disclaimer: I wrote this answer with libraries like Rx on my mind, which are sometimes mistakenly labelled FRP. I want to apologize to Conal Elliott - the inventor FRP - for repeating this mistake and thank him for pointing out. Consequently, my answer is not about FRP but about the observer/observable-pattern of Rx. Again, I am sorry for the inconvenience.

For my answer, I consider FRP a method to program asynchronous control-flow, the central idea is the duality of observable and observers.

An observable represent sequences of signals that happen while your application is running, like keyboard-strokes or incoming chat-messages. The counter-part — the observer — can perform side effects when certain signals are emitted. A common use-case for an observer is to update the user-interface or write something to a log. I think you could say, that observables model the passive aspects of a program, while observers model the active part of the program.

FRP does not enforce a central component that mediates the signals. It is the task of the programmer to connect the observers and the observables. Usually, this task involves creating intermediate observables by filtering out certain signals, buffering them, or merging multiple observables. An FRP library therefore offers some predefined functions for filtering, mapping, reducing, zipping etc. pp.

The Elm-Architecture (EA), on the other hand, provides a method to program asynchronous control-flow by focusing on state-transitions. The programmer specifies a global “message” datatype upfront, that represent all the possible signals that can happen at run time. The dual of a message is the command, which describes an action, that ought to be executed by the Elm runtime-system. On top of that, the Elm architecture also demands that the user defines an initial model, a view- and an update-function. Nothing of which has a counter-part in FRP. The initial model simply represents the initial application state. The update-function is the central component of EA: Whenever a message is emitted by the system, the update function gets called with the current application state (the model) and the current message. The update-function then computes the next application-state. Eventually, the view-function is called with the updated model and its returned Virtual DOM is applied to the browser’s DOM by the Elm-Runtime.

In EA there is no counterpart to the intermediate observers, that are central to FRP. The programmer does not construct his program by composing intermediate observers, consequently there are no analogous operations on messages to filter/map/reduce for observables. Instead, every state-change is mediated through the central update-function, which in turn has no counter-part in FRP.

However, these differences are not mutually exclusive, I’d even go so far and say that FRP and EA are orthogonal, they just set a different focus: FRP is focused on the interaction of components, while EA is focused on state-transitions within isolated components. Let me illustrate this with a diagram:

Image-Source: ReactiveX - Scan operator

Such diagrams are often used by the FRP community: The long arrows represent observables, the discs on the arrow represent signals. The central-box displays the function signature of the so-called scan function. The scan function is yet another function that is used to create intermediate observables from existing ones, just like filter/map/zip. In this case, the bottom observable is obtained by applying the scan function to the top observable. The various smaller arrows display how parameters are passed to the scan function. So, what does the scan function do? It’s similar to the reduce-function, but it emits all intermediate results as signals. It gets two arguments: A so called seed-value (the star) and a callback-function. The callback function is called for each signal in the input observable. The result of the callback-function is emitted as a signal of the output observable. On the first signal, the callback function is feet with the “seed”-value and the first signal. On subsequent calls, the callback function is called with the result from the previous call and the next message.

In a sense, the callback-function to the seed-function plays the same role as the update-function of the Elm Architecture: Remember, the update function is called with the current application state and the current emitted message. The callback-function to scan is called with the result of the previous iteration and the current signal. The “seed”-value is like the initial model of EA.

To sum it up: The key-difference of FRP and EA is in the perspective: In FRP the programmer concentrates on the interactions between the various application components. In EA the programmer is concerned with state-transition within an isolated component. I hope this makes sense.

FRP should be thought of as no different than a loop. In a loop, there are any number of things which might happen and for which must be tested. You might imagine you are programming a game or a business application.

In a game, the things that happen are often related to the passage of time. For example, if your character steps off a platform velocity will work to accelerate his descent until he lands on a lower platform. While gravity doesn't itself trigger any events, its force is felt and factored into in each frame (we're talking frames per second).

In a business application, the things that happen are usually not related to the passage of time. Instead they're related to what the user is doing. Where is the cursor on the screen. Is the user typing? What keys is he pressing? Has he clicked a button? The user activity is the spring from which the interesting events flow.

In both situations, a game or an app, there are things happening which must be monitored and handled. All of this could happen within the context of our main loop where we're constantly testing for conditions in order to identify what's happening. We will normally call certain functions in response to those happenings. Rather than confining ourselves to programming inside a loop, it can be useful to invert the loop and pass messages into a separate context. Within that context we call these messages events, we subscribe to them, and we handle them when they arrive. The loop still exists, we are just outside of it.

Reactive programming is no far stretch from ordinary event-driven programming. The main difference is that we treat events (or rather values directly related to them) like first class citizens. These values are emitted either as events occur or as time moves forward. We call these emitted values a signal. As the signal emits, we route its value down other channels (of our own devising) usually transforming (mapping) or filtering the values somehow. Essentially, we're piping values along a network of fire hoses and using those hoses as channels of communication and reacting to what's coming out. Back at the original source, we still have a loop and we're still testing for certain conditions. None of that's changed one iota. All that's changed is we've inverted the control structure. We've crossed a router with an event loop.

There is nothing about FRP that one cannot do in a typical loop; what changes, is the style by which it's done. There is nothing about this that is specific to the web. The web is just a platform like the desktop. Both situations can harness FRP. The web context is irrelevant. What's relevant is your program's needs. What interesting things are going on that need handling? How do you want to handle them? You probably won't write your own loop, but you could. You would probably start by handling events. If you decide it makes sense you could start routing those events and transforming them in order to define new kinds of events. Ultimately, you're composing an application out of events.

FRP provides a mechanism by which events can be composed into other kinds of events. That's all. What makes it functional its focus on mapping, filtering, and mapcatting to building up event networks out of events as data objects. It offers a style by which both games and apps can be built on the web or elsewhere. The only significant thing about games is that time is first class and a timer acts as a fountain from which the passage of time streams through the program as a series of events. In a business application, the time fountain will be omitted because it is not relevant to that programming model.

Functional is a programming paradigm where the emphasis is generally having programs operate similarly to mathematical functions - you use things like function composition and immutable data structures that are mostly side-effect-free. The result of a mathematical function(x^2 +y^2+ 2*x) is always the same for the same input value(in this case the “x” and “y” values) independent of any other “state” in the system - it is independent of any other function having to be called first, and is independent of e.g. the time when it is called. This leads ro simpler to predict behaviors e.g. when we have multiple threads and/or asynchronous behavior.

Reactive programming is a style of application building ,( often associated with user-interfaces) where the application is driven by something called data flow. In traditional interfaces there is a lot of information flowing in both directions - user clicking on buttons or lists and editing them, and there are links to all the other parts of the application that are used to update UI elements, and save any associated changes in the data. In the traditional interface there is a fight between the code that is performing the actions, and the updates that may well require an asynchronous response from a server before the UI can be updated. Forgetting to “tell” one part of the user interface to update can lead to visual inconsistencies , as can triggering an update prematurely and then having a subsequent network event modify it. It places the onus on the developer to be sure to update the necessary pieces, sometimes in the right order. It tends to be complex and somewhat error prone.

In reactive programming the focus is placed on having changes in the data drive all the subtleties of the user-interface in a more unified manner. Obviously the data itself needs to be updated by user interactions and e.g. data downloaded from a network, but the idea with reactive is that the user interface is “reacting” to data events(however changes occur) in a kind of unidirectional flow of data. The UI elements change when the reactive framework detects a change of state in the data itself. In this way the user interaction(button clicks, keystrokes etc. is simply applied to the data through whatever business rules are used to model the data. This unifies all the updates so that the developer focuses user actions on changing the data, and leaves the UI updating to be triggered by the data itself.

The tie-in with functional programming is that the state of theUI displayed essentially becomes a functional output of of the underlying data. You are no longer requiring the developer to remember to e.g. toggle theUI flag that says the data has been changed and the data needs a “Save” when the window is closed or toggle“Undo-x/Redo-x”menu items. You let the reactive framework do that for you based on the changes it detects in the data. You don’t end up with one part of the UI being inconsistent with another part.

Of course it doesn’t come for free - the developer has to define how the interface is to be updated for the various states of data, but it is “functional” - the same data input always displays the sameUI “output”, independent of when or how the data changed. It is reacting to the data.

It isn’t just “ordinary” UI interfaces that can be reactive. Other parts of a system - the “backend” itself(e.g. Database/File system) can be setup in a Reactive “chain” to store the various parts of the Data “Repository”.

Strongly typed is a separate thing from function or object oriented programming. It simply means that every value has a type. Most languages these days are strongly typed. You may mean statically typed, meaning that everything has a value that can be determined at compile time, as opposed to dynamically typed, where the type of a value may only be meaningful at runtime. There are OO languages which are statically typed and OO languages which are dynamically typed, and the same holds for functional languages.

Functional programming minimizes the use of side effects, choosing to write code that acts like mathematical functions (importantly, the same function called with the same arguments will yield the same value). As such, functional programming tends to avoid explicit state (variables) and instead uses "binding" -- names for values that don't change over their lifetime.

In addition, functional programming treats functions as "first-class values", so you can bind them to names, pass them into other functions as arguments, and return them as values from functions. This allows the programmer to write "higher-order functions" that encapsulate common patterns that differ only in specifics together. For instance, if you have a list of numbers, and want a list of their squares, this is fundamentally the same problem as if you have a list of invoices and wanted a list of their customers. This is typically encoded in a higher-order function called "map", which would get called with a squaring function in the first case, and an "extract-customer" function in the second case.

Object oriented programming (OOP) emphasizes the concept of "objects", which are things which have both state and behavior bundled together. An object is expected to manage its internal state, and interact with the rest of the program via "methods" or "messages" (depending on which school of OOP you follow. Smalltalk and Objective-C talk in terms of messages, C++/Java/C# talk in terms of public methods). Unlike in functional programming, it is perfectly expected that two identical method calls (messages) may yield different results, as they may depend on the internal state of the object (imagine an object modeling a bank account. You would expect the result of a get_balance() method to be different before and after a call to a withdraw(amount) method).

Many people feel that OOP is more an analysis technique than strictly a programming technique. Breaking down the problem into objects (or types of objects) and thinking about how the objects interact with each other is a good way to design a program, regardless of the language or techniques you use. As a curiosity, it should be noted that while C is not regarded as an Object Oriented programming language, the Linux kernel uses OO concepts and techniques in many parts of it.

While functional programming and OOP seem diametrically opposed when it comes to their treatment of state and functional types, more recent languages in each field

I am not familiar enough with reactive programming to comment on it. From what I've read, it feels like it is a separate concern from functional, object oriented, or typing issues.

From Reactive Programming to RxJava/ReactiveX Java:

Reactive Extensions is a library that follows Reactive Programming Principles to compose asynchronous and event-based programs with the use of observable sequence.Let’s have a look at RxJava basics and its real world example.

RxJava is a library that helps programmers to write asynchronous, concurrent, as well as resilient applications. With the use of RxJava, you write programs in reactive programming fashion. Here you will be provided with a quick introduction to reactive programming and RxJava.

Before we get into more details about it, let’s go through a real world example.

Real World Example for RxJava:

Let’s suppose you go to an ATM (Automated Teller Machine) to withdraw some money. You insert your debit/credit card into the machine then as per instructions you enter pin code, enter the amount you want to withdraw and click on the complete button. After clicking the button there can be two possible outcomes:

Either the ATM machine has the requested amount of cash, in this case it will dispense the cash. After which it will signal to you with a message about the successful transaction completion.

Or the ATM machine does not have sufficient cash, in this case it will signal with a message of transaction failure.

In the above example, the ATM machine is a source of cash and you are the consumer of cash. Based on the transaction details provided by you the cash is dispensed from the ATM machine. This example will now be used to explain the concepts below.

What is Reactive Programming?

The Reactive Programming is a style of programming in which you define a source as well as consumer of that data. Once you connect the consumer to the source, the library RxJava takes care of transferring the data, generated by the source, to the consumer.

We have three important terms in the definition of Reactive programming. Let’s discuss about each of these:

1. Source of data
2. Consumer of data
3. Connecting Consumer to the Source

RxJava in Action

Let’s understand all of the above-mentioned points with the help of an example code written using RxJava:

Source of Data

In ATM machine example, the machine along with the configured transaction details acts as the source. Similarly, in the above code example Obeservable<T> represents a source. An Observable can be created using any one of the many factory methods it provides. Observable.range(int start, int count) method is one of them. In the above example, the source will emit four numbers, starting from 1 through 4, and then it will finish.

Consumer of Data

Subscriber<T> acts as a consumer of data. RxJava uses onNext(T data) method on the Subscriber to push the data emitted by the source that is, Observable to the consumer of data that is, the Subscriber. In the above example, the consumer will print each received number onto the console. This is similar to the ATM dispensing bills or banknotes of different denominations.

Once all the data is emitted by the source, RxJava signals the completion using onComplete() method on the Subscriber. In the above example, the consumer prints completely and the completion is signalled using a successful transaction message.

If any error observed during the emission of data, RxJava library forwards the error to onError(Throwable e)method on the Subscriber. In the above example, the consumer handles the exception by printing error onto the console and the error is signalled using a transaction failure message.

Connecting Consumer to the Source

The connection between the consumer and the source is established using the subscribe(Subscriber s)method on Observable. In RxJava liberary, the computations defined as part of Observable and Subscriber get executed only when the connection between the two is established. This means that the computations are lazy. In the above example, the source will start emitting numbers only when a consumer is subscribed to it. In this example pressing the done button after configuring transaction details is analogous to the subscribing action. Till then no cash is dispensed by the ATM machine.

A concise version of above code ( using Java 8) will be like:

Summary

We saw that when writing programs using RxJava we have to define an Observable and a Subscriber and then connect the two using the subscribe method on the Observable. From here the Observable starts emitting data and RxJava starts sending the data received from the Observable onto the Subscriber. Hopefully this introduction should be enough for you to get started with RxJava.

FRP's "poster child" in web programming seems to be auto-complete:

http://jsfiddle.net/36b20tkp/

var $input = $('#textInput'), 
    $results = $('#results'); 
 
// Only get the value from each key up 
var keyups = Rx.Observable.fromEvent($input, 'keyup') 
    .map(function (e) { 
        return e.target.value; 
    }) 
    .filter(function (text) { 
        return text.length > 2; 
    }); 
 
// Now debounce the input for 500ms 
var debounced = keyups.debounce(500 /* ms */ ); 
 
// Now get only distinct values, so we eliminate the arrows and other control characters 
var distinct = debounced.distinctUntilChanged(); 
 
// Get suggestions, automatically cancelling old requests 
var suggestions = distinct.flatMapLatest(searchWikipedia); 
 
// Render 
suggestions.forEach( 
    function (data) { 
        $results.empty() 
            .append($.map(data[1], function (value) { 
                return $('<li>').text(value); 
            })); 
    }, 
    function (error) { 
        $results.empty() 
            .append($('<li>')) 
            .text('Error:' + error); 
    } 
); 

The reason is this shows orchestration of UI events and asynchronous server requests. I hear FRP is good with animation, too; as you can probably imagine, UI events, async requests and animation are widely used in web app clients. FRP is also useful server-side, where the streams are client connections with data coming from them and being sent to them in real-time.

The main difference between the above example and any simple solution you might come up with yourself without FRP is that:

• It will be correct: it will automatically cancel old requests that might have traveled for a longer time, preventing the bug where a late reply might replace the current results (since the user has continued typing and is already on a longer word). Unsubscribing from events is also automatic, so you don't need to worry about memory leaks when forgetting to unsubscribe event handlers (although this example doesn't need it).
  
• It won't hammer your server: it won't send one request per key stroke, but will wait for the user to slow down. This is called debouncing - from EE, where the conductive piece of metal in a button will physically bounce around for a bit before making full contact.
  
• It will still be easier to understand than a bunch of callbacks, even if you use promises. Apparently FRP is to promises what lists and arrays are to scalar values.

Here's a video that talks about how RxJS is used for the Netflix web app and Microsoft's Cortana: Bart De Smet, Jafar Hussain, Matthew Podwysocki: Pragmatic Rx (Channel 9)

Reactive programming is a technique that only makes sense for a few particular sorts of problems—explicitly modeling systems that change over time (ie “react”). In my mind, it’s solidly in the domain of libraries, not languages, and I’m surprised it’s becoming something of a buzzword!

Haskell the language is not reactive in any meaningful way. The language has no constructs explicitly designed for reactive programming and it is unlikely to get them.

Haskell, like most languages, does have libraries for reactive programming. Broadly speaking, there are two common categories for these libraries:

• functional reactive programming: abstractions that model time, great for anything from UIs to robotics to animation and computer music. Example libraries include Reflex FRP and sodium.
• streaming: libraries for efficiently working with streams analogous to RX-style reactive programming libraries. Examples include pipes, streaming and conduit.

In practice, the use cases for the two styles of reactive programming libraries are fairly distinct. FRP is primarily used for interactive UIs while streaming libraries are used for efficiently managing file and network IO.

I watched the whole video. I think that he means that in FRP time doesn’t flow(*), it is passed (as a value). This is the same as the statement he makes earlier (in the talk) about no need for communication when perceiving events. In FRP you have to receive an ‘event’ for a moment of time to be ‘materialised’. So in the ‘stadium analogy’ used in the talk, FRP would require every person in the audience to continuously receive a ‘time has changed’ event to ‘cause’ them to try and re-capture the new ‘state’ of the game (**)

I think there is a substantial difference between the STM model and FRP. The Lamport model is somewhere in between, you have flow and you have relative time.

Anyway I am not Rich Hickey and he may have meant something else.

(*) Generally FRP models have to talk about pushing or pulling for this reason.

(**) There is a metaphysical argument about the nature of time, special relativity and cognition, but I don’t think we can reach any conclusions about which one more closely represents ‘reality’. Besides we may care more about which one works better on a computer.

In functional programming you pipe the data through function and/or their composition without modifying any state outside function(s). So, you program is just a composition of functions, which do not have any side effects, you always get the same output giving the same input.

For example, you do kind of functional programming when pipe data in bash:

# cat README.txt | grep 'test' | sort 

In imperative programming you execute sequential statements, which modify running program state, step-by-step.

FILE_CONTENT=`cat README.txt` 
FILTERED_CONTENT=`grep 'test' <(echo $FILE_CONTENT)` 
SORTED_CONTENT=`sort <(echo $FILTERED_CONTENT)` 
echo $SORTED_CONTENT 

Code written in functional programming is somewhat more elegant.

Because user expectations of software has never been higher. Reactive programming is the realization that software must rise to the challenge of offering better user experiences than ever. It combines the concept of asynchronicity, with the observer and iteration pattern and standardizes the ways that producers and consumers of data must behave. When applied correctly, reactive programming gives us the concepts and tools to publish and consume data in ways that keep the system working well or degrades performance in a controlled manner in case of failure rather than letting everything come crashing down. Sort of like if the brakes of your car suddenly stop responding to your foot commands, do you want to still want to have control over the steering wheel or should the entire car become unresponsive at high speeds? This is part of what reactive programming tries to achieve. And it results in better systems and better user experiences.

Reactive programming and event-driven programming are both paradigms designed to handle asynchronous data streams, but they do so in different ways. Understanding their pros and cons can help you decide which approach might be more suitable for a particular project.

Reactive Programming

Pros:

• Declarative Code Style: Reactive programming allows for a more declarative approach where you express the logic of the computation without necessarily describing its control flow. This can lead to more readable and maintainable code.
• Backpressure Management: Reactive streams support the concept of backpressure automatically, which means the system can handle surges in data flow by controlling the flow of data and not overwhelming the consumer.
• Strong Library Support: There are robust libraries (like RxJava, Reactor) that facilitate reactive programming, providing extensive tools and operators to help manage complex data flows and transformation.
• Improved Scalability: By handling streams of data asynchronously, reactive programming can improve the system's scalability and responsiveness.

Cons:

• Steep Learning Curve: The paradigm shift to thinking reactively can be challenging, especially for those accustomed to imperative programming styles.
• Complex Debugging: Asynchronous data streams can make it difficult to debug applications due to the separation of the data producer and consumer and the transformation logic applied to the streams.
• Overhead: The abstraction layer that reactive libraries provide can introduce overhead, potentially impacting performance, especially if not properly tuned.

Event-Driven Programming

Pros:

• Highly Scalable: Event-driven architectures can easily scale horizontally, as components can be scaled independently based on the events they are interested in.
• Loose Coupling: Components in an event-driven architecture are loosely coupled; they only interact through events, which can lead to easier maintenance and evolution of the system.
• Real-Time Processing: Event-driven systems are well-suited for real-time applications where actions need to be triggered immediately in response to events.

Cons:

• Complex Flow Control: Managing the flow of events can become complex, especially as the system scales and the number of event sources and event types increases.
• Potential for Message Loss: If the system is not well-designed, there can be a risk of losing messages or events, especially in high-load scenarios.
• Difficulties with Testing: Testing event-driven systems can be challenging due to the asynchronous and decoupled nature of components, requiring sophisticated testing frameworks.

Conclusion

Both paradigms are powerful for building systems that handle asynchronous operations and data streams. Reactive programming is generally more suited for applications requiring robust handling of continuous data streams with a need for managing backpressure. In contrast, event-driven programming excels in scenarios where the application components must respond to discrete events and can be scaled independently. The choice between them often depends on specific project requirements and existing infrastructure.

Think of a classic pattern in computing: there is a publisher of data (a source) and a consumer of that same data (a sink). Now think of an application that deals with data at a large scale and should process that data in a manner that is resilient in the face of more data coming in, errors within the systems, or mere slow downs in the system. Should the producer keep feeding the consumer if it can’t keep up with the speed of data and overload it? Or should the user expect the program to remain unresponsive until the consumer catches up? If the consumer has crashed, should the publisher know about it or should it just keep pumping data for nothing? Alternatively, should another consumer be spawned to keep up with the data coming in?

Reactive systems make these concerns, (resilience, responsiveness, and scalability), a top priority. Starting from the reactive manifesto, to the reactive streams organization, rules have been put in place that define exactly how components should behave so that systems can be considered reactive. There are also frameworks and libraries, such as Rx Java, that offer constructs to process data in a reactive way.

So reactive programming makes systems react to changes in data flows.

I’m not going to cover the relative advantages, disadvantages and trade-offs. You didn’t ask and it’s the source of huge argument, frequently unhelpful. I’ll give an overview of the diffferences and a couple of simple examples at the end.

Characteristics of imperative programming:

1. Implicit state
2. Mutable variables and data structures
3. Procedures
4. Statements
5. Loops
6. Sentinel values, exit codes or exceptions
7. Control structures

Characteristics of functional programming:

1. Explicit state
2. Immutable variables and data structures
3. Functions
4. Expressions
5. Folds, reductions, traversals, recursion
6. Algebraic Data Types
7. Function composition, functions as values

I’ve lined up those lists so that the numbers match. Implicit state vs Explicit, Mutable vs Immutable and so on.

Functional programming can be a style which uses the characteristics from the second list (even in an imperative language). Functional languages are ones whose design is intended to enable and encourage (or even force) the use of functional discipline.

Statements do something which changes the state of the program (maybe changing the value of a global variable). Expressions return a value (often the result of a computation).

Procedures take (zero or more) parameters and then do something. Functions take (zero or more) parameters and then return a result. Functional programming encourages (in the case of Haskell, requires) pure functions - functions which make no change to the state of the program and which will always return the same result for a given value.

Imperative programs are mostly built from statements and procedures (they may also have functions but there is no requirement for those to be pure and no way to enforce it).

Functional code is constructed by composing smaller functions into larger ones and by creating chains of functions, where the output of one becomes the input of the next.

State in imperative programming is implicit because any statement could change any variable that is in scope. The state of the program at any point is the values of all the currently existing mutable variables.

State in (pure) functional programming is explicit because there is no need to keep track of all the variables in the program. State is all the values passed from one function to the next.

I’m not even going to try to explain point 7 in detail in one answer. I’ll finish with examples in Scala (a hybrid language which support imperative and functional style) to illustrate points 5 and 6. Loops and exceptions are, in any case, specific examples of control structures.

The idea is to find the largest number in a list, which can’t be possible if the list is empty.

// Imperative style with loop and exception to handle empty list 
def maxI (xs : List[Int]) : Int = { 
  val length = xs.length 
  if (length < 1) { throw new IllegalArgumentException } 
  var maximum = xs(0) 
  for (i <- 1 to (length - 1)) { 
    if (xs(i) > maximum) { maximum = xs(i) } 
  } 
  return maximum 
} 
 
// Recursive style with algebraic data type 
def maxR (xs: List[Int]) : Option[Int] = xs match { 
  case Nil => None 
  case List(x: Int) => Some(x) 
  case x :: y :: rest => maxR( (if (x > y) x else y) :: rest ) 
} 
 
// Fold (reduction) style with algrebraic data type 
def maxReduce (xs : List[Int]) : Option[Int] = 
  if (xs.isEmpty) { 
    None 
  } else { 
    Some( xs reduceLeft { (x, y) => if (x > y) x else y } ) 
  } 

You can write applications using either object-oriented programming or functional programming. You can even use both at the same time. The difference is how they organize the code and data, 2 different ways of thinking and solving problems.

Object oriented programming

As the name implies, you break down your program into objects. An object tries to resemble real world objects: it has data and it has behavior. For example, let’s say you want to make a pet store. You can have cats, cats would have data such as color, age, name, breed, and they have behaviors such as run, eat, jump, meow, etc.

Typically in OOP, you have classes, which describe objects, and objects are instances of classes. For example:

// this describes the abstract concept of a "Cat" 
// not individual cats 
class Cat { 
	// this is the data that cats have 
	var color; 
	var name; 
	var age; 
	var breed; 
	var weight 
	 
	// this are the behaviors: 
	void run(x,y) { 
		// code to run to x, y 
	} 
 
	void eat(food) { 
		// code to eat some food 
		weight = weight + food.weight; 
	} 
} 
 
// now these represent individual cats: 
var snowflake = new Cat(); 
snowflake.color = White; 
snowflake.name="Snowflake"; 
snowflake.age=3; 
 
// here is a second cat 
var garfield = new Cat(); 
garfield.color=Orange; 
garfield.name="Garfield"; 
garfield.age = 7; 
garfield.weight=40; 
 
// lets put snowflake on the left: 
snowflake.run(0, 0); 
// and lets tell garfield to move to the right: 
garfield.run(2, 0); 

Functional programming

In functional programming, your program is a function, as in the mathematical sense. A function receives one or more values and produces another value. Notice that in the mathematical sense, a function always returns the same thing for the same value, and that is true in functional programming.

To define a function, you can use other functions. You can even use the same function to define the function (recursion).

Suppose you want a program that tells you how many letters are in a string, you would write a function like this:

length "" = 0 
length (x:xs) = 1 + (length xs) 

This defines a function called length. Length of an empty string is simply 0, length of x:xs (the letter x, concatenated with the string xs) is 1 + the length of the rest of the string.

Differences

There are languages that are both object oriented and functional. But in general, OOP deals with objects and how they change their state based on their behaviors. Functional deals with functions, state never changes.

Functional programming is all about functions. (Yeah, right?) Well, actually it’s all about pure functions. Pure functions are functions without any side effects. In other words, they don’t write to a database, they don’t change the value of anything outside their scope and they don’t print anything. Reactive programming is often explained with an analogy to a spreadsheet: Imagine a cell that calculates the input of two other cells. Once you change one of the inputs, the sum updates as well. The cell reacts to the changes and updates itself. This is very similar to dataflow programming. Conceptually, the focus here lies on the flow of the data instead of on the flow of control. ReactiveX and similar libraries for reactive programming get sometimes labelled “Functional Reactive Programming”, but actually this is not quite right. ReactiveX is reactive and it employs many elements known from functional programming such as anonymous functions and methods such as map, filter and many others. However, Functional Reactive Programming has been clearly defined as something else.

Just expected, you “could” put this question verbatim to Google, but unless you already understand what the answer means it is just gibberish, I suspect most people would be confused just like you.

According to what Google returned, you may have noticed imperative has mention of a computer while functional doesn’t, more precisely it is difference of an imperative programmer vs a functional programmer. Imperatives have implicitly implied the state of the computer while functional does not care what the state of computer’s computation.

Do you know the term “Fly-by-wire”? Understanding that with respect to aircraft would help you understand imperative vs functional in the context of computer programming.

Reactive programming solves problems everywhere there is any interaction with something that can change, including every interaction with a human.

Here’s an interesting example for something that is very rarely done reactively: configuration files.

Most of the time, programs start, read configuration files and then proceed with the configuration in memory. But what happens if the user wants to change the configuration? When the program has been written in a purely imperative fashion, the only way, actually the way we use everyday, is to modify the config and restart the program.

But a reactive program could be designed to react to events coming from the configuration, with an event fired at startup, but also events fired by monitoring the filesystem.

The usual way isn’t reactive because it pretends that configuration files are something that doesn’t change. But they do, and reactive programming pushes you to actually model what can change as a source of events.