Can Reactive Programming Handle Complexity? 149
Nerval's Lobster writes "A recent article on Reactive Programming, which suggested that five lines of Reactive could solve a problem that required 500 lines using Java or 200 lines using triggers, led many readers to question (passionately) whether Reactive enables you to address not just typical problems, but complex ones as well. In a follow-up column, Espresso Logic CTO Val Huber argues that, while it certainly can't solve all use cases, Reactive Programming is very capable of addressing many complex problems, and can address all other scenarios via a transparent integration with procedural languages. He shows how Reactive can handle complexity using two different scenarios: a classically complicated database application (a bill of materials price rollup) and procedural integration (to address external systems such as email and transactions not limited by a database update). Take a look at his work; do you agree?"
Problem as I see it... (Score:2, Interesting)
It appears that reactive programming would require an incredibly bloated and powerful backend. In effect, it moves most of the logic to the framework and allows the programmer to just hook a few pieces together. I can't imagine it scaling well with all the extra event notifications one would introduce. It looks like it would change from one event causing the execution of a chunk of code to multiple chained events triggering a conditional series of smaller chunks of code.
The problem lies in the overhead of notifications.
It might be "fewer lines of code" to write, but there's just no way in hell it could be as run-time efficient.
Re:A few problems... (Score:2, Interesting)
It's the third (at least) Slashvertisement for this useless new ... whatever it is they are trying to sell.
It has potential to get management buy-in because it works exactly the same as Excel. However, it will not get acceptance in the IT departments because it works like Excel but with no explicit statement about the questions you have raised and likely more as well.
There are situations where tables & triggers* are the best way to sort out a problem. There are places where dedicated matrix algebra would solve the problem most efficiently. You can either learn what tools are available and use the one that seems like the best fit, or you can master one tool and apply it to everything, both work because in the end you're still translating a vague idea into something that can become distinct instructions for the same computers.
*I think I just started development on the 3rd worst D20 product.
Re:The usual consulting snake oil (Score:5, Interesting)
Two points here I think:
1) Yes it is possible to build maintainable triggers - I'm doing it right now, as a matter of fact. However, it's certainly not my first choice since it's (a) hard to debug when they cascade and b) performance is hard to keep under control as they proliferate. Just look at Oracle's older products (or heck, look at Apex) and the huge amounts of triggers firing for even the most simple of tasks. It's a weed that you have to control rigourously or it will grow out and suffocate your software. It is NOT a best practice to use triggers if you can avoid them, they're a last resort if all other options are off the table.
2) Centralizing the business rules has a lot of repercussions beyond the technical side of things. Look at BeInformed's products for that. With proper definition of business rules, a good business rule engine can generate most CRUD-code from scratch, dynamically populating the screens with the required fields. BeInformed's latest product even generated the workflow at runtime, all business rule based. It was much more advanced than reactive. Unfortunately they invested too much and they're now up for grabs as they went under. As I understand it, SAP and Microsoft are fighting over the remains. Which is a much better buy than Reactive.
I'm sure you can find an edge case where some platform can't access the centralized business rule repository, or needs an exception. Or it becomes inflexible and unwieldy. Those are generally signs of failing organizational processes, not technical issues.
That said, there's another point: why can't databases integrate with business rule engines? We're still stuck with constraints from the 60's, even Domain-Key constraints have to be programmed instead of declared. Databases could leap forward if they would deal properly with time, versioning, and business rules. Instead, we get slightly higher marks on the TP benchmarks. That's useless.