Is ReactiveX considered reactive programming? [closed]

Question

From ReactiveX introduction page:

It is sometimes called “functional reactive programming” but this is a misnomer. ReactiveX may be functional, and it may be reactive, but “functional reactive programming” is a different animal. One main point of difference is that functional reactive programming operates on values that change continuously over time, while ReactiveX operates on discrete values that are emitted over time.

Meanwhile, from Wikipedia's Functional Reactive Programming page, ReactiveX is listed in the "Implementations" section:

Implementations[edit]

• cellx, Ultra-fast implementation of reactivity for javascript
• Elm, FRP language that compiles to HTML, CSS, and JavaScript
• Frappuccino FRP implementation in Ruby
• Flapjax, behavior/event FRP implementation in JavaScript
• Reactive.jl, FRP implementation in Julia
• ReactiveX, FRP implementation in multiple languages, including Java, JavaScript, Python, Swift and many more
• reactive-banana FRP implementation in Haskell
• ReactiveCocoa FRP implemented in Swift and Objective-C
• ReactiveKit FRP implemented in pure Swift
• Reflex FRP implementation in Haskell
• Scala.Rx FRP implementation in Scala (and Scala.js)
• Sodium, FRP implementation in C#, C++, Haskell (deprecated[12]), Java, > Rust, and Scala
• Yampa FRP implementation in Haskell

I quite understand what ReactiveX does, and also did some researches about "Reactive Programming" and "Functional Reactive Programming", but I still can't distinguish the relationships between them.

In fact, I kind of believe that Wikipedia page is a misnomer, or incorrectly listing the examples in the "Implementations" section since I know that cellx and ReactiveX (which is both listed in the examples) is built to solve completely different problems.

Answer 1

Author of the reactive-banana library here.

The key distinction between functional reactive programming (FRP) and reactive programming (RP) is that the former has a well-defined denotational semantics, usually obtained from the types

type Behavior a  ~=  Time -> a
type Event    a  ~=  [(Time, a)]

while the latter does not have a well-defined denotational semantics. In particular, all implementations of RX that I know suffer from the problem that merging event streams is non-deterministic: When the streams contain simultaneous events, then sometimes one occurrence is merged before the other, and sometimes the other way round.

Moreover, the statement that "FRP operates on values that change continuously over time" is both subtly incorrect and not the key difference:

• First, the most probable parse for this statement is that "Behaviors are continuous functions Time -> a", which is not true: Behaviors can be discontinuous, for instance they can be step functions. What is true instead is that Time in FRP is usually taken to be a real number, i.e. a continuum of values.
• Second, it is perfectly possible to have FRP where time is discrete. That is not the key difference to RP, instead it is all about whether your operations on values have a well-defined denotational semantics or not.