
Reactive Programming is the New OOP - mattcarkci
http://dataflowbook.com/cms/?p=836
======
MetaCosm
... having channels doesn't have anything to do with Reactive Programming
([http://en.wikipedia.org/wiki/Reactive_programming](http://en.wikipedia.org/wiki/Reactive_programming)).
The implication that channels were added to Go to support it seems dishonest.

There is a very long thread on the Go list of a guy who is a fan of dataflow
grumbling about how design decisions made in Go make it a poor fit for
dataflow.

~~~
bkirwi
Sadly, 'reactive' \-- like OOP -- seems to be one of those words that gets
reinterpreted to meaninglessness. The definition I'm most familiar with, from
the Reactive Manifesto,[0] seems like it would fit Go's channels just fine...
but anything that puts Go and Erlang and Node.js in the same box might be too
broad to be useful.

[0] [http://www.reactivemanifesto.org/#reactive-
applications](http://www.reactivemanifesto.org/#reactive-applications)

~~~
pauldino
Maybe I'm missing something but that manifesto doesn't seem to have anything
at all to do with reactive programming, except that maybe you could use
reactive programming to help build "reactive applications".

------
ripter
This isn't even an article, just a guy saying the people complained about OOP
back in the day.

~~~
barkingcat
It doesn't even say what kind or what reactive programming is - just throws
out some random words ...

~~~
vanderZwan
I wasn't a coder back in the day, but wasn't that kind of what the main
criticism was in response the OOP movement back then as well?

------
Confusion

      It’s funny how similar the arguments against OOP and
      Reactive Programming are. 
    

It's funny how similar this argument in favor of Reactive programming is to
the arguments used in favor of other purported paradigm shifting trends that
never went anywhere. Aspect Oriented Programming anyone?

~~~
UK-AL
Aspects are used quite a lot in Java and C#. Simply to get around the
verbosity.

~~~
tlarkworthy
and in python they are function decorators.

------
chazu
Can someone tell me the key differences between the actor model and
reactive/dataflow programming? I haven't seen any references to erlang in
conversations about Reactive programming, which seems odd to me as erlang's
lack of shared state and message-passing seem like they fit the definition of
reactive programming.

~~~
jerf
They're basically unrelated. The actor paradigm is basically imperative
programming, with boundaries being put up between the actors, and the way you
cross the boundary is with a message. If that sounds too foreign, bear in mind
that while OO doesn't have to be an "Actor" and an actor doesn't have to be
"OO", they share a certain structural similarity, in that one of the primary
characteristics of working with an "object oriented" system is that you are
creating imperative islands of code, and the way you cross the barriers are
via method calls. Indeed back when OO was first being formulated you can see
the terminology was not settled yet, and you'll see method calls being called
"messages" even today in some OO communities.

The Actor model is basically OO, except that objects are given their own
execution contexts, whereas in OO there's one execution context that drives
the objects. You can do worse for your first design in Erlang than to break
your task into core objects exactly as you would for a high-level OO design
(don't put in all the little collection and iterator and other structure
classes, stick to the "high level" design), and use that to drive your process
design. It won't be perfect, but it's not a bad first pass. The profound
differences between one execution context and multiple also has subsequent
follow-on effects on the languages in question, and in what direction they
evolve, so in practice they feel quite different despite the underlying
similarities in the model.

Reactive programming is extremely different. There, values are defined as
functions on other values, intrinsically, such that if A is B + C, future
changes to B and C mean that A is automatically updated to the new B + C with
no programmer interaction. This is no longer imperative design; instead of
your program consisting of a huge set of instructions for the processor to
directly execute (no matter how gussied up that is by the syntax and semantics
of the local language), your program consists of a declaration of
relationships between values and how they evolve over time. The fundamental
operation of the programming language is no longer "Set value identified by X
to Y", but "Attach value X to value Y with update function Z".

As is always the case in the world of Turing Completeness, this can be
embedded into OO, or OO can be embedded into it, etc. all sorts of
combinations are possible. But it is a fundamentally different underlying
method for writing your program.

I would observe that A: this isn't new, which I say not because anyone is
claiming that it is but because it means that we can in fact draw on past
experience to examine it and B: our general experience with it up to this
point is that it often makes small tasks easier, even _much_ easier, but that
trying to create whole systems this way is often quite problematic. If you
think laziness in Haskell is hard to understand, just wait until you're trying
to understand a cyclic dependency graph in a data-binding environment (the
usual OO manifestation) or a spreadsheet, with the local bizarre adaptations
to try to make that sensible all interacting with each other in crazy
complicated ways. It's a useful tool, and I don't mean that as a mere
rhetorical sop, it really _is_ a useful tool to have in the belt, but I'm
deeply skeptical of it as a proclaimed savior of programming, or the Next Big
Paradigm. Our experiences with it up to this point have not been positive
enough to justify that claim, IMHO, and I haven't seen that there's been any
sort of big enough change in the landscape lately to justify that.

Compare to "functional programming", which has been the Next Big Paradigm for
a few decades now, but IMHO modern Haskell of the past 3-5 years really _is_ a
big enough advance to justify some examination on the topic. (I'm _not_ saying
Haskell is guaranteed to be the Next Big Thing, I'm just saying that there's
been enough action there to legitimately justify having a fresh look at the
situation.)

If you can point me at the big advance for reactive programming in question,
I'd love to have a look. I know the Haskell world has been fiddling with FRP
but I'm still underwhelmed by the efforts.

~~~
jarrett
> just wait until you're trying to understand a cyclic dependency graph in a
> data-binding environment (the usual OO manifestation) or a spreadsheet, with
> the local bizarre adaptations to try to make that sensible all interacting
> with each other in crazy complicated ways.

I think that may be a significant, fundamental problem with reactive
programming. The way these graphs are constructed is typically (necessarily?)
buried within the reactive programming framework, giving the programmer poor
visibility into what's actually happening. Maybe that problem can be solved,
but I suspect it might be intrinsic to reactive programming.

> I know the Haskell world has been fiddling with FRP but I'm still
> underwhelmed by the efforts.

I've test-driven some of those projects. Last I checked, the documentation was
extremely sparse, and the only examples were trivial. I haven't yet seen an
example of a useful Haskell app built with FRP. FRP has sometimes been
described as the silver bullet for doing stateful apps in a pure FP way. Maybe
it is, but for now, I'm sticking with pseudo-imperative Haskell for those
purposes.

------
jarrett
> Now OOP is taken for granted and assumed that all languages should be able
> to produce objects.

Not really. There are OOP languages, there are multi-paradigm languages that
include OOP stuff, and then there are languages that don't have OOP at all.
That last category includes functional languages like Haskell and some Lisps.

 _Should_ every language support at least some OOP? Maybe. I think it's too
soon to tell. We may eventually learn that pure functional languages are
better for maintaining a sane codebase, in which case OOP will not be
considered a mandatory language feature.

~~~
chowells
What Haskell lacks is hierarchies of subtyping. It certainly can be used for
OOP. I've written object-oriented code in Haskell. It's not common, but it's
not hard. And on rare occasions it's the best solution to a problem.

~~~
jarrett
Perhaps we have different definitions of OOP. To me, it's not OOP without
subclasses and private mutable state. What does OOP mean to you? I'm guessing
you're thinking of Haskell's typeclasses as an analogue to Java's interfaces.
Any other features?

~~~
dllthomas
You can implement private mutable state (and dynamic polymorphism behind an
interface) with records of closures. Depending on what you mean by
"subclasses" here, they may follow trivially. Haskell typeclasses are a poor
match to OOP, as you say.

~~~
jarrett
> with records of closures.

Interesting. Can you point me to an example?

~~~
Jtsummers
[http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent](http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent)

[http://okmij.org/ftp/Scheme/oop-in-fp.txt](http://okmij.org/ftp/Scheme/oop-
in-fp.txt)

[http://stackoverflow.com/questions/2954642/methods-and-
prope...](http://stackoverflow.com/questions/2954642/methods-and-properties-
in-scheme-is-oop-possible-in-scheme)

[http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-20.html](http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-20.html)

Some examples. The first is a discussion on it. The second and third have
examples in scheme. I'd type more but I'm on my iPad. If I get time later I'll
steal time on someone's computer to type up more.

------
josephschmoe
I looked up the Wikipedia article and I'm actually a huge fan of this. This
article sucks though.

------
_pmf_
Misunderstood, overrated and propagated by sophomores with a toy project, a
blog and too much time?

------
zenciadam
Does that mean we'll have 10 years of poorly written books about it?

~~~
0xdeadbeefbabe
More like blog posts.

