How Reactive Programming Differs From Procedural Programming 186
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?"
table based programming (Score:4, Interesting)
functional (Score:4, Interesting)
this is just rebadged functional programming, except using deliberately confusing syntax
Toy Example (Score:4, Interesting)
For example, the "Purchase Order" entity includes a reference to a sales rep. From it's inclusion we infer that is important data, so it would also need to be added as a "reaction". There's also no hint on how these "reactions" are actually implemented. The original article claims that consistency is enforced but doesn't really explain why.
The above might be what they mean, but that's not sufficient for consistency. If your database field is merely a duplicate of derived data in other entities, you shouldn't pat yourself on the back for avoiding a problem you created in the first place! You can also overlook a use case in the analysis phase too, and then you'll fail to include it regardless of the framework.
I think I'd like to see an example with all the entities included and some normalisation. Then maybe I might be convinced that RP has any advantages over triggers.
Re:History repeats (Score:5, Interesting)
We used to make websites by regenerate all html pages when the database changes. It delivers really fast then.
Yeah, that's "reactive programming" at the file level. I do it all the time, with Makefiles. Lots of people do. A nice thing about a Makefile is that you can easily control when the calculation of derivative files happens. You (re)create some sets of primary data, then use a simple "make" command to rebuild everything that depends on any of them.
This is yet another illustration that the perps who introduced this supposedly-new concept have mostly just found a new buzzword for an approach that has been reinvented repeatedly in the past.
One of the ongoing problems in many fields of science and technology is the constant rediscovery (or reinvention if you prefer) of concepts long known by others that just use different words for the concepts.
Actually, mathematicians long ago realized this, and have a standard term for things that are described differently but are actually identical: They're generally called "isomorphic". A classical example that's important in computers was George Boole's "Boolean algebra", invented primarily as an exercise in pure logic. Eventually people noticed that it was isomorphic to the "propositional calculus", and then as electricity became widely available, engineers found that their new "circuit switching calculus" was another isomorphism. That's why so many programming languages have those AND, OR, XOR, NOT, etc operators.
This crowd is merely giving us another entry in the rather long list of isomorphic systems that differ only in their terminology. This means time wasted re-developing your system from scratch, when you could have saved a lot of time if you'd only realized that others had already solved your problem for you. But we don't have a good way to discover that two systems described with different words really are the same thing.
(Or do we? Maybe some mathematical linguists are working on the problem right now, and we don't realize this because we don't recognize their terminology.)
Re:All methodologies are the same. (Score:5, Interesting)
Like every other question about software development, we should always start with The Mythical Man Month. In this case, the relevant chapter is There Is No Silver Bullet.
Now, the interesting thing about that chapter is that, while it was right, it was the least right of all the good predictions Brooks made. No technology is a silver bullet, but many produce noticeable improvements that, when put together, can give us an order of magnitude in productivity over older tech. It's not as if OO has been abandoned. Case tools were replaced by the far more sensible powerful IDE. GUI builders are not used a lot nowadays, but we get many of their gains by having dev environments with tighter feedback loops. And there's of course the mother of all improvements, which is the creation of large, powerful libraries. How many of the things that people did for business applications 15 years ago are, today, just replaced by libraries?
Not that this denies your final thesis though: Hire bright programmers with people skills, and do your best to keep them. No technology will allow bad developers to make a good application.
Spreadsheets are lousy programming models (Score:5, Interesting)
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:History repeats (Score:3, Interesting)
You've hit it exactly - they've "invented" Makefiles for database rows.
In a sense, that didn't exist before, so that's something new, and it's definitely simpler than writing the 200 lines of code to do what make would automatically do for you.
I'm not sold on it taking over the world, but it's an interesting application of the idea.
(Well, actually, it did exist before - they point out the example of a spreadsheet, which does exactly what they're talking about. This seems to be the answer to "why can't we program databases the same way we do spreadsheets and Makefiles?")