Slashdot Mirror
How Reactive Programming Differs From Procedural Programming
Nerval's Lobster writes "A recent post on Reactive Programming triggered discussions about what is and isn't considered Reactive Logic. In fact, many have already discovered that Reactive Programming can help improve quality and transparency, reduce programming time and decrease maintenance. But for others, it raises questions like: How does Reactive differ from conventional event-oriented programming? Isn't Reactive just another form of triggers? What kind of an improvement in coding can you expect using Reactive and why? So to help clear things up, columnist and Espresso Logic CTO Val Huber offers a real-life example that he claims will show the power and long-term advantages Reactive offers. 'In this scenario, we'll compare what it takes to implement business logic using Reactive Programming versus two different conventional procedural Programming models: Java with Hibernate and MySQL triggers,' he writes. 'In conclusion, Reactive appears to be a very promising technology for reducing delivery times, while improving system quality. And no doubt this discussion may raise other questions on extensibility and performance for Reactive Programming.' Do you agree?"
There really is no such thing, they just made up the term for attention. What he is describing might be called "tools" programming, but it's not new or different. I have written "Tools" in various languages for over 20 years. If they think they are going to market a few bucks with a "re-branding" program good for them. It worked for "Cloud" and I knew better then too.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
How does RP handle dupes?
I know I put in my $0.02 previously, so I won't bother again.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
1) The proactive, forward looking teams adopt it first, and have great success.
2) The "emerging trend followers" hop on board, and have reasonable results.
3) The rest of the industry follow and have mixed results, without it being any more successful than any other methodology.
Don't be blinded - initial results always look very promising.
Anybody around here remember Jackson Structured Programming The initial OOP wave? The whole CASE moevement? GUI application builders that were supposed to end the need for programmers?
The golden rule is that "whatever methodology technology you choose, half of adopters will always get sub-average results". The question you have to ask yourself Is are your team smarter than the average team?
Yet another super awesome framework/system/language/whatever to make a shopping cart in as few lines as possible.
The someone tries to build something remotely complex and it all falls to shit and the code ends up as spaghetti.
The guy who built it then leaves the company and they can't find anyone else with the skills to understand how it works
Buzz words! Get your red hot buzzwords! These buzzwords are fresh folks! No one's even figured out what they mean yet! You snooze, you lose! You there, little boy, I bet you could use Web 3.0!
The world's burning. Moped Jesus spotted on I50. Details at 11.
Isn't reactive programming essentially a repackaging of Table Oriented Programming?
"First they came for the slanderers and i said nothing."
this is just rebadged functional programming, except using deliberately confusing syntax
Snowden and Manning are heroes.
For example, the "Purchase Order" entity includes a reference to a sales rep. From it's inclusion we infer that is important data, so it would also need to be added as a "reaction". There's also no hint on how these "reactions" are actually implemented. The original article claims that consistency is enforced but doesn't really explain why.
The above might be what they mean, but that's not sufficient for consistency. If your database field is merely a duplicate of derived data in other entities, you shouldn't pat yourself on the back for avoiding a problem you created in the first place! You can also overlook a use case in the analysis phase too, and then you'll fail to include it regardless of the framework.
I think I'd like to see an example with all the entities included and some normalisation. Then maybe I might be convinced that RP has any advantages over triggers.
Plan My Week for iPhone
We used to make websites by regenerate all html pages when the database changes. It delivers really fast then.
Yeah, that's "reactive programming" at the file level. I do it all the time, with Makefiles. Lots of people do. A nice thing about a Makefile is that you can easily control when the calculation of derivative files happens. You (re)create some sets of primary data, then use a simple "make" command to rebuild everything that depends on any of them.
This is yet another illustration that the perps who introduced this supposedly-new concept have mostly just found a new buzzword for an approach that has been reinvented repeatedly in the past.
One of the ongoing problems in many fields of science and technology is the constant rediscovery (or reinvention if you prefer) of concepts long known by others that just use different words for the concepts.
Actually, mathematicians long ago realized this, and have a standard term for things that are described differently but are actually identical: They're generally called "isomorphic". A classical example that's important in computers was George Boole's "Boolean algebra", invented primarily as an exercise in pure logic. Eventually people noticed that it was isomorphic to the "propositional calculus", and then as electricity became widely available, engineers found that their new "circuit switching calculus" was another isomorphism. That's why so many programming languages have those AND, OR, XOR, NOT, etc operators.
This crowd is merely giving us another entry in the rather long list of isomorphic systems that differ only in their terminology. This means time wasted re-developing your system from scratch, when you could have saved a lot of time if you'd only realized that others had already solved your problem for you. But we don't have a good way to discover that two systems described with different words really are the same thing.
(Or do we? Maybe some mathematical linguists are working on the problem right now, and we don't realize this because we don't recognize their terminology.)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
from what i've read on wikipedia, "Reactive Programming" is really just function as a variable with caching.
example:
c = 5 // outputs 9 // outputs 10
b = 4
a = b + c
print(a)
c = 6
print(a)
this isnt rocket surgery
Anons need not reply. Questions end with a question mark.
Their presentation makes analogies between "reactive programming" and spreadsheets and specifically references the power of "chaining" to have multiple functions firing as the result of changes.
There are a number of issues with this kind of event chaining that you run into as you get past the toy cases.
1) Fan-out. How many actions are being kicked off by a simple change?
2) Latency - this is a direct corollary to the fanout. Are all of the chained functions being run synchronously? If so, what happens when someone introduces a very slow function that gets run as the result of a user input. So the user changes the price of a part and every purchase order in the system is suddenly being updated?
3) Synchronicity - of course, as soon as you find out that your synchronously run chained functions slow things down you start running them in the background. Now, you have a problem where you don't know if something is up-to-date or not. And, in this model, it's not possible to find out if something is up-to-date.
The examples that they gave are very poor use cases for triggers even. Most general ledger systems I've looked at, running on top of a database, would just recalculate the balance on demand. If your database is large enough that the recalculation starts to take significant time, you cache the result and invalidate it using a trigger. Most GL systems typically make entries much more frequently than they need to calculate the balance for an account. If the recalculation of the balance takes significant time, you probably don't want to do it every time an entry is made anyhow.
Stored procedures and triggers are already here and I see no evidence that there is anything new here. If the database is in a correct normalized form this will not reduce the amount of code one iota.
Do ***NOT*** put this sort of logic in the application code. Use properly written stored procedures, foreign key constraints, and database triggers and don't let "application" programmers (especially not agile ones or those who invent new terminology for well known and previously solved problems) within 100 miles of the logic.
And as far as the users being able to understand it "better" I have only one word to say: Bwahahahahahahahahahaha!
Given how much anti-education rhetoric combined with fads and agism I see in technology, it seems like tech is worse then most fields about reinventing the past. There seems to be an almost pathological desire to not acknowledge when something is a revisit of an older idea. Maybe too much ego wrapped up in being original?
You've hit it exactly - they've "invented" Makefiles for database rows.
In a sense, that didn't exist before, so that's something new, and it's definitely simpler than writing the 200 lines of code to do what make would automatically do for you.
I'm not sold on it taking over the world, but it's an interesting application of the idea.
(Well, actually, it did exist before - they point out the example of a spreadsheet, which does exactly what they're talking about. This seems to be the answer to "why can't we program databases the same way we do spreadsheets and Makefiles?")
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
Ok, there are a lot of people commenting on this below who have absolutely no idea what reactive programming is about. So I'll try to clear it up a bit.
Reactive programming is not polling.
If you call a function and wait for it to return a result, you aren't doing reactive programming.
If you are working in a REPL or command-line environment, and you have to type a command every time you want to obtain a result, your system is not reactive.
Reactive programming is not events and triggers. Well... let's say it this way: reactive programming is to events/triggers as writing in [C/C++/Java/C#/Haskell/etc.] is to writing in assembly. In other words, you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
Events and triggers are typically used when a little reactivity is needed. When you build your system around reactivity, using events and triggers quickly becomes inefficient and you need something built for the task. You would pick a reactive programming language or framework for such a complex job, just like (most of) you would choose high-level languages and frameworks over assembly for building a social media website.
Reactive programming isn't an agile framework. It's not some new way of describing object-oriented programming. And it's not the right tool for every job, but for some jobs, it's the perfect tool.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
Just like OOP eventually breaks down into CPU instructions, and you can use any Turing complete language to implement anything, I think he has a fair point. It sounds like a way to design a language so that complex event/trigger type stuff are easier to implement and debug systematically, perhaps using a slightly different way of thinking. It might not be a fancy thing, but I don't think there's anything wrong about giving it a name.
Don't kid yourself that it isn't fundamentally a style implemented with events.
I suppose that's why I said:
... you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
I don't know Val Huber, but can judge his "technology" ( hardly worth that name, though ) by what he is doing: putting the logic of a server-side application inside an RDBMS. After years and years of Hibernate applications with abysmally bad mainainability, now that finally finally finally-thank-god there are mature no-SQL databases, this guy goes back to where we were in the 80s.
Moreover: comments on that article simply get suppressed. Which says enough about this guy's capability to sustain critical thought. Dupe. Total dupe.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
When would I find time to read when I'm already so busy inventing?
... you really could do the same exact thing with events or triggers than you can do with reactive programming. But events and triggers are very basic compared to what is meant by reactive programming.
I kind of get the diretion you're going in, but I stil don't see. can you give an example? I see your analogy about C++ versus assembly but I only really understand it because I nuderstand C++.
Presumably reactive programm automates some (how/what?) or many or most of the difficulties away...
SJW n. One who posts facts.
You've told us what it isn't. That's as much use as telling us that strawberries are not yellow and curved.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
The point of new paradigms in programming languages is to make the complexity of the expression match the complexity of the idea being expressed, not the complexity of the (platform specific) implementation.
Crappy illustration:
C++ - Event-trigger
// event
// trigger
// actual code you want to get around to actually writing
// some routine that modifies a continuously
vector triggers;
void add_trigger(Trigger * t);
void reactive_variable::modify_value(int new_value)
{
this.value = new_value;
for (i = triggers.begin(); i != triggers.end(); i++){
i.react(new_value);
}
}
int main()
{
reactive_variable a;
Trigger *b = new Trigger(COPY_VAR);
a.add_trigger(b);
Trigger *c = new Trigger(ADD_VAR, 1);
a.add_trigger(c);
a.modify_value(2);
enter_event_loop();
return 0;
}
Incomplete, inelegant and probably buggy, but you get the picture.
Verilog - Reactive
assign b = a;
assign c = a+1;
inital a = 2;
always @(posedge clk)
a = count(input);
Easy to understand whats going on and spot errors. 'b' will always equal 'a' and 'c' will always be one more.
Reactive programming is based on the totally opposite concept of COME FROM statement. Waiting for a future Dijkstra to write a paper on how evil COME FROM is.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
There was once a language called magic that allowed this to be done and was really good at it. A bank wrote their system with it. Then 5 years later someone tried to re-write the banking app. 10 years later they're still reverse engineering the original app to provide the functionality.
as it is eaten so it shall pass
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.
I don't know why people keep submitting this garbage from Espresso Logic, who is just taking advantage of the fact the the term "reactive" has been overloaded to mean different things to exploit the hype surrounding the Reactive Manifesto and related technologies (e.g., Akka, Rx, Node.js, etc.) to push their own, completely unrelated product, which is based on the more traditional (i.e., the one you find in Wikipedia) definition of "Reactive Programming".
"Reactive programming", as defined by the Reactive Manifesto (which is what all the hype is about), is about designing applications that operate in an entirely asynchronous and non-blocking manner, so as to maximize CPU utilization and fully exploit parallelism, and ensure that the system is always responsive to new events (user input, incoming data streams, errors, changes in load, etc.) rather than having resources tied up waiting for external processes (e.g., blocking on I/O). It has nothing to do with "reactive databases".
cp /dev/zero ~/signature.txt