Slashdot Mirror
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?"
Can bullshit walk?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
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.
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".
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I concur.
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?
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.
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"
No. He's an Anonymous Coward.
I'm British.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
This is just marketing hype dressed up as a question. Having said that, anything that gets anyone enthused about programming is good, I guess.
What I really don't like is when Val Huber refers to a previous article he submitted as if it were written by a third party.
Now, I love SQL (and triggers are ok) - and so does Val Huber - I'm sure we would get along fine.
Val, you've been doing SQL for 20 years! woot. So that means you started back 'round '94.
(Aw. I started back in '85. I was doing websites in '94 - remember Lycos?)
But it's just using SQL Triggers, Val - why give it some sort of fancy name? Ohh everyone else does that, like "Web2"? or "The Cloud", etc?
Still stinks - but hopefully someone may actually pick up how to use some of the cool features of SQL.
This comment was written with the intention to opt out of advertising.
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
Some drink at the fountain of knowledge. Others just gargle.
By the way, I thought I'd add, the only reactive style language that I've really found could get modestly complex and still not be incomprehensible is Lab view. It's event driven, and the you can literally see where and how a variable is being modified with the wires it draws (unless you like using globals. The problem with labview is feeding a wire through a lot of graphical levels is so annoying that you end up resorting to globals more than you should.). Labview takes a really different mind set to do well but anyone can be crappy at it and get the job done. It's the only program I've felt comfortable modifying in the middle of an experimental run. It's just really robust in that the errors one makes tend not to be fatal. Maybe it's because visually you can see the logic and know the scope of any side effects. But major application complexity? nope. Get complex interfaces hacked together fast? yes.
Some drink at the fountain of knowledge. Others just gargle.
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".
My experience is that nearly anytime you see a problem reactive programming could address you would be better off designing a program in which evaluation is lazy, and every calculation is memoized. Spend a little time designing for laziness and memoization and there's no need to lock everything into being based on a reactive language.
Some drink at the fountain of knowledge. Others just gargle.
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.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
address not just typical problems, but complex ones as well
If they find that complex problems are not typical, that tells us a lot about the scope of their experience.