Slashdot Mirror

← Back to Stories (view on slashdot.org)

How Reactive Programming Differs From Procedural Programming

Posted by samzenpus on from the talk-amongst-yourselves dept.

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?"

2 of 186 comments (clear)

  1. All methodologies are the same. by hamster_nz · · Score: 5, Insightful

    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?

  2. Woohoo by viperidaenz · · Score: 5, Insightful

    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