How Reactive Programming Differs From Procedural Programming

Nerval's Lobster writes "A recent post on Reactive Programming triggered discussions about what is and isn't considered Reactive Logic. In fact, many have already discovered that Reactive Programming can help improve quality and transparency, reduce programming time and decrease maintenance. But for others, it raises questions like: How does Reactive differ from conventional event-oriented programming? Isn't Reactive just another form of triggers? What kind of an improvement in coding can you expect using Reactive and why? So to help clear things up, columnist and Espresso Logic CTO Val Huber offers a real-life example that he claims will show the power and long-term advantages Reactive offers. 'In this scenario, we'll compare what it takes to implement business logic using Reactive Programming versus two different conventional procedural Programming models: Java with Hibernate and MySQL triggers,' he writes. 'In conclusion, Reactive appears to be a very promising technology for reducing delivery times, while improving system quality. And no doubt this discussion may raise other questions on extensibility and performance for Reactive Programming.' Do you agree?"

Comments

All methodologies are the same.

[hamster_nz]

1) The proactive, forward looking teams adopt it first, and have great success.

2) The "emerging trend followers" hop on board, and have reasonable results.

3) The rest of the industry follow and have mixed results, without it being any more successful than any other methodology.

Don't be blinded - initial results always look very promising.

Anybody around here remember Jackson Structured Programming The initial OOP wave? The whole CASE moevement? GUI application builders that were supposed to end the need for programmers?

The golden rule is that "whatever methodology technology you choose, half of adopters will always get sub-average results". The question you have to ask yourself Is are your team smarter than the average team?

Woohoo

[viperidaenz]

Yet another super awesome framework/system/language/whatever to make a shopping cart in as few lines as possible.

The someone tries to build something remotely complex and it all falls to shit and the code ends up as spaghetti.
The guy who built it then leaves the company and they can't find anyone else with the skills to understand how it works

Re:Marketing 101

[Anonymous Coward]

Here's a quote for your marketing:
Q: How does reactive programming differ from procedural programming?
A: People use procedural programming, they only talk about reactive programming.

A Day at the Country Fair

[MightyMartian]

Buzz words! Get your red hot buzzwords! These buzzwords are fresh folks! No one's even figured out what they mean yet! You snooze, you lose! You there, little boy, I bet you could use Web 3.0!

Spreadsheets are lousy programming models

[putaro]

Their presentation makes analogies between "reactive programming" and spreadsheets and specifically references the power of "chaining" to have multiple functions firing as the result of changes.

There are a number of issues with this kind of event chaining that you run into as you get past the toy cases.

1) Fan-out. How many actions are being kicked off by a simple change?
2) Latency - this is a direct corollary to the fanout. Are all of the chained functions being run synchronously? If so, what happens when someone introduces a very slow function that gets run as the result of a user input. So the user changes the price of a part and every purchase order in the system is suddenly being updated?
3) Synchronicity - of course, as soon as you find out that your synchronously run chained functions slow things down you start running them in the background. Now, you have a problem where you don't know if something is up-to-date or not. And, in this model, it's not possible to find out if something is up-to-date.

The examples that they gave are very poor use cases for triggers even. Most general ledger systems I've looked at, running on top of a database, would just recalculate the balance on demand. If your database is large enough that the recalculation starts to take significant time, you cache the result and invalidate it using a trigger. Most GL systems typically make entries much more frequently than they need to calculate the balance for an account. If the recalculation of the balance takes significant time, you probably don't want to do it every time an entry is made anyhow.

Re:I thought that we were supposed to be pro-activ

[metamarmoset]

The point of new paradigms in programming languages is to make the complexity of the expression match the complexity of the idea being expressed, not the complexity of the (platform specific) implementation.

Crappy illustration:

C++ - Event-trigger
vector triggers;

void add_trigger(Trigger * t);

void reactive_variable::modify_value(int new_value)
{
// event
this.value = new_value;
// trigger
for (i = triggers.begin(); i != triggers.end(); i++){
i.react(new_value);
}
}

// actual code you want to get around to actually writing
int main()
{
reactive_variable a;
Trigger *b = new Trigger(COPY_VAR);
a.add_trigger(b);
Trigger *c = new Trigger(ADD_VAR, 1);
a.add_trigger(c);

a.modify_value(2);

enter_event_loop(); // some routine that modifies a continuously

return 0;
}

Incomplete, inelegant and probably buggy, but you get the picture.

Verilog - Reactive
assign b = a;
assign c = a+1;

inital a = 2;

always @(posedge clk)
a = count(input);

Easy to understand whats going on and spot errors. 'b' will always equal 'a' and 'c' will always be one more.