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?"
Also (Score:2, Insightful)
A few problems... (Score:5, Insightful)
- 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.
No silver bullet (Score:5, Insightful)
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 (Score:5, Insightful)
Re:of course it can (Score:5, Insightful)
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.
5 lines and i don't know what they do (Score:5, Insightful)
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 (Score:5, Insightful)
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:A few problems... (Score:5, Insightful)
- 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.
Looks more like a formula (Score:3, Insightful)
Having read TFA, it looks to me like all they have done is compared a schema which was not properly normalised, with something which was; for example the 'reactive' code calculates total cost as quantity x price, where as the author is conjecting that the SQL version would have a total-price field, and therefore have to have '500' lines of code to keep this field updated.
Smells like snake oil to me.
You have to ask, "Why would the SQL schema need a totalprice field?" ... then you have to recalculate the totalprice every time you look at it.
If your business logic says that the totalprice is always Q x price, then ditch the field and ditch all the code which enforces the relationship. But
There are other examples of denormalised data in the sample provided, and in all cases the 'reactive' code simply calculates the value on the fly - and as other commenters have mentioned, this blows up as soon as the business rule is no longer valid, such as "when a product's price is changed, DONT change the price on quoted or shipped orders, DO change the price on scheduled or reoccuring orders"
Ditto (Score:5, Insightful)
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
Re:The usual consulting snake oil (Score:3, Insightful)
That's certainly valid that proper organization is far more the key to good code than the use of any language - my comments should not be taken as an ad for Java or any other specific technology.
That said, certain language features lend themselves to good organization much better than others. Where SQL faces challenges is that (1) it's mostly a declarative language using set calculus, which (again, in my opinion) makes it ill-suited for non-trivial business logic, (2) because of the aforementioned, it can't be hooked up to a debugger in any normal sense, making maintenance and troubleshooting that much harder, (3) it's a separate "codebase" and technical competency than the "main" codebase (whether it's in Java, C#, Ruby or whatever), thus creating a competency barrier that must be crossed every time work needs to be done on that code, (4) it's not stored with the main codebase, but as a form of data, raising the issue of out-of-sync deployments with the app servers, and (5) far fewer developers know it well enough for complex uses than typical app-server languages, making staffing difficult.
Finally, I have personally always found large codebases much more manageable when written in a statically typed language (which SQL is obviously not). Not wanting to spark a flame war with Ruby or PHP fans, though, I will caveat my statement that those languages are also much better suited for business logic than SQL's declarative style is.
Re:A few problems... (Score:4, Insightful)
I don't know about "anti-pattern", but they cause trouble because they cause other code to be non-deterministic and it's very difficult to create patterns around that sort of behavior. They're practically the logical equivalent of the "COME FROM" in Intercal, which was originally a joke for goodness sake. I was flabbergasted when I found out people are vaunting code that actually works this way. It's particularly painful in implementations where the "reactions" can override program flow with errors or silent rejection or just running off and doing whatever they want. It's nearly impossible to debug since reactions (triggers) are almost always coded in a language or paradigm separate from some procedural language used to provide the UI or whatever other layer is being reacted TO.
I just don't like it! But that's just me.