11 ms·

Reactive Programming is the New OOP

31 points by mattcarkci 12y ago

MetaCosm 12y ago
... 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 12y ago
  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 12y ago
    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".
- amirouche 12y ago
  > having channels doesn't have anything to do with Reactive Programming Mostly agree, in the sens that, from my limited pratical experience & knowledge of Reactive Programming (RP), I understand that RP isn't bound to a particular "parallel execution model" (maybe s/parallel execution model/threading model/ ?). > 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. I can't find it in https://groups.google.com/forum/#!searchin/Golang-nuts/Reactive$20programming https://groups.google.com/forum/#!searchin/Golang-nuts/React... A blog post might be better fit for that (so far I was unsuccessful getting constructive feedback that way). Anyway here are more thought, based on my experience dealing with GUI app: - "parallelism", even if simpler with an event-loop, is still a significant burden especially when performance matters - Class based OOP, especially not JavaScript, is very helpful to group a sequence of callbacks to help fight spaghetti code. - Explicit State Machines are a praised black art wrongfully dubbed useless overhead because "it's possible to do otherwise" - «yield/await/async» as been recently recognized broadly as the way forward cf. https://news.ycombinator.com/item?id=4732924 https://news.ycombinator.com/item?id=4732924 All the points mentionned above have in common that they try to handle correctly with fine grained priority and different "paralellism" patterns with ease. RP mean to provide much more than "yield", it's pattern that is similar to the explicit state machine intent. The declarative paradigm/syntax arguably provides an ease of use that is competitive both in terms of performance and dev efforts even if mileage may vary. See by yourself: >>> HackerNewsPost.rank = HackerNews.upvote_count * MAGIC_NUMBER This one might be better expressing the actual behavior, even if the ranking algorithm is "hidden": >>> HackerNewsPost.on_change(HackerNewsPost.position).update(HackerNewsPost.rank).maximum_frequency(timedelta(seconds=60*60)) The above can not be expressed in "one line" using "yield" and whatnot. May be of interest to you: - https://speakerdeck.com/ryanartecona/a-unified-model-of-asynchrony-in-js https://speakerdeck.com/ryanartecona/a-unified-model-of-asyn... - http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ http://swannodette.github.io/2013/12/17/the-future-of-javasc... - Observable/Observer, pub/sub & signaling patterns - Search for "AngularJS performance issues" - http://en.wikipedia.org/wiki/UI_data_binding http://en.wikipedia.org/wiki/UI_data_binding Reactive Programing can abstract the underlying "threading model" and all the above patterns... I am biased. edit: typo & more rigorous "API" in second one-liner
ripter 12y ago
This isn't even an article, just a guy saying the people complained about OOP back in the day.
- barkingcat 12y ago
  It doesn't even say what kind or what reactive programming is - just throws out some random words ...
  - vanderZwan 12y ago
    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 12y ago
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 12y ago
  Aspects are used quite a lot in Java and C#. Simply to get around the verbosity.
  - tlarkworthy 12y ago
    and in python they are function decorators.
- jarrett 12y ago
  I'm also not convinced that the arguments really are the same. The biggest complaint I've heard about OOP isn't that "you can get by without it," as the author claims. Rather, it's two things: Proliferation of objects such that the codebase can't be understood holistically, and the dangers arising from objects having internal state. I've never heard either of those arguments against reactive programming. The most common complaint I've heard about reactive programming is that it has yet to be realized in the form of mature libraries. (In general, for most languages. I'm sure at least one language has it.) Thus, whether it's a great idea or not is largely immaterial for most workaday developers, who won't be able to use it until the ecosystem exists.
chazu 12y ago
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.
- acjohnson55 12y ago
  I think the key difference is in which side of the conversation between transmitter and receiver the intentionality is vested. - Actors have no control over where messages come from. Actors have complete control over what other actors receive their messages. - In a reactive model, a producer sends messages blindly, with no control over the receiver. The consumer chooses its sources specifically. I'm not sure if this is exactly the right answer, but it is the impression I got after reading a paper on dataflow programming [1]. I'd be interested in whether anyone has any deep insights on the relative advantages of each model, and whether they're actually equivalent on some level. [1] http://infoscience.epfl.ch/record/176887/files/DeprecatingObservers2012.pdf http://infoscience.epfl.ch/record/176887/files/DeprecatingOb...
- HillRat 12y ago
  As I understand it (and I may not understand it at all!), the most significant difference is that dataflow programming is deterministic and compositional, whereas actors are nondeterministic and discrete. Intuitively, I tend to compartmentalize dataflow along with maps, filters and comprehensions; and actors with FSMs. This is probably an incorrect generalization, but it works for me. Somewhere, Hoare gives an example of pipelining the sieve of Eratosthenes through a series of communicating processes, which is a good example of dataflow programming -- you send a list of integers to a process that sieves out even numbers and sends the result to a process that sieves out multiples of 3, and so on. Such a pipeline is deterministic -- given a set of values, you will always get the same output -- and compositional -- the sum of the sieves is greater than the individual parts. A traditional actor-based model, on the other hand, isn't well-suited for that kind of problem, but is great if your goal is to dispense biscuits and chocolates. State is kept locally, and the actor can change its behavior to external messages based on internal state -- that is to say, actors have discrete identities. The response to any particular message is nondeterministic, because it depends on what's the actor's internal state and decision process may be, and you can't really combine multiple vending machines to compose a new, super-vendor.
jarrett 12y ago
> 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 12y ago
  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.
  - bunderbunder 12y ago
    What's that old chestnut about design patterns just being workarounds for missing language features? Multi-paradigm languages: I'll admit they're usually woefully lacking in sex appeal. When it comes to getting @$#@% done and moving on with your life, though, they be awesome.
    - dllthomas 12y ago
      There is a difference between "this isn't provided by the language, but I can easily implement it" and "this is impossible (or absurdly messy) in the language, but these work-arounds can make me care less".
  - jarrett 12y ago
    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?
zenciadam 12y ago
Does that mean we'll have 10 years of poorly written books about it?
- 0xdeadbeefbabe 12y ago
  More like blog posts.
_pmf_ 12y ago
Misunderstood, overrated and propagated by sophomores with a toy project, a blog and too much time?
josephschmoe 12y ago
I looked up the Wikipedia article and I'm actually a huge fan of this. This article sucks though.

31 points by mattcarkci 12y ago

... 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 12y ago
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 12y ago
  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".
amirouche 12y ago
> having channels doesn't have anything to do with Reactive Programming Mostly agree, in the sens that, from my limited pratical experience & knowledge of Reactive Programming (RP), I understand that RP isn't bound to a particular "parallel execution model" (maybe s/parallel execution model/threading model/ ?). > 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. I can't find it in https://groups.google.com/forum/#!searchin/Golang-nuts/Reactive$20programming https://groups.google.com/forum/#!searchin/Golang-nuts/React... A blog post might be better fit for that (so far I was unsuccessful getting constructive feedback that way). Anyway here are more thought, based on my experience dealing with GUI app: - "parallelism", even if simpler with an event-loop, is still a significant burden especially when performance matters - Class based OOP, especially not JavaScript, is very helpful to group a sequence of callbacks to help fight spaghetti code. - Explicit State Machines are a praised black art wrongfully dubbed useless overhead because "it's possible to do otherwise" - «yield/await/async» as been recently recognized broadly as the way forward cf. https://news.ycombinator.com/item?id=4732924 https://news.ycombinator.com/item?id=4732924 All the points mentionned above have in common that they try to handle correctly with fine grained priority and different "paralellism" patterns with ease. RP mean to provide much more than "yield", it's pattern that is similar to the explicit state machine intent. The declarative paradigm/syntax arguably provides an ease of use that is competitive both in terms of performance and dev efforts even if mileage may vary. See by yourself: >>> HackerNewsPost.rank = HackerNews.upvote_count * MAGIC_NUMBER This one might be better expressing the actual behavior, even if the ranking algorithm is "hidden": >>> HackerNewsPost.on_change(HackerNewsPost.position).update(HackerNewsPost.rank).maximum_frequency(timedelta(seconds=60*60)) The above can not be expressed in "one line" using "yield" and whatnot. May be of interest to you: - https://speakerdeck.com/ryanartecona/a-unified-model-of-asynchrony-in-js https://speakerdeck.com/ryanartecona/a-unified-model-of-asyn... - http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ http://swannodette.github.io/2013/12/17/the-future-of-javasc... - Observable/Observer, pub/sub & signaling patterns - Search for "AngularJS performance issues" - http://en.wikipedia.org/wiki/UI_data_binding http://en.wikipedia.org/wiki/UI_data_binding Reactive Programing can abstract the underlying "threading model" and all the above patterns... I am biased. edit: typo & more rigorous "API" in second one-liner

ripter 12y ago

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

barkingcat 12y ago
It doesn't even say what kind or what reactive programming is - just throws out some random words ...
- vanderZwan 12y ago
  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 12y ago

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 12y ago
Aspects are used quite a lot in Java and C#. Simply to get around the verbosity.
- tlarkworthy 12y ago
  and in python they are function decorators.
jarrett 12y ago
I'm also not convinced that the arguments really are the same. The biggest complaint I've heard about OOP isn't that "you can get by without it," as the author claims. Rather, it's two things: Proliferation of objects such that the codebase can't be understood holistically, and the dangers arising from objects having internal state. I've never heard either of those arguments against reactive programming. The most common complaint I've heard about reactive programming is that it has yet to be realized in the form of mature libraries. (In general, for most languages. I'm sure at least one language has it.) Thus, whether it's a great idea or not is largely immaterial for most workaday developers, who won't be able to use it until the ecosystem exists.

chazu 12y ago

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.

acjohnson55 12y ago
I think the key difference is in which side of the conversation between transmitter and receiver the intentionality is vested. - Actors have no control over where messages come from. Actors have complete control over what other actors receive their messages. - In a reactive model, a producer sends messages blindly, with no control over the receiver. The consumer chooses its sources specifically. I'm not sure if this is exactly the right answer, but it is the impression I got after reading a paper on dataflow programming [1]. I'd be interested in whether anyone has any deep insights on the relative advantages of each model, and whether they're actually equivalent on some level. [1] http://infoscience.epfl.ch/record/176887/files/DeprecatingObservers2012.pdf http://infoscience.epfl.ch/record/176887/files/DeprecatingOb...
HillRat 12y ago
As I understand it (and I may not understand it at all!), the most significant difference is that dataflow programming is deterministic and compositional, whereas actors are nondeterministic and discrete. Intuitively, I tend to compartmentalize dataflow along with maps, filters and comprehensions; and actors with FSMs. This is probably an incorrect generalization, but it works for me. Somewhere, Hoare gives an example of pipelining the sieve of Eratosthenes through a series of communicating processes, which is a good example of dataflow programming -- you send a list of integers to a process that sieves out even numbers and sends the result to a process that sieves out multiples of 3, and so on. Such a pipeline is deterministic -- given a set of values, you will always get the same output -- and compositional -- the sum of the sieves is greater than the individual parts. A traditional actor-based model, on the other hand, isn't well-suited for that kind of problem, but is great if your goal is to dispense biscuits and chocolates. State is kept locally, and the actor can change its behavior to external messages based on internal state -- that is to say, actors have discrete identities. The response to any particular message is nondeterministic, because it depends on what's the actor's internal state and decision process may be, and you can't really combine multiple vending machines to compose a new, super-vendor.

jarrett 12y ago

> 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 12y ago
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.
- bunderbunder 12y ago
  What's that old chestnut about design patterns just being workarounds for missing language features? Multi-paradigm languages: I'll admit they're usually woefully lacking in sex appeal. When it comes to getting @$#@% done and moving on with your life, though, they be awesome.
  - dllthomas 12y ago
    There is a difference between "this isn't provided by the language, but I can easily implement it" and "this is impossible (or absurdly messy) in the language, but these work-arounds can make me care less".
- jarrett 12y ago
  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?

zenciadam 12y ago

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

0xdeadbeefbabe 12y ago
More like blog posts.

_pmf_ 12y ago

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

josephschmoe 12y ago

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