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.

Re:Marketing 101

[s.petry]

I think it's supposed to be being touted as a special new language because we need "reactive" programming hence the name "Reactive". The language may be "new", but I doubt it. I have not looked honestly, I looked at the claim on why it's needed and call bullox. I have mountains of libraries I have written for various tools in C, Python, Perl, and various scripting languages (TCL/WISH/SH). Most of those use bits of the mountains of libraries developed for those languages.

I'm getting cynical in my age I guess, but the majority of the claims people make are simply fluff to try and make a buck or name. Claiming that we need a new language for a special case is silly. Develop and release a library(or libraries) for your needs so that people can use it. Otherwise we end up with all these little tufts of crap that 3 people in the world use, and have to listen to them complain about why adoption is so low.

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

Horseshit.

[pigiron]

Stored procedures and triggers are already here and I see no evidence that there is anything new here. If the database is in a correct normalized form this will not reduce the amount of code one iota.

Do ***NOT*** put this sort of logic in the application code. Use properly written stored procedures, foreign key constraints, and database triggers and don't let "application" programmers (especially not agile ones or those who invent new terminology for well known and previously solved problems) within 100 miles of the logic.

And as far as the users being able to understand it "better" I have only one word to say: Bwahahahahahahahahahaha!

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.