Slashdot Mirror
Why Reactive Programming For Databases Is Awesome
Nerval's Lobster writes "'Building on many lessons learned from spreadsheets, functional languages and model-driven application development environments, Reactive Programming (RP) is a recent approach to creating applications,' Val Huber, CTO of Espresso Logic, writes in a new column. 'In the RP paradigm, you can create complex applications from a series of simple declarative statements. Many of the details of implementation and work of gluing together various sorts of application constructs can be hidden because of the declarative approach.' He goes on to argue that RP makes maintenance easier and applications more adaptable, because RP offers automatic dependency management and reuse; at the same time, he also acknowledges that RP has some shortcomings. What say you?"
I think excel is one of the greatest programs ever and reactive programming sounds great. This article isn't very specific as to how to get started though. Is it a concept, a product or something I have to implement myself?
Interesting.
Code modeled in RP sounds like VHDL, Verilog et all - the languages used to model modern Programmable Logic Arrays, Programmable Gate Arrays and Programmable Logic Devices - aka, hardware.
No doubt this approach has its merits, but this kind or "programming" has its gotchas - a lot of gotchas.
I stand aside for now, looking with great interest.
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
Did this guy just reinvent spreadsheets? There's something to be said for this, but having written in Prolog, which works that way, the 'reactive programming' people have to make a better case than the article does.
On the other hand, one of the big problems in databases is change notification. Microsoft at one point had a research project on this. The concept was that you could make a request to be notified when something of interest changed in the database. This was expressed as an SQL SELECT statement. When some change was made that would affect the output of your pending SELECT, you'd be notified. The problem was to figure out some efficient way to do this with thousands or millions of pending SELECT statements.
Finance people use notifications like that all the time. Limits on stocks, limits on combinations of stocks, changes in key ratios, that sort of thing. But the systems for that are specialized, a special case of a more general problem. The most general form of the problem is that B wants to know when something has changed at A. Most of the solutions for this have problems. Polling is either inefficient or slow. B relying on A to message them on a change has a failure problem. Both approaches can result in overloading A with checks for events that aren't happening.
From the article description I couldn't figure out a) what is actually reactive programming; b) how will that help me build better applications. Complex applications are already built from a series of simple declarative statements. In fact, we call the most simple declarative statements language available "assembly". We call the machine representation of those very complex applications built with simple declarative statements "binary". On the other hand, Brainfuck also allows you to build complex applications with very simple statements, and I'm not migrating to it anytime soon.
Not cool, Slashdot, I'm going to have to read TFA!
Usually database manuals calls them triggers.
I can see this being useful for problems that are extremely linear and require extreme parallelization on large quantities of data, but that's about it.
I've done this 'methodology' many times using Excel. I did it because I I needed to give the spreadsheet to other people, and wanted to avoid having Office nag about 'potentially dangerous VBA'.
It makes it very easy to see *exactly* how your data is flowing, which is a bonus. It also uses a *lot* more ram because you are now maintaining a permanent block of memory for every single operation, for every different piece of data you are coding against. Of course, the second you get a cyclic dependency, the whole thing blows up.
But this method of 'programming' was a natural and convenient extension based on how Excel (or any spreadsheet) operates. Nothing more.
Is it just me, or does it seem like everyone now-a-days is trying very hard to come up with new methodologies and paradigms and web 6.5isms, so they can get their 5 minutes in the lime light?
I remember experimenting with a C++ framework that would work somewhat similar. Lazy evaluation and such. http://sourceforge.net/projects/ditto, it's long since been abandoned because, well... the only thing this way of programming solves is a small part of the "R" in "CRUD". It worked brilliantly for showing information on screen and automatically updating all kinds of stuff whenever some data changed, but in the end it only solved the least difficult part of creating an application, and doing so at a relatively high CPU% cost.
It was also supposed to have lazy/dynamic/late-binding expressions (i.e. lazy_int a = b + c;), but it turns out you only very rarely have any use for that type of expressions. At the time, there were also far superiour C++ frameworks being developed which could do these things as a side effect of supporting more useful programming models.
This RP thing doesn't really seem to do anything more than that.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
No, the article is just terrible at explaining what FRP is. The idea of FRP is that you stop simply having the idea of having values, and start having the idea of "time varying values". So instead of having an int, which I change the state of at a bunch of times, I can have a Reactive which represents the value of the int at all possible times. You can then treat these as first class citizens, which you can manipulate, so if you have a Reactive representing the time, you can do things like time + 1, and get a new reactive int representing one second later than the current time.
These can be combined in much more complex ways to produce much more interesting behaviours than "hey, what will the time be in one second".
You can see a simple example of this, describing the n-bodies problem here http://noordering.wordpress.com/2009/02/01/simulating-n-bodies-and-functional-programmingre/
Vampires do not fear silver bullets. They fear stakes and sunlight. Werewolves fear silver bullets.
Write failed: Broken pipe
to /active/ programming.
Anyways, seriously, please, please please my fellow programmers. Don't jump
on this just because it looks or sounds esoteric.
is in its usual place.
OK, B+C can be evaluated once when you assign A, or it can be evaluated every time you evaluate A. Sometimes you know that A will not change after you calculate it, or that a fresh value of A is required, and sometimes you don't.
Delaying the evaluation of A is usually safe; but it can sometimes be very slow. Like it or not, performance still matters. If you evaluated A unnecessarily inside a tight loop in a game, you'd be dead. Even less CPU intensive thinks like web apps could be killed by this kind of thing, if A is evaluated in JavaScript every time you move your mouse pointer.
Evaluating A every time is not only slow, it might not even be correct. Let's say you pull in some weather data and then render a map. The frontal zone should be a smooth line. If you pull in new frontal boundary data while rendering the map... you'll render a broken front.
Sorry. It looks like the programmer still has to think. Re-calculating A every time the symbol A occurs may or may not be required.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Yeah, and in client side systems they're known as call-backs or event driven, etc. etc.
I don't know about you, but if it's old let's call it new!
In Coursera's Reactive Programming MOOC, the difference between reactive programming event-handling and traditional event-handling is described in two slides from the introductory lecture:
http://subbot.org/coursera/reactive/callbacks.png
http://subbot.org/coursera/reactive/howtodobetter.png
A traditional Java event-handler is first presented, and the problems enumerated: it relies on a side-effect (the variable "count" in the example), which involves shared mutable state; events and their handlers are not first class. Reactive programming tries to do better so that complex handlers can be composed from primitive ones.
Good god (or in this case bad god)
Every damn company I have ever worked in has some (albeit smart) idiot who creates a smart excel/access application which does wonderful things.
Who then distributes it to xyz people
Then the datasource (ip address) changes and the thing breaks.
Or the datasource changes (database table changes) and the thing breaks
Or his hardcoded status codes changes or is expanded and the thing breaks
Then they call you out of the blue and say, please fix it!
Access is an evil which should die. Advocates of it are welcome to come debate the matter with me. I need fresh meat.
Excel is extremely powerful and a handy tool, but as soon as anyone adds a datasource they should come and debate the matter with me.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
Event-driven programming is HELL
Isn't that right there a good reason for it being implemented once, correctly, as a core OS/language feature so that the programmer doesn't have to micromanage all the interactions, and instead just say 'this is a dependency on that; event engine, you sort it out'?
For better or worse, ever since the mouse we've lived in an event-driven world. From what I can see, it's mostly worse, because our software tools haven't adapted to minimise the complexity, so we have the monstrous Byzantine complexity of signals, slots, callbacks, etc. RP - if it were done properly - seems like a good way of encapsulating a lot of this back into the system levels where it belongs.
I agree that RP has to have rock-solid formal semantics for it to be dependable; that's a job for computer scientists rather than library programmers, so I hope somone in PhD land is looking seriously at this.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
I see that you've used that word in your reply, and therefore I have to conclude that you have no idea what you were talking about. ;-)
The Tao of math: The numbers you can count are not the real numbers.