×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

How Reactive Programming Differs From Procedural Programming

samzenpus posted about 10 months ago | from the talk-amongst-yourselves dept.

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?"

Sorry! There are no comments related to the filter you selected.

I thought that we were supposed to be pro-active.. (1)

PaulBu (473180) | about 10 months ago | (#45946035)

not re-active! ;-)

Paul B.

Re:I thought that we were supposed to be pro-activ (1)

Anonymous Coward | about 10 months ago | (#45946081)

Hello, Paul. How are we doing this evening? ;)

Re:I thought that we were supposed to be pro-activ (1)

icebike (68054) | about 10 months ago | (#45946193)

Point proven.

Re:I thought that we were supposed to be pro-activ (0)

Anonymous Coward | about 10 months ago | (#45946577)

Absolutely...there's not nearly enough RFC 6921-compliant [ietf.org] applications.

Re:I thought that we were supposed to be pro-activ (3, Informative)

bondsbw (888959) | about 10 months ago | (#45947583)

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.

Re:I thought that we were supposed to be pro-activ (-1)

cheater512 (783349) | about 10 months ago | (#45947781)

Guess how reactive programming works? Yep. Events/triggers.

A = 1
Run all events watching variable A
Repeat until all the events have cascaded.

Don't kid yourself that it isn't fundamentally a style implemented with events.
There is no way for memory locations to be 'reactive' so you need a event to trigger the additional changes.

Re: I thought that we were supposed to be pro-acti (2)

KramberryKoncerto (2552046) | about 10 months ago | (#45947885)

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.

Re:I thought that we were supposed to be pro-activ (2)

bondsbw (888959) | about 10 months ago | (#45947917)

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:I thought that we were supposed to be pro-activ (1)

blackraven14250 (902843) | about 10 months ago | (#45948001)

It's a level of abstraction. If the only difference is that a "reactive" paradigm allows you to write the same code in less lines, each of which is less complex, it's an improvement over creating events/triggers. I don't know whether that's actually the case, but if it is, the above applies.

Marketing 101 (4, Insightful)

s.petry (762400) | about 10 months ago | (#45946071)

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 (5, Funny)

Anonymous Coward | about 10 months ago | (#45946213)

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:Marketing 101 (1)

danbuter (2019760) | about 10 months ago | (#45946421)

So, is this a new slant on Agile Programming?

Re:Marketing 101 (3, Insightful)

s.petry (762400) | about 10 months ago | (#45946663)

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:Marketing 101 (0)

Anonymous Coward | about 10 months ago | (#45948311)

Most of these new flava-flav languages are usually interpreted, or at the very best, badly JITed. So the performance will be worse than your mountains of existing C libraries. Certain also, the esoterism these flava-flav folks will foist on you will place an enormous burden on you, reducing your productivity as much as it does reduce your program's performance.

Anyone who doesn't know and understand that you can implement ANY programming paradigm in C without even trivial difficulty or obfuscation, shouldn't be programming in ANY language. Unfortunately this is 90% of working programmers today. And a single bad programmer creates much work for many good programmers. Oh god, what a sorry state the industry is in.

Re:Marketing 101 (1)

jythie (914043) | about 10 months ago | (#45947025)

It looks more like a domain specific language with a propriety tool/library of some type. Anything that can, as they claim, reduce 500 lines of code into 5 lines probably is not terribly general purpose. It looks like it is just a rebranding of event driven programming only done in their own tool rather then a standard language, probably doing a few things automagically and a whole bunch of stuff badly.

Re:Marketing 101 (4, Funny)

sunderland56 (621843) | about 10 months ago | (#45946529)

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:Marketing 101 (2)

Bite The Pillow (3087109) | about 10 months ago | (#45947799)

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, testing, or really any attention at all, because it works for your domain-specific problem.

So, you have your "ordering" framework, one for "matching address rules to geographical locations" validation framework, your "content management system that uses plain text to deliver content" framework... oh, there is a framework for every need. That's how simple it is.

And, NO ONE HAD TO WRITE THE FUCKING FRAMEWORK.

That last part is the important one, it's how you achieve time to market and bug-free nature of the code. Just give up and believe.

History repeats (0)

Anonymous Coward | about 10 months ago | (#45946115)

We used to make websites by regenerate all html pages when the database changes. It delivers really fast then.

Re:History repeats (4, Interesting)

jc42 (318812) | about 10 months ago | (#45946695)

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:History repeats (2)

jythie (914043) | about 10 months ago | (#45947057)

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?

Re:History repeats (0)

Anonymous Coward | about 10 months ago | (#45947107)

Not only that, anything that is picked has already been discarded though experience. Cloud, thin clients, whatever this deadlock hell garbage is.

Re:History repeats (1)

Darinbob (1142669) | about 10 months ago | (#45947913)

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:History repeats (1)

bondsbw (888959) | about 10 months ago | (#45947259)

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:History repeats (0)

stoborrobots (577882) | about 10 months ago | (#45947563)

If you have to type "make [...]" or set up a cron job, you aren't doing reactive.

That's a little disingenuous - there will always be a tool in the chain whose job is to continually check for changes and trigger the recalculation. Whether that tool is a cron job or a trigger in a db, or a specially built "reactive" engine, something is doing that job.

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. Externalising that loop into a cron job doesn't change what it is.

Reactive programming amounts to writing a 10 line Makefile which is "automatically" (i.e. set up by someone else) called by inotify/FSEvents or by cron, instead of writing a 200 line shell script to watch a directory for changes and call gcc and/or yacc when needed.

Re:History repeats (1)

bondsbw (888959) | about 10 months ago | (#45947897)

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 grandparent, etc. to the top. It will use any intermediate outputs that were already generated where possible.

Here's where reactive is different: true reactive programming would being at the level 5 leaf that changed, as a direct result of it being changed. No continuous polling loop would be used in your implementation (again, the OS implementation is external to this). Such a "make" would not even need to make any check on the file modification date/time. It would know that the file it is notified about will always be the direct reason for causing a recompile, and it would go up the tree to produce its intermediate outputs as well as the final output, just like normal make.

Re:History repeats (0)

Anonymous Coward | about 10 months ago | (#45948411)

No it's a different algorithm:

In your inotify Makefile example:

1. Some program calls inotify on all the files in the source set.
2. When inotify indicates a file change, it executes make -f $makefile
3. Make reads the toplevel makefile
4. Make walks the filesystem tree, inquires the mtime of every source file and every object.
5. for each recipe which is dirty, make executes the recipe, potentially invoking make recursively.

This results in a massive amount of work checking file entries which aren't dirty, and executing recipes recursively for files that *could* be stale.

In a real constraint propagation example (which is what this "Reactive Programming" seems to be a reinvention of):

1. A program calls inotify on the set of source files.
2. On notify, it looks at the source file's constraints, and rebuilds it.
3. It then walks the constraint tree, recursively rebuilding or relinking objects which either depend on that source file or the object file.

The difference here is that the tree is walked down from leaves to root, by propagating what has been damaged by rebuilding, starting at the source file. With Make, even triggered in an automatic fashion, it still walks the tree from the root to the leaves, pruning branches only when it can be certain those branches contain no dirty leaves, resulting in a massive amount of unnecessary work, that is avoided in the later scenario by using the knowledge provided by the notify event.

It gets better, when you have an online compiler (one that keeps the internal state between compilations), you can then track changes to the code function by function or statement by statement, and recompile on the fly. The amount of code that needs recompilation with each edit in an online compiler is usually so negligable that the user will never perceive a compilation happening. I used to use compilers that worked this way in DOS, though it seems to have gone out of fashion as computers have got faster and compilers slower. For large code-bases like Linux and Webkit, I really wish I had an online compiler today.

Re:History repeats (0)

Anonymous Coward | about 10 months ago | (#45948357)

Dude, I had DOS compilers in the early 90's that did this, they called in "Online Compilation". Somehow with all the unix hero-worship, since online compilation was NIH in the unix world, the idea was discarded like so many good ideas destroyed by the Unix cult's NIHism.

Re:History repeats (2, Interesting)

stoborrobots (577882) | about 10 months ago | (#45947313)

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.

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?")

Does it handle dupes? (3, Informative)

istartedi (132515) | about 10 months ago | (#45946127)

How does RP handle dupes [slashdot.org] ?

I know I put in my $0.02 previously, so I won't bother again.

Re:Does it handle dupes? (1)

bob_super (3391281) | about 10 months ago | (#45946261)

So your reaction is to have proactively addressed the topic?

Re:Does it handle dupes? (0)

Anonymous Coward | about 10 months ago | (#45946745)

Agreed. No idempotency and the other thing is a lack of audit artifacts, unless he's logging events within the Database layer.
Database shouldn't be logging parameters and stuff. That's clearly application stuff.
Stuff like this would be a nightmare to audit :(

All methodologies are the same. (5, Insightful)

hamster_nz (656572) | about 10 months ago | (#45946143)

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. (0)

Anonymous Coward | about 10 months ago | (#45946243)

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?

Yes. Yes. Yes. Yes. And some really nasty-ass "4GL" languages in there too.

Re:All methodologies are the same. (1)

Anonymous Coward | about 10 months ago | (#45946255)

Careful about using the word average.
It is quite possible that a small subset gets it all wrong & skews the results:

Take the set {10, 9, 8, 9, 8, 9, 8, 8, 10, 1, 2}

The number of members is 10
The sum is 74
The average is 7.4

80% of the members of the above set are above average.

It is quite possible that 80% of people get over-average results if you have one or two data points that skew average.

Re:All methodologies are the same. (1)

Lehk228 (705449) | about 10 months ago | (#45946353)

not if you use median for average

Re:All methodologies are the same. (1)

maxwell demon (590494) | about 10 months ago | (#45946405)

If you use median, it's median, not average.

Re:All methodologies are the same. (1)

Anonymous Coward | about 10 months ago | (#45946469)

Depends on who you talk to. It used to be that "average" could refer to any of several measurements that looked at the central tendency of a distribution, including median and mode in addition to mean. There seems to be more of a trend teach that decades ago though, so it is more common with older people with math background or even just grade school math, while people now are mostly taught that mean and average are synonyms. And not to be confused with when mean included things like geometric and harmonic mean...

Re:All methodologies are the same. (1)

dwater (72834) | about 10 months ago | (#45946997)

It still means that.

'older people'? I'm 48, so perhaps it is changing...

Re:All methodologies are the same. (1)

Immerman (2627577) | about 10 months ago | (#45947571)

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 options, but because if any other average were meant it would probably have been specified for clarity.

Cooking analogy - if a recipe calls for sugar you will probably be best off using a medium-coarseness cane or beet sugar with a 50/50 glucose/fructose distribution - not because there aren't hundreds of different types of sugar with different flavor profiles and cooking properties, but because if they meant one of those other kinds the recipe would have called for "______ sugar", the fact that it did not implies that they meant the common usage - plain, ordinary table sugar.

Re:All methodologies are the same. (1)

fisted (2295862) | about 10 months ago | (#45946879)

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: All methodologies are the same. (0)

Anonymous Coward | about 10 months ago | (#45946375)

I have a _mean_ solution for that problem

Re:All methodologies are the same. (1)

hamster_nz (656572) | about 10 months ago | (#45946673)

All distributions are assumed Gaussian untl proven otherwise, as they will be a sum of a large number of random events. :-)

Re:All methodologies are the same. (4, Insightful)

msobkow (48369) | about 10 months ago | (#45946595)

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. (4, Insightful)

lgw (121541) | about 10 months ago | (#45947513)

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:All methodologies are the same. (1)

dbialac (320955) | about 10 months ago | (#45947813)

I'm actually looking at this one to a degree as an example of how not to build scalable database systems.

Re:All methodologies are the same. (0)

Anonymous Coward | about 10 months ago | (#45948407)

+101

To quote George Santayana: "Those who cannot remember the past are condemned to repeat it."

One of my young colleagues once refused to believe that there was ever such a thing as a magnetic tape ...

Re:All methodologies are the same. (4, Interesting)

hibiki_r (649814) | about 10 months ago | (#45946701)

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:All methodologies are the same. (1)

socode (703891) | about 10 months ago | (#45948269)

"Although we see no startling breakthroughs, and indeed, believe such to be incompatible with the nature of software, many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate, and exploit them should indeed yield an order-of-magnitude improvement."
  -- Brooks

I can't agree this was the least right of all of his predictions - he said exactly what you intimated he was wrong about. On that, he was bang on, and it's less surprising since it was an epistemological prediction. The area he was least right about was the rate of technological progress, which is much less fundamental, and therefore underestimated how quickly tools, storage, and compting speed would increase, with a consequent impact on the size of development team, production of documents, automation of testing and so on.

Re:All methodologies are the same. (0)

Anonymous Coward | about 10 months ago | (#45948059)

Yes, I do remember JSP, and II have to say it worked for me. But I always recognised that other members of th team simply didn't need that approach.

Woohoo (5, Insightful)

viperidaenz (2515578) | about 10 months ago | (#45946151)

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

Re:Woohoo (0)

Anonymous Coward | about 10 months ago | (#45946317)

Is that a dig at Paul Graham?

my question: (1)

globaljustin (574257) | about 10 months ago | (#45946483)

Yet another super awesome framework/system/language/whatever to make a shopping cart in as few lines as possible.

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)

someone tries to build something remotely complex and it all falls to shit

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 interview for a company, or be the head 'coder' during a major decision time for a new client or product, and just say, "No, from a coding perspective this is theoretically possible but it can't be done. This is bad design and we can code something that has this function and meet our quality standards."

can that happen?

Taming CRUD? Only half way (1)

Tablizer (95088) | about 10 months ago | (#45947403)

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 certain presumptions. However, if you have to violate those presumptions, then your clean abstractions take a big hit to the nuts and the fixes are messier than what you'd get hand coding most of it from scratch or from minimalist libraries.

That appears to be "trick" used here: when your scenario lines up nicely with your framework's assumptions, the framework handles most of the grunt work like magic. It's essentially a circus trick for the naive.

Until the day CRUD is somehow finally fully tamed with a great framework that handles all the goofy needs of specific shops, my preferred compromise is to use "smallish" abstractions, AKA "helper routines" that can optionally be used to simply things, but are NOT required. I like to say you need a way to: date your abstractions, but not marry them.

And these components have sub-components that can be partially used as needed also so that I only have to reinvent 1/3 of the wheel if I can't use the whole component. That way real-world requirements that "break" my larger-scale abstractions don't entirely boot me out of the framework (to be left hand coding all the details) because I can still use most of the smaller-scale abstractions that the bigger ones were built out of. It's kind of a fractal "next resort" down the abstraction ladder.

It's not perfect, but a decent compromise between hand-coding all from scratch and (alleged) do-it-all frameworks (like TFA) that are not flexible. But, you do have to know the parts well.

Re:Taming CRUD? Only half way (1)

Bite The Pillow (3087109) | about 10 months ago | (#45947823)

date your abstractions, but not marry them.

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?

Does not matter (0)

Anonymous Coward | about 10 months ago | (#45946191)

The problem is not the model, but the idea that one size fits everything.

And the biggest problem is that the management, and very often the developers are unable to switch between the different approaches.

It is simple, you want something fast and dirty, and right now? REACTIVE

You got the market, and now is time to make your product stable and reliable? SWITCH TO CONVENTIONAL.

As simple as that.

should've tried Twisted (2)

smoothnorman (1670542) | about 10 months ago | (#45946207)

what it takes to implement business logic using Reactive Programming versus two different conventional procedural Programming models: Java with Hibernate and MySQL triggers,'

...Twisted/python is perhaps a more sensible established comparison for event-driven, or not. besides... "business logic"?

A Day at the Country Fair (5, Funny)

MightyMartian (840721) | about 10 months ago | (#45946223)

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 (4, Funny)

similar_name (1164087) | about 10 months ago | (#45946297)

I bet you could use Web 3.0!

I'm going to wait for Web 3.11 for Workgroups.

Re:A Day at the Country Fair (1)

girlintraining (1395911) | about 10 months ago | (#45947553)

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.
 

Re:A Day at the Country Fair (-1)

Anonymous Coward | about 10 months ago | (#45946415)

"Buzz word" is just a buzz word used for people who don't know what they're talking about.

spreadsheet (0)

Anonymous Coward | about 10 months ago | (#45946289)

Sounds like the spreadsheet engine has grown up!

mod ,up (-1)

Anonymous Coward | about 10 months ago | (#45946381)

guys are usuaaly GAY NIGGERS from These challenges learn what mistakes FreeBSD went out These early pro-homosexual would take about 2

table based programming (3, Interesting)

phantomfive (622387) | about 10 months ago | (#45946387)

Isn't reactive programming essentially a repackaging of Table Oriented Programming? [c2.com]

Re:table based programming (1)

istartedi (132515) | about 10 months ago | (#45947009)

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:table based programming (1)

phantomfive (622387) | about 10 months ago | (#45947443)

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:table based programming (2)

msobkow (48369) | about 10 months ago | (#45947041)

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.

functional (3, Interesting)

Lehk228 (705449) | about 10 months ago | (#45946413)

In imperative (procedural) programming, A=B+C is an assignment statement. A is set when the assignment statement executes. Subsequent changes to B or C do not affect A, unless you specifically re-calculate A. Software developers are responsible for understanding and managing these dependencies.

Reactive programming is a declarative approach for defining logic. Variables are defined by expressions such as A=B+C, which automatically reacts to changes in B or C.

this is just rebadged functional programming, except using deliberately confusing syntax

Re:functional (1)

msobkow (48369) | about 10 months ago | (#45946999)

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:functional (1)

msobkow (48369) | about 10 months ago | (#45947013)

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:functional (0)

Anonymous Coward | about 10 months ago | (#45947677)

Wrong, just wrong.

Re:functional (1)

bondsbw (888959) | about 10 months ago | (#45947949)

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:functional (2)

bondsbw (888959) | about 10 months ago | (#45947171)

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 servers that might only return a handful of joined records out of millions or billions? And what if that data rarely changes, but you need to know almost immediately? Polling would use too many resources, too much bandwidth, and may never give you the results in a timely manner. But if the system is reactive, the change starts at the leaf server and only gets propagated up its part of the server hierarchy to the final listener. And if that record is filtered out somewhere along the way? The remaining part of the server hierarchy (including the end listener) never has to know or worry about it.

Still, reactive programming is a hammer but not everything is a nail. Use it when it helps.

Re:functional (2)

lgw (121541) | about 10 months ago | (#45948367)

Or, one could call it "push based, instead of pull based" if one were eschewing obfuscative nomenclature.

Re:functional (0)

Anonymous Coward | about 10 months ago | (#45947479)

more like just a state machine using a spreadsheet macros or database triggers

Re:functional (0)

Anonymous Coward | about 10 months ago | (#45947827)

Reactive programming is a declarative approach for defining logic. Variables are defined by expressions such as A=B+C, which automatically reacts to changes in B or C.

this is just rebadged functional programming, except using deliberately confusing syntax

And we all know how well this works to make reliable code in spreadsheets...

The great coroundrum (1)

TrollstonButterbeans (2914995) | about 10 months ago | (#45946473)

This article summary ends "And no doubt this discussion may raise other questions on extensibility and performance for Reactive Programming.' Do you agree?""

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 I am staying on-topic discussing how to improve superior ambiguity. And I can argue it is revelvant because "revelvant" is not a word and can have any retroactive intended meaning! So double the value of this post in the marketing department!)

Differs because it isn't a type of programming (0)

Anonymous Coward | about 10 months ago | (#45946477)

This is commonly known as creating a reusable framework and does absolutely nothing to change programming, of which database programming is only a small part anyway.

Another great trolling headline from Slashdot.

Junk science (1)

Anonymous Coward | about 10 months ago | (#45946653)

Articles like this really annoy me. There are so many things wrong, it's hard to decide where to start. He concludes in favour of reactive by comparing java and mysql complete with all white space, comments and declarations, with a few bullet pointed reactive expressions in order to fluff up the numbers as much as possible. He makes no attempt to give a balanced viewpoint and makes conclusions based on false statistics and insignificant results. I've seen many so-called experts write junk like this to promote whatever their shiny new API is over the years. Most of them have ended up in limited edge systems, maintained by developers who would rather be doing anything than dealing with the nightmare.

Reactive might be a good idea, but I'm tired of dealing with people sucked in by junk science like this.

Toy Example (3, Interesting)

reluctantjoiner (2486248) | about 10 months ago | (#45946667)

I'm trying not be as automatically dismissive as others, but this example isn't convincing. If your enterprise can be encapsulated by eleven use cases, any framework will suffice. But even in this toy example, we can some obvious missing things.

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 customer.balance Rx, specified for the place order use case, states that its value is the sum of the unpaid order totals. This expression is automatically reused over all transactions that use the field. So, the balance is increased if an order is added, decreased when it is deleted or paid, increased when you raise the quantity, and so forth. With imperative code, it is easy to overlook one of the use cases introducing âcorner caseâ(TM) design and coding errors. Reactive practically eliminates this class of error.

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:Toy Example (1)

FalleStar (847778) | about 10 months ago | (#45946767)

It also doesn't help that he's clearly trying to exaggerate how complex this simple logic would be in other programming languages. The "500 lines of Java code" is mostly whitespace, curly braces, and comments. When you remove the comments from the code he provides while keeping the generous line-spacing, it's only 275 lines of code.

Re:Toy Example (1)

sjames (1099) | about 10 months ago | (#45947871)

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 example this contrived I have to wonder if the new greatest thing can be justified in a non-contrived example.

This is rules based programming (1)

greg_barton (5551) | about 10 months ago | (#45946691)

See JBoss Drools, JRules, Blaze, etc.

Nothing to see here (1)

rootmon (203439) | about 10 months ago | (#45946729)

This is nothing new. You can wrap up the complexity of the code in a toolkit/framework/library but this is just functional programming driven by events. Nothing to see here. Move along. Don't believe the hype.

what "Reactive Programming" really is (3, Informative)

Gravis Zero (934156) | about 10 months ago | (#45946749)

from what i've read on wikipedia, [wikipedia.org] "Reactive Programming" is really just function as a variable with caching.

example:

c = 5
b = 4
a = b + c
print(a) // outputs 9
c = 6
print(a) // outputs 10

this isnt rocket surgery

Re:what "Reactive Programming" really is (1)

Anonymous Coward | about 10 months ago | (#45947477)

I'm a C# programmer by day, and I don't see the hype either. It's been available in C# for years now, and with no need for events or event handling or triggers or any other temporal foolishness.

In your pseudocode example, c and b are variables, and a is a delegate that takes no parameters and returns an int (or something that int can convert to, barring further detail). Using C# lambdas, the line a = b + c would be written as a = (b, c) => b + c.

But you're right, it's really just a function pointer and some syntactic sugar to make it all stick together. Definitely not rocket surgery.

Re:what "Reactive Programming" really is (4, Funny)

Prien715 (251944) | about 10 months ago | (#45948047)

from what i've read on wikipedia, [wikipedia.org] "Reactive Programming" is really just function as a variable with caching.

example:

c = 5
b = 4
a = b + c
print(a) // outputs 9
c = 6
print(a) // outputs 10

this isnt rocket surgery

c=a + b ...behold the infinite loop is born!

Spreadsheets are lousy programming models (5, Interesting)

putaro (235078) | about 10 months ago | (#45946911)

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:Spreadsheets are lousy programming models (1)

Krishnoid (984597) | about 10 months ago | (#45947063)

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:Spreadsheets are lousy programming models (1)

Entrope (68843) | about 10 months ago | (#45947447)

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 I use a spreadsheet for most of my one-off analyses of small(-ish) data sets.

Re:Spreadsheets are lousy programming models (1)

Lemmeoutada Collecti (588075) | about 10 months ago | (#45947549)

That's pretty much the summary of why I use them, as well as to initially organize sample data sets so I can quickly rearrange and visualize them. But as anyone who has attempted to use Excel to calculate a result on a million plus row spreadsheet knows, automatic calculation quickly becomes an enemy of the state - it slows to a crawl as the data sets grow or the calculations become more complex than just sum/average/etc.

Another post above points out the cause of the issue - one change can kick off a fanning of calculations, and each calculation can kick off another fan out. Loops are also easy to create, so I wonder how RP deals with those.

Re:Spreadsheets are lousy programming models (-1)

Anonymous Coward | about 10 months ago | (#45947861)

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?

Excel is popular because it visually gives the "illusion of understanding." And that is also the reason that non-trivial spreadsheets are almost always incorrect POS.

Re:Spreadsheets are lousy programming models (2)

Capt.Albatross (1301561) | about 10 months ago | (#45947647)

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 spreadsheets, but it seems to raise problems for a multiuser database with concurrent updates.

Re:Spreadsheets are lousy programming models (0)

Anonymous Coward | about 10 months ago | (#45947721)

How about recursion? Or even without recursion, various race conditions or other problems caused by combining expression chains of various lengths or latencies?

Horseshit. (3, Insightful)

pigiron (104729) | about 10 months ago | (#45946985)

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!

Isn't this SQL? (0)

Anonymous Coward | about 10 months ago | (#45947205)

To me, the whole idea is already well addressed within the SQL language. You're either talking about setting up a good definition of business rules for your data (DDL) or creating another way to look at your data (Views).

While there is room for improvement in the way that SQL defines (and especially exposes) the final definition, it's so far down the path to what the authors contemplate that I don't see why taking a different approach makes any sense. Maybe handle this information at the interface between the database and the application(s)?

The example logic provided would be very valuable information for SQL's Query Optimizer to have in planning how to execute statements. At large volumes of customers, it becomes very important to consider the performance impacts of defining and enforcing logic - you always should (to the best of your resources and ability).

During the age of NoSQL: have people forgotten about the benefits of the tool that was 'holding them back'?

Or Logic Programming (Re:Isn't this SQL?) (1)

Capt.Albatross (1301561) | about 10 months ago | (#45947807)

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, while those (relatively few) problems requiring the power of a Turing machine could be handled in a Turing-equivalent host language.

In contrast, the proponents of 'reactive programming' seem to be wandering into the realm of logic programming, which has been around for at least 4 decades (Prolog), without giving any indication that they are aware of its pitfalls.
 

Amazingly stupid and fluff article (1)

enigmatic (122657) | about 10 months ago | (#45947601)

That is one of the least informative articles I have read in a long time.
In fact I feel dumber for having read it.

It picks numbers out of thin air for the "standard programing" model,
then it has some magic pixie dust that represents the result in
reactive programming as a few lines of code.

QML is like this (0)

Anonymous Coward | about 10 months ago | (#45947821)

I've been learning QML (Qt's declarative markup language) and it works this way.

Values for properties of UI elements are expressions that can refer to other elements' properties. When the values of the properties in the other elements change, this element's property's value changes as well.

Under the Bus and Over this Reactive BS.... (0)

Anonymous Coward | about 10 months ago | (#45948137)

It looks like most any comments on that article get pruned pretty quickly. Post a thoughtful critical comment and watch it disappear.

Also, who in their right mind would want to obfuscate all of their business logic across a number of database tables? Sure, maybe it's less code but if it's not something that can be understood by someone other than the original developer, it has little long term value. Developers get thrown under the bus all of the time, I say write your code (and use "clean reading" technologies) as if it were to literally happen and some poor soul needs to try and pick it after.

I'll take 100 lines of readable code over 5 lines of obfuscated bullshit any day.

This is absolute bullshit. (2)

vikingpower (768921) | about 10 months ago | (#45948405)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?