Can Reactive Programming Handle Complexity?

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

Comments

A few problems...

[Ckwop]

A few problems:

- What about circular reactions?
- Is SQL really that right language for encoding business logic?
- Triggers are kind of an anti-pattern.
- What about atomicity? What if I need the whole reaction chain to work or none of it.

I'm afraid there more questions than answers with this proposed pattern.

Re:A few problems...

[lgw]

- Triggers are kind of an anti-pattern.

Well, sort of the point of this style is to embrace triggers as a powerful and underused tool. I'm a big fan of powerful and underused tools, but generally there's a reason they're underused.

Pick the right tool for the job. Reactive programming seems like it makes life wonderfully easier for this very narrow set of problems. That's neat. But both trying to us it for everything and insisting that it's useless because it doesn't work for everything are mistakes. Like a power screwdriver with a U-joint attachment, some tools go from pointlessly awkward to awesomely helpful when faced with a particularly-shaped niche.

Re:A few problems...

[Qzukk]

I think I just started development on the 3rd worst D20 product

*rolls a 1*

Your fingers fumble over the keyboard, striking keys almost under their own accord.

UPDATE customer SET lastname='Jones'

*rolls save vs. WHERE clause... 3*

;

With horror you look on as you strike a glancing blow to the enter key.

No silver bullet

[Rumagent]

It is a tool. Like any other tool you apply it when your skill and experience tells you to. I belive the term commonly associated with this is "professional".

of course it can

[istartedi]

x = new WonderfulObject();
x.Invoke("5000 lines of C that somebody wrote");

Re:of course it can

[istartedi]

But if developers are constantly writing slight variations on the same 500 lines of C, why not encapsulate it?

Sure, no problem with that. After all I just typed that into a text area in a web browser and hit send. There were probably *millions* of lines of encapsulated code in that one instant. The difference is that I'm not pretending that hitting "Submit" is the same as writing a web browser, a network stack, router firmware, etc. I didn't solve any problems. Those guys did.

Re:of course it can

[phantomfive]

Your comment made me laugh, but then I read the article, and that's exactly what the author said. From the article:

"Reactive Programming is very capable of addressing many complex problems, and can address all other scenarios via a transparent integration with procedural languages."

5 lines and i don't know what they do

[shadowrat]

I don't know what the 500 lines of java code are, but i guess they are grabbing input and cleaning it and opening database connections and whatnot. assuming that he's counting import statements and puts curly brackets on their own lines. sure 500 lines.

I don't know much about this Reactive stuff, but i don't see anything in this sample code that tells me where the input is coming from or where it is going to or if it's being cleaned in the process. Somehow Reactive also creates an environment in which nothing unexpected ever gets entered?

The usual consulting snake oil

[engineerErrant]

As background, I am the director of engineering in a small Java/Postgres-based shop. We run a cloud backend for our mobile apps.

This "methodology" reads from the first sentence like an extended infomercial for a consulting shop, or a company trying to create the aura of "thought leadership" to get more investment cash. The formula is simple and time-honored: (1) arbitrarily single out a well-worn software practice to receive a snappy marketing name and be held above all other practices, (2) claim it's new, and (3) offer to implement this bleeding-edge buzzword to clueless executives. For a small fee, of course. It's the same formula that gave us Agile.

In my opinion, what they've described here is a large step *backward.* Not only is this a relatively trivial use of the GoF Observer pattern, but bizarrely, it's done in SQL using triggers, causing immediate database vendor lock-in and creating a maintainability nightmare. It's how software was made back in the 90s when Enterprise SQL database vendors ruled the land. Sprinkling business logic around in the SQL instead of centralizing it in a much more suitable language for logic like Java is a completely terrible idea, unless you're an Oracle sales rep.

This one is safely ignored.

Re:The usual consulting snake oil

[St.Creed]

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.

Ditto

[goombah99]

I've done reactive programs. They make fun little interface gizmhos. But holy shit, try debugging something that does something complex. You can't assure when, where and how variables might be changing in some outer reaches of your program while another part of the program is assuming they are momentarily fixed. It's going to be unpossible to seriously optimize a reactive program.
So yeah for silly data base queries of simple mathematical calcs go for it. Complex programs. run away

Apologies to Douglas Adams

[Hognoxious]

The Americans considered themselves the winners because afterwards America became an entirely separate country. The British considered themselves the winners for exactly the same reason.