Live data from Hacker News

Reactive Programming is the New OOP

dataflowbook.com

1–10 of 31 posts

Re: Reactive Programming is the New OOP

#2
... having channels doesn't have anything to do with 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.

Re: Reactive Programming is the New OOP

#4

  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?

Re: Reactive Programming is the New OOP

#5

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?

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

Re: Reactive Programming is the New OOP

#6
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.

Re: Reactive Programming is the New OOP

#7
post #6

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.

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/DeprecatingOb...

Re: Reactive Programming is the New OOP

#8
> 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.

Re: Reactive Programming is the New OOP

#9

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?

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.

Post reply on HN