Why Reactive Programming For Databases Is Awesome 165
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?"
Re:I for one would love to see DBs be more like Ex (Score:5, Insightful)
Spreadsheet programming (Score:4, Insightful)
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?
Re:Spreadsheets? (Score:3, Insightful)
A trigger on INSERT or UPDATE of a watched entity should kick off an INSERT into a message queue, and a trigger on INSERT in the message queue should run a script to send the message where it needs to go. Now you have a self-managing, self-logging, asynchronous system that only uses system resources when needed.
Don't reinvent the wheel. Do learn your craft and become a master at it.
This was solved decades ago. Next question, please.
Re:Spreadsheets? (Score:4, Insightful)
A trigger on INSERT or UPDATE of a watched entity should kick off an INSERT into a message queue, and a trigger on INSERT in the message queue should run a script to send the message where it needs to go. Now you have a self-managing, self-logging, asynchronous system that only uses system resources when needed.
Yes, exactly. OK, sometimes it can actually be a little tricky to figure out who needs notification and what data they need, but that's application/business logic that just needs to be worked out. (Example: client was not interested in a particular "master" record, and therefore has not received it, but the addition of a particular "detail" record means that client is now interested, so sending the changed record is not enough, the update needs to include the master and all related details. And so on and so forth, for a really rich app with rich workflow, there winds up being a surprising amount of logic required to get the right updates but no more than needed out to each client.)
This was solved decades ago. Next question, please.
Well... No, not really, at least not that I know of. The ability for "trigger on INSERT in the message queue should run a script to send the message where it needs to go" has actually *not* been around for decades. For way too long, this had to be a process *polling* the message queue. Triggers were limited to whatever "procedural SQL" flavor your db had, and had no access to file or network resources. Now you can write triggers in many languages, sometimes with full access to the system. Now you can from a SQL trigger send a notice, which a client can listen for via select/kqueue/libevent etc. But that's all much more recent.
Re:I for one would love to see DBs be more like Ex (Score:2, Insightful)
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.