Alas, with the good always comes the bad, and some of the reactions (sic) have no been quite so
positive. For example, consider the following I wrote:

[..] Adding reactivity to an object-oriented language is, at first blush, non-sensical and certainly causes confusion [because] whereas functional programming, which is per definition static/timeless/non-reactive, really needs something to become interactive, reactivity is already inherent in OO. In fact, reactivity is the quintessence of objects: all computation is modeled as objects reacting to messages.

This seemed quite innocuous, obvious, and completely uncontroversial to me,
but apparently caused a bit of a stir with at least some of the creators of ReactiveCocoa:

@Javi@kyleve lol, that’s the guy who said “OO is already reactive, so who needs FRP”

Ouch! Of course I never wrote that "nobody" needs FRP: Functional Programming definitely needs
FRP or something like it, because it isn't already reactive like objects are. Second, what I wrote is
that this is non-sensical "at first blush" (so "on first impression"). Idiomatically, this phrase is usually sets up a "
...but on closer examination", and lo-and-behold, almost the entire rest of the post
talks about how the related concepts of dataflow and dataflow-constraints are highly desirable.

The point was and is (obviously?) a
terminological one, because the existing term "reactivity" is being overloaded
so much that it confuses more than it clarifies. And quite frankly, the idea
of objects being "reactive" is (a) so self-evident (you send a message, the object reacts
by executing method which usually sends more messages) and (b) so deeply ingrained and
basic that I didn't really think about it much at all. So obviously, it could very
well be that I was wrong and that this was "common sense" to me in the Einsteinian
sense.

I will explore the terminological
confusion more in later posts, but suffice it to say that Conal Elliott contacted
the ReactiveCocoa guys to tell them (politely) that whatever ReactiveCocoa was, it certainly wasn't FRP:

I'm hoping to better understand how the term "Functional Reactive Programming" gets applied to systems that are so far from the original definition and principles (continuous time with precise & simple mathematical meaning)

A group of leading experts from industry and academia came together last fall at the invitation of IBM and ACM to ponder the primary areas of future needs in software support for object-based applications.

[..]

In the future, as you talk about having an economy based on these entities (whether we call them “objects” or we call them something else), they’re going to have to be more proactive. Whether they’re intelligent agents or subjective objects, you enable them with some responsibility and they get something done for you. That’s a different view than we have currently where objects are reactive; you send it a message and it does something and sends something back.
— The promise and the cost of object technology: a five-year forecast

But lol, that's only a group of leading researchers invited by IBM and the ACM writing in
arguably one of the most prestigious computing publications, so what do they know?
Let's see what the Blue Book from 1983 has to say when defining what objects are:

The set of messages to which an object can respond is called its interface with the rest of the system. The only way to interact with an object is through its interface. A crucial property of an object is that its private memory can be manipulated only by its own operations. A crucial property of messages is that they are the only way to invoke an object's operations. These properties insure that the implementation of one object cannot depend on the internal details of other objects, only on the messages to which they respond.
— Smalltalk 80, The Language and It's Implementation, p. 6

So the crucial definition of objects according the creators of Smalltalk is that they respond
to messages. And of course if you check a dictionary or thesaurus, you will find that respond
and react are synonyms. So the fundamental definition of objects is that they react to messages.
Hmm...that sounds familiar somehow.

While those are seemingly pretty influential definitions, maybe they are uncommon? No.
A simple google search reveals that this definition is extremely common, and has been
around for at least the last 30-40 years:

A conventional statement of this principle is that a program should never declare that a given object is a SmallInteger or a LargeInteger, but only that it responds to integer protocol.
— Design Principles Behind Smalltalk, Dan Ingalls 1981

But lol, what do Adele Goldberg, David Robson or Dan Ingalls know about Object Oriented
Programming? After all, we have one of the creators of ReactiveCocoa here!
(Funny aside: LinkedIn once asked me "Does Dan Ingalls know about Object Oriented
Programming?" Alas there wasn't a "Are you kidding me?" button, so I lamely clicked "Yes").

Or maybe it's only those crazy dynamic typing folks that no-one takes seriously these days? No.

Heck, even the Apple Cocoa/Objective-C docs speak of "objects responding to messages", it's
almost like a conspiracy.

By separating the message (the requested behavior) from the receiver (the owner of a method that can respond to the request), the messaging metaphor perfectly captures the idea that behaviors can be abstracted away from their particular implementations.
— Object-Oriented Programming with Objective-C -- Apple

Or maybe this is an old definition from the 80ies and early 90ies that has fallen out of use? No.

The behavior of related collections of objects is often defined by a class,
which specifies the state variables of an objects (its instance variables)
and how an object responds to messages (its instance methods).
— Design Concepts in Programming Languages, 2008 p 362

Methods: Code blocks that define how an object responds to messages.
Optionally, methods can take parameters and generate return values.
— Cocoa, by Richard Wentk, 2010

The main difference between the State Machine and the immutable is the way the object reacts to messages being sent (via methods invoked on the public interface). Whereas the State Machine changes its own state, the Immutable creates a new object of its own class that has the new state and returns it.
— Interface Design by Bill Venners

So to sum up: classic OOP is definitely reactive. FRP is not, at least according to the guy
who invented it. And what exactly things like ReactiveCocoa and Elm etc. are, I don't think
anyone really knows, except that they are not even FRP, which wasn't, in the end reactive.