Comment Re:I thought that we were supposed to be pro-activ (Score 2) 186
The downside of reactive programming, however, is exactly the same as the downside of the event/trigger logic that has been available in databases for decades, namely the difficult-to-trace side-effects caused by out-of-order execution that is basically mandated in reactive programming.
It's not so obvious when you're first writing code, but it's a headache when you're maintaining it (I disagree with the article on this point). Take the example in the original article... let's say you go back and add a requirement that people can pay for multiple invoices at once or for partial amounts. You have to check every single trigger to see if it refers back to the original payment information and adjust it accordingly. You'll have to change the data model to handle partially paid components (currently "paid" is a boolean), and any trigger that reads or modifies "paid" will have to be adjusted.
This alone isn't a problem -- you'd have to make similar changes in OOP, procedural, or functional languages... the issue is that in those languages you're more likely to be able to trace the dependant code and understand the flow. If you have access to the entire code base, you could search it I suppose, but each trigger operates like a "COME FROM" command in INTERCAL... it's as if your code is running along operating and all of a sudden an execution branch just pops in, performs some change, and lets you carry on, without telling you. I've had to debug some brutal issues caused by this sort of programming and it's difficult precisely because you're not sure where the execution path is coming from nor in what order it's being executed. It's almost entirely un-auditable once it gets complex enough to perform real-world tasks. If this was a real-world billing system, you'd have payments, refunds, discounts, credits, and a dozen other bits each making each "reaction" more complex. Each would require its own line of reactive code and each would depend on at least several of the others, and it's very easy to lose track of what's going on.
I realize people can write bad code in any paradigm, but bad code in reactive is far more difficult to debug, fix, and maintain, IMHO.