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

Marketing 101

[s.petry]

There really is no such thing, they just made up the term for attention. What he is describing might be called "tools" programming, but it's not new or different. I have written "Tools" in various languages for over 20 years. If they think they are going to market a few bucks with a "re-branding" program good for them. It worked for "Cloud" and I knew better then too.

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?

Re:All methodologies are the same.

[msobkow]

Absolutely.

The longer you spend in programming, the more you realize it's all been done in years past and it's just some "new grad" thinking they've invented something because they never looked into the history of programming techniques used over the years, or because they never happened to touch the systems that did it before.

I've been programming for over 35 years.

I've come to the conclusion that it's all about marketting buzz-words and bullshit to try and sucker investors into spending money, not about actually improving the way people write code or think about problems.

Re:All methodologies are the same.

[lgw]

The nice thing is after 10-15 year or so, all problems start to look familiar to you, but not so much to the young guys or the managers. You can either rebel against the latest old thing new again and seem a Luddite, or seem a genius for immediately seeing all the pitfalls and optimizations entailed in the "new" idea.

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

Is it webscale?

[Hognoxious]

You've told us what it isn't. That's as much use as telling us that strawberries are not yellow and curved.