How Reactive Programming Differs From Procedural Programming 186
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?"
I thought that we were supposed to be pro-active.. (Score:2)
not re-active! ;-)
Paul B.
Re:I thought that we were supposed to be pro-activ (Score:4, Informative)
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.
Is it webscale? (Score:5, Insightful)
You've told us what it isn't. That's as much use as telling us that strawberries are not yellow and curved.
Re: (Score:2)
So, basically his imprecision was more precise than yours.
Re: (Score:3)
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 requ
Re: I thought that we were supposed to be pro-acti (Score:2)
Re: (Score:3)
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.
Re: (Score:3)
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...
Re:I thought that we were supposed to be pro-activ (Score:5, Informative)
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.
Re: (Score:2)
Actually, that's a good illustration, thanks!
Especially the bit about hardware. I guess if = just means a wire, then if one side changes, then so does the other. I guess you'd have to insert a D-latch to make it non-reacive. I guess nothing in the assignments is clocked.
I expect with care and crazy templates you could make a reactive framework for C++ if one chose.
Re: (Score:2)
Re: (Score:2)
so Reactive Programming is basically syntactic sugar making event handling a bit easier.
Fair enough... though I can't help thinking of Node.js and all those callbacks being heralded as a new revolution in programming when I hear about this stuff. As an old fart, I know there's nothing really new... just kids who think they need any new paradigm because they never had the balls to learn how the old stuff worked.
Re: (Score:2)
Point proven.
Marketing 101 (Score:5, Insightful)
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.
Re:Marketing 101 (Score:5, Funny)
Here's a quote for your marketing:
Q: How does reactive programming differ from procedural programming?
A: People use procedural programming, they only talk about reactive programming.
Re: (Score:2)
Re:Marketing 101 (Score:4, Insightful)
I think it's supposed to be being touted as a special new language because we need "reactive" programming hence the name "Reactive". The language may be "new", but I doubt it. I have not looked honestly, I looked at the claim on why it's needed and call bullox. I have mountains of libraries I have written for various tools in C, Python, Perl, and various scripting languages (TCL/WISH/SH). Most of those use bits of the mountains of libraries developed for those languages.
I'm getting cynical in my age I guess, but the majority of the claims people make are simply fluff to try and make a buck or name. Claiming that we need a new language for a special case is silly. Develop and release a library(or libraries) for your needs so that people can use it. Otherwise we end up with all these little tufts of crap that 3 people in the world use, and have to listen to them complain about why adoption is so low.
Re: (Score:2)
I'm getting cynical in my age I guess, but the majority of the claims people make are simply fluff to try and make a buck or name. Claiming that we need a new language for a special case is silly. Develop and release a library(or libraries) for your needs so that people can use it. Otherwise we end up with all these little tufts of crap that 3 people in the world use, and have to listen to them complain about why adoption is so low.
I can say this because your cynicism plays directly into my game. The new paradigm is Meta Programming. With my new Meta Programming tools I can write code in one single language and compile it into any other language that has an open source parser. My style guide language ensures the output code is consistent with whatever project I need produce code for. You are both the perfect candidate for, and also most likely not to learn such a language / platform.
That is why the creation of new languages and pa
Re: (Score:2)
Re: (Score:2)
Re:Marketing 101 (Score:5, Funny)
There really is no such thing,
Of course there is - I've been reactive programming for years. My boss yells at me to do something, and I react.
Re: (Score:3)
You clearly don't understand.
If you abstract the idea to a framework, and let the framework take care of the work, you have less programming to do.
And if your framework is domain-specific enough that it can watch one column and update another with very simple rules, without injecting a custom validation layer, then you have it very easy.
Your code base being 5 lines means that only 5 lines of code execute, and anything else that happens behind the scenes require no learning, support, fixing, bug reports, tes
Does it handle dupes? (Score:4, Informative)
How does RP handle dupes [slashdot.org]?
I know I put in my $0.02 previously, so I won't bother again.
Re: (Score:2)
So your reaction is to have proactively addressed the topic?
All methodologies are the same. (Score:5, Insightful)
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 [wikipedia.org] 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?
Re:All methodologies are the same. (Score:5, Insightful)
Absolutely.
The longer you spend in programming, the more you realize it's all been done in years past and it's just some "new grad" thinking they've invented something because they never looked into the history of programming techniques used over the years, or because they never happened to touch the systems that did it before.
I've been programming for over 35 years.
I've come to the conclusion that it's all about marketting buzz-words and bullshit to try and sucker investors into spending money, not about actually improving the way people write code or think about problems.
Re:All methodologies are the same. (Score:5, Insightful)
The nice thing is after 10-15 year or so, all problems start to look familiar to you, but not so much to the young guys or the managers. You can either rebel against the latest old thing new again and seem a Luddite, or seem a genius for immediately seeing all the pitfalls and optimizations entailed in the "new" idea.
Re: (Score:2)
OOP with the concepts of public functions and private variables is a big step forward in terms of the compiler being able to check your work. For anything where you are passing around complex business objects, some sort of OOP is necessary.
In the Java world, there are add-ons (Spring Roo) which simplif
Re: (Score:2)
What is he, a foetus? Magnetic tape is still around.
Re:All methodologies are the same. (Score:5, Interesting)
Like every other question about software development, we should always start with The Mythical Man Month. In this case, the relevant chapter is There Is No Silver Bullet.
Now, the interesting thing about that chapter is that, while it was right, it was the least right of all the good predictions Brooks made. No technology is a silver bullet, but many produce noticeable improvements that, when put together, can give us an order of magnitude in productivity over older tech. It's not as if OO has been abandoned. Case tools were replaced by the far more sensible powerful IDE. GUI builders are not used a lot nowadays, but we get many of their gains by having dev environments with tighter feedback loops. And there's of course the mother of all improvements, which is the creation of large, powerful libraries. How many of the things that people did for business applications 15 years ago are, today, just replaced by libraries?
Not that this denies your final thesis though: Hire bright programmers with people skills, and do your best to keep them. No technology will allow bad developers to make a good application.
Re: (Score:2)
You have to also realize that probably over half of software developers are willfully ignorant and therefore incompetent, which is why technology promotion on /. looks like a good path to larger acceptance.
Re: (Score:2)
Re: (Score:2)
then it's the median, but hey, let's try it:
{1, 2, 8, 8, 8, 8, 9, 9, 9, 10, 10}
2/11 (~18%) are smaller than the median.
5/11 (~45%) are larger than the median.
so you're wrong while you're wrong.
Re: (Score:2)
It still means that.
'older people'? I'm 48, so perhaps it is changing...
Re: (Score:2)
Yes, but in most any setting where everyone in the room knows that there are more kinds of averages than the arithmetic mean and uses them regularly, they will still probably only use the unadorned term "average" to mean just that - unless context dictates that some other average is implied.
Go ahead - tell any mathematician, statistician, etc to "calculate the average of these numbers" with no option for further clarification, I bet you at least 90+% return the arithmetic mean - not because there's no other
Re: (Score:2)
Really? If I say our neighbours are "just an average family" I don't mean they have a non-integer number of members.
I'd say the laymen's conception is closer to the mode.
Re: (Score:2)
All distributions are assumed Gaussian untl proven otherwise, as they will be a sum of a large number of random events. :-)
Re: (Score:2)
Average: a measure of central tendency. Mean, median and mode are different ways of measuring central tendency, i.e., they're 3 different kinds of average. Mean is just one kind of average.
Woohoo (Score:5, Insightful)
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
my question: (Score:2)
yeah...see this is true, and my question is WHY?
this happens predictably (at least for any rational person who looks at how this part of the computing industry changes over time)
but still people spend good time/money, sometimes lots of a few people's time, to make another and the cycle starts over again
is it possible to in
Taming CRUD? Only half way (Score:2)
I've been looking at ways to make CRUD applications "declarative" using almost nothing but data dictionaries (field tables) and attributes. It can be done for relatively simple and controlled scenarios, but if you have unanticipated requirements or are stuck using an existing database that has built up years of baggage/cruft, then it requires custom interventions.
CRUD is conceptually relatively simple, but the devil's in the details and those details can really be devils.
Yes, you can simplify CRUD by making
Re: (Score:2)
Can you screw your abstractions and forget to call them later? Do you have to use Gates condoms or will sheepskin work? What if your abstractions become pregnant? Is the offspring concrete? Should you have just prevented the problem by going with an int-er-face?
Re: (Score:2)
Can you screw your abstractions and forget to call them later? Do you have to use Gates condoms or will sheepskin work? What if your abstractions become pregnant? Is the offspring concrete?
I think you have the genders switched -- in this analogy, you're the woman. In particular, the abstraction is the boyfriend who can walk away scot-free if things don't work out, and you're the one who is stuck with an 18-year support obligation.
Re: (Score:2)
Re: (Score:2)
The line is blurry between them. Libraries for CRUD generally require or expect certain conventions be used. These conventions create a "framework" of sorts. But there are "controlling" frameworks and "voluntary" frameworks (for lack of a better term). Controlling frameworks control the "main" function(s) and flow, limiting you to writing event handler-like snippets.
Voluntary frameworks give you sample "main" function(s), and detail libraries, and let you use or ignore what you want. Controlling frameworks
should've tried Twisted (Score:3)
A Day at the Country Fair (Score:5, Funny)
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!
Re:A Day at the Country Fair (Score:5, Funny)
I bet you could use Web 3.0!
I'm going to wait for Web 3.11 for Workgroups.
Re: (Score:2)
I'm going to wait for Web 3.11 for Workgroups.
Yes... because having web apps where pressing 'cancel' on a login screen sounds like a great idea.
table based programming (Score:4, Interesting)
Re: (Score:2)
I'd step back even further and say it's a repackaging of wiring things together. Once we got away from magnetic cores and punched-cards, wiring things together wasn't modeled in code very much. If all of that were really great, we would have already been doing more spreadsheet and/or circuit-simulator based programming. That's not to say it doesn't have some nifty applications. Aren't there some cool GUI front ends to audio processors that work that way?
Re: (Score:2)
I'd step back even further and say it's a repackaging of wiring things together. Once we got away from magnetic cores and punched-cards, wiring things together wasn't modeled in code very much.
That's an interesting point that I hadn't thought about. Modern programming languages kind of get away from the 'wiring things together' approach, and even make it difficult.
Arguably though, that is how the brain is constructed.
Re: (Score:3)
Table-oriented programming strikes me as a fancy name for something much older: data driven programming. Control structures which are pre-defined as "tables" of data that get interpreted at run-time.
Re: (Score:2)
functional (Score:4, Interesting)
this is just rebadged functional programming, except using deliberately confusing syntax
Re: (Score:2)
Actually, it's not. Functional languages do not necessarily re-evaluate expressions. Take Erlang for example.
Rather, functional languages like Erlang explicitly do not allow RE-assignment of variables: assign once logic.
You're thinking of an expert system, which *does* re-evaluate expressions and rules based on the dependency tree it builds up while loading the rules.
Re: (Score:2)
Most functional languages are rather a way of expressing multiple function signatures and having the run-time decide which is the best match based on the parameters at run-time, not compile-time.
Re: (Score:2)
Most functional languages are rather a way of expressing multiple function signatures and having the run-time decide which is the best match based on the parameters at run-time, not compile-time.
You should be stripped of your 5-digit ID for that statement.
You just described duck typing, while the opposite (static typing) is typically encouraged in functional languages.
Re: (Score:2)
I don't claim to know all functional languages. That's why I qualified my statements with "Erlang", which happens to be a well known language that is classed as "functional."
And it is most emphatically not statically typed.
Re: (Score:2)
Higher level functional specifications are like generics. They match some generic set of parameters regardless of the types of the parameters. They then invoke other functions, some of whose overloads specify types, and usually a generic fallback.
Until run-time, there is no information about what the generics passed to that higher level function are, so there is no way to use static typing from compile time analysis.
Another aspect of some functional languages is that they make it easy to pass generic
Re: (Score:2)
In short, the whole point of a functional language is to express generic algorithms and procedures in terms of generic types. To re-use the logic of one specification across a swath of data types.
While you could express multiple overloads of the algorithms, each specified in terms of specific types, that would be missing the whole point of functional programming.
Re: (Score:3)
Not entirely. Of course you can model A=B+C as a function A which, when evaluated, returns the sum of B and C. And sure, you can evaluate A() several times and get different results if B or C have changed.
Reactive programming is about the future and expecting change. When B or C changes, notification of that change is pushed up to the eventual recipient.
But it's more than just simple event handling. For example, what if you wrote a complex SQL query against a few dozen tables located on a hierarchy of s
Re: (Score:3)
Or, one could call it "push based, instead of pull based" if one were eschewing obfuscative nomenclature.
Re: (Score:2)
Re: (Score:3)
Not entirely. Of course you can model A=B+C as a function A which, when evaluated, returns the sum of B and C. And sure, you can evaluate A() several times and get different results if B or C have changed.
Reactive programming is about the future and expecting change. When B or C changes, notification of that change is pushed up to the eventual recipient.
So let me get this straight instead of polling the keyboard and mouse port constantly, with Reactive Programing we can just have them generate an interrupt which calls a handler and it calls functions which calls functions to propagate this state change event into other waiting batches of code until the end result is generated -- Updating a cursor location or activating keystroke command, etc. Wow, that's pretty revolutionary. Someone should invent the shit out of that so that the CPU can just sit on a HA
Re: (Score:2)
...Or Seaside even. [seaside.st]
The great coroundrum (Score:2)
But a superior ending would be "Don't you agree?"
Because any response to "Don't you agree?" is better for marketing FUD because any potential answer ("Yes", "No") can be interpreted with being in agreement with the leading question?
(This comment is revelvant specifically because the term is "Reactive programming" is a worthless marketing buzzword and
Toy Example (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Equally troubling is the screwy premise. In most cases, once the PO issues the price is fixed. Reacting to changes in product.price would be incorrect. That's the whole reason for having a product_price field in lineitem. If that isn't the case, then as you say the duplicate is self-inflicted damage. I also don't see why you would ever reassign a line-item row to another product, you toss it and create a new one.
I know it's hard to present a complete example in a neat little package, but when I see an examp
Re: (Score:2)
What has me particularly troubled is that it talks about amount being sum(items*price) while in the "Just five lines of reactive programming" it has
Derive credit_limit as sum(purchaseorderList.amount_total where paid=false)
As far as I can tell, this allows people to order as much stuff as they like, and only when they try to pay for it will it be blocked.
On the positive side, if someone has ordered 10000 widgets at $10 then the sales rep decides to have a 2 for the price of one offer for the next 50 custome
This is rules based programming (Score:2)
See JBoss Drools, JRules, Blaze, etc.
what "Reactive Programming" really is (Score:4, Informative)
from what i've read on wikipedia, [wikipedia.org] "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
Re:what "Reactive Programming" really is (Score:5, Funny)
from what i've read on wikipedia, [wikipedia.org] "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
c=a + b ...behold the infinite loop is born!
Re: (Score:2)
behold the infinite loop is born!
Good. Any language that can't do an infinite loop is rubbish.
Spreadsheets are lousy programming models (Score:5, Interesting)
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.
Re: (Score:2)
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.
Sort of an off-topic question -- why is Excel the chosen programming 'language'/model for non-programmers? Are there design concepts that come into play to assist the non-programmer or any human when you lay out your data/variables visually?
Re: (Score:2)
I would guess because a spreadsheet makes dealing with variables -- both scalars and arrays -- easy, where "dealing with" includes data reduction, visualization and editing. Derived values are updated automatically, you can trivially pull up at least a few common visualizations, and the software includes a solid library of basic statistical and other mathematical functions. I am a professional programmer, proficient in GNU Octave in addition to various compiled languages, but the reasons I listed are why
Re: (Score:2)
Another post above points out the cause of the issue - one change can kick off a fannin
Re: (Score:3)
I was about to add 4) Unstable cycles - the formula your program represents may not be satisfiable, in which case it can never settle down to a consistent set of values.
If that is the case, however, then either your problem is not solvable or your model of it is faulty, and the program implementing it would be wrong whether it used reactive programming or not.
This suggests a partial solution to the synchronicity problem: whenever the event queue is empty, you have a consistent solution. This is OK for sprea
Horseshit. (Score:3, Insightful)
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!
Re: (Score:2)
Indeed, it's shocking that anyone ever chooses a language or platform other than the database for doing complex application logic. Certainly couldn't be a limitation of the tools or languages available in the DB, those are top notch for every business case.
This is absolute bullshit. (Score:3)
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.
Reactive Programming = COME FROM label (Score:3)
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.
Been there broke that (Score:2)
Exploiting ambiguity to latch onto hype (Score:3)
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 [reactivemanifesto.org] and related technologies (e.g., Akka [akka.io], Rx [codeplex.com], Node.js [nodejs.org], 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".
How is this just not callbacks? (Score:2)
This seems like the way nodejs works, where everything is done in a callback (anonymous function). Maybe you layer a triggering framework on it but that's all it is.
This is the second "reactive programming" article and I don't think it's anything other than callbacks. Someone is trying to get PR for some paradigm they think they invented.
The *read deal* with "Reactive Programming (Score:2)
Both slashdot articles are authored by "ValHuber [slashdot.org]" who works at Espresso Logic [espressologic.com] Expresso Logic's web page is bannered by
"Reactive Service for SQL Data
RESTful API with reactive logic and security in 4 easy steps
Dramatic reduction in development & maintenance time"
I think it is time we stop marketing for this consulting company.
Why do we reinvent wheels? (Score:2)
This is just forward-chaining logic programming. I.e., if x changes then do y, and people have been using this in design for years - several large vertical applications have this feature built in.
The problem with this kind of code is that, when there is contextual dependency on what is to be done (which happens often in real life), the code becomes riddled with special cases accessing data from far flung parts of the system to determine the contextual state - this starts to look akin to spaghetti code with
Re:History repeats (Score:5, Interesting)
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.)
Re: (Score:3)
Re: (Score:2)
There is an anti-learning bias I think. More and more programers who think the past was stupid and not worth studying, with languages that only old irrelevant people learned, and system designs that are irrelevant for today, and theorems and equations that are hard and difficult and thus to be skipped.
Re: (Score:2)
Re: (Score:2)
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.
But that isn't reactive; it's still polling.
Reactive is the opposite of polling. E.g. if you wanted Makefiles to be reactive, your filesystem would need to notify when a change occurs, and then that change would immediately cause a compile (or whatever it is in your data calculation case) of only the pieces that are directly affected by that, and so on up the chain until the final result is produced.
If you have to type "make [...]" or set up a cron job, you aren't doing reactive.
Re: (Score:2)
Yeah, that's "reactive programming" at the file level. I do it all the time, with Makefiles. ...
But that isn't reactive; it's still polling. ... you have to type "make [...]" or set up a cron job, you aren't doing reactive.
So who said anything about typing "make"? It's quite common for, e.g. a web CGI program to start a "make" process after the client input has been written to the appropriate files. The CGI program can then proceed or exit, and make's updates will happen in the background. It's also not uncommon to see Makefile commands of the form "cd some/dir; make foo" as part of the update process.
This isn't materially different from a write/assign triggering a cascade of updates via some routine deep down in the
Re: (Score:2)
Your filesystem notifications or DB reactions are either coming from a polling loop in the FS/DB engine, or from an event processing loop in the FS/DB engine.
The system calls you use isn't the question. It's about how your implementation works, not about external implementations you don't control.
Let's think hierarchically. Make is smart and will check all intermediate output, all the way down to the leaves of its target tree, to see if it needs to do anything. If all the leaves are older than the final output, make doesn't do anything. If a level 5 leaf is younger than the final output file, make reevaluates that leaf and its level 4 parent, its level 3 gra
Re: (Score:3, Interesting)
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 simple
Re: (Score:2)
This crowd is merely giving us another entry in the rather long list of isomorphic systems that differ only in their terminology.
Hey, if it gives the marketing folks a way to keep themselves busy, while I get to keep doing things the same way as always, it sounds like a win for everyone.
Or Logic Programming (Re:Isn't this SQL?) (Score:2)
I was thinking along the same lines, except that I would say 'relational' rather than 'SQL' because SQL is neither the only nor the ideal implementation of the relational model.
In one significant way they are different, however. Part of Codd's insight was that the deductive power of his model should be less than Turing-complete, so that issues of undecidability don't arise (triggers were not part of Codd's model.) This restriction made automatic query optimization and reasonable transaction times feasible,
Re: (Score:2)
Yes and no. Really its just javascript callbacks. The QML system is just giving you a framework of automatic callbacks. At the core it works a lot like nodejs