Can Reactive Programming Handle Complexity? 149
Nerval's Lobster writes "A recent article on Reactive Programming, which suggested that five lines of Reactive could solve a problem that required 500 lines using Java or 200 lines using triggers, led many readers to question (passionately) whether Reactive enables you to address not just typical problems, but complex ones as well. In a follow-up column, Espresso Logic CTO Val Huber argues that, while it certainly can't solve all use cases, Reactive Programming is very capable of addressing many complex problems, and can address all other scenarios via a transparent integration with procedural languages. He shows how Reactive can handle complexity using two different scenarios: a classically complicated database application (a bill of materials price rollup) and procedural integration (to address external systems such as email and transactions not limited by a database update). Take a look at his work; do you agree?"
No (Score:1)
I disagree.
Drive-by disagreements (Score:1)
You must be British.
Re: (Score:3)
No. He's an Anonymous Coward.
I'm British.
Apologies to Douglas Adams (Score:5, Funny)
The Americans considered themselves the winners because afterwards America became an entirely separate country. The British considered themselves the winners for exactly the same reason.
Re: (Score:2)
One hot summer's day a Fox was strolling through an orchard till he came to a bunch of Grapes just ripening on a vine which had been trained over a lofty branch. "Just the thing to quench my thirst," quoth he. Drawing back a few paces, he took a run and a jump, and just missed the bunch. Turning round again with a One, Two, Three, he jumped up, but with no greater success. Again and again he tried after the tempting morsel, but at last had to give it up, and walked away with his nose in the air, saying: "I am sure they are sour."
Re: (Score:2)
No, that's just humor (or humour, considering the source).
Re: (Score:2)
http://en.wikipedia.org/wiki/W... [wikipedia.org]
America:0
British:0
never start a war you can't win.
Oh and, don't fuck with Canada.
Yes (Score:3)
I concur.
Ditto (Score:5, Insightful)
I've done reactive programs. They make fun little interface gizmhos. But holy shit, try debugging something that does something complex. You can't assure when, where and how variables might be changing in some outer reaches of your program while another part of the program is assuming they are momentarily fixed. It's going to be unpossible to seriously optimize a reactive program.
So yeah for silly data base queries of simple mathematical calcs go for it. Complex programs. run away
Labview (Score:3)
By the way, I thought I'd add, the only reactive style language that I've really found could get modestly complex and still not be incomprehensible is Lab view. It's event driven, and the you can literally see where and how a variable is being modified with the wires it draws (unless you like using globals. The problem with labview is feeding a wire through a lot of graphical levels is so annoying that you end up resorting to globals more than you should.). Labview takes a really different mind set to do
Re: (Score:2)
Yup. I'm sure there are lots of neat shortcuts you can make with reactive programming. But once the complexity grows beyond a certain level, it's going to be hell to debug.
So it's like pretty much everything else software-related: it depends upon the situation. For situations where reactive programming permits a simple implementation, it's pretty great. Otherwise, not so much.
Re: (Score:2)
Brian Kernighan's famous quote comes to mind. I wonder what the multiplier becomes for something like this...
Are there good uses? (Score:2)
Are there specific use cases or patterns where reactive programming may excel, and be integrated into a more traditionally developed system (to minimize reactive complexity through human written code complexity - no way around the complexity...)?
I have no reactive application experience, just wondering if it is possible and if it could be beneficial.
Re: (Score:2)
From a functional perspective the basic idea is to handle asynch callbacks with a Future monad.
Re: (Score:2)
Huh? All the reactive programming frameworks I've used (Python's Trellis, various cell-model approaches in Clojure) have transactional memory, so things never appear to be happening in parallel.
Reactive programming without transactional memory is Doing It Wrong.
Re: (Score:2)
RIght. but now you are deleting most of the appeal of reactive programming by having to go back to explicitly managing dependencies.
Re: (Score:2)
I do? I didn't notice myself explicitly managing dependencies when using Trellis [telecommunity.com] or Hoplon [hoplon.io].
Re: (Score:2)
"Must"?
If you pay attention, you might notice that the languages in question have strong metaprogramming support (and one of them has native immutable data structures with structural-sharing updates and typical log32n performance, and transactional memory baked in deep).
The metaprogramming support means that there's lots of room to do compile-time analysis and optimization, and the native transactional memory support means that the cell abstr
Also (Score:2, Insightful)
Re: (Score:3, Funny)
Re: (Score:2)
Yeah, this is the 2nd or 3rd 'Slashvertisement' publicizing someone's obscure product without adequately explaining what RP actually is.
One would think from reading the tutorials of Val Kilmer (sic) that reactive is just some DSL built on top of PL/SQL...
Re: (Score:2)
You are absolutely correct. What is needed is proactive programming.
Fuck that.
Counteractive Programming, or better yet, Deactive Programming.
Re: (Score:1)
Th ultimate programming model: Inactive programming. You do nothing, but still get a working program.
Re: (Score:2)
Th ultimate programming model: Inactive programming. You do nothing, but still get a working program.
Already have that.
Its called "Management".
Re: (Score:2)
Prostate programming? You know where you can shove that...
A few problems... (Score:5, Insightful)
- What about circular reactions?
- Is SQL really that right language for encoding business logic?
- Triggers are kind of an anti-pattern.
- What about atomicity? What if I need the whole reaction chain to work or none of it.
I'm afraid there more questions than answers with this proposed pattern.
Re: (Score:2, Interesting)
It's the third (at least) Slashvertisement for this useless new ... whatever it is they are trying to sell.
It has potential to get management buy-in because it works exactly the same as Excel. However, it will not get acceptance in the IT departments because it works like Excel but with no explicit statement about the questions you have raised and likely more as well.
There are situations where tables & triggers* are the best way to sort out a problem. There are places where dedicated matrix algebra wo
Re:A few problems... (Score:5, Funny)
*rolls a 1*
Your fingers fumble over the keyboard, striking keys almost under their own accord.
*rolls save vs. WHERE clause... 3*
With horror you look on as you strike a glancing blow to the enter key.
Re: (Score:2)
*rolls a 1*
Your fingers fumble over the keyboard, striking keys almost under their own accord.
*rolls save vs. WHERE clause... 3*
With horror you look on as you strike a glancing blow to the enter key.
No problem if you live in the right part of Wales: http://en.wikipedia.org/wiki/File:Jones.png [wikipedia.org]
Re: (Score:1)
I'm not sure exactly where he wants to use this... as a new constraint system for a database or something?
Yeah, that's the ticket... stuff more business logic in the database. I have yet to see a system designed by DBAs around stored procedures as "the way all systems should integrate" that was remotely usable.
Databases are not good development platforms.
Re: (Score:2)
Databases are not good development platforms.
Especially since, buzzword-compliance excepted, they are by far the least scalable part of your architecture.
Re: (Score:2)
Databases are not good development platforms.
Especially since, buzzword-compliance excepted, they are by far the least scalable part of your architecture.
... unless you're Google perhaps
Re: (Score:2)
Databases are not good development platforms.
Especially since, buzzword-compliance excepted, they are by far the least scalable part of your architecture.
... unless you're Google perhaps
Just because they've figured out how to scale it (for some jobs - anything needing reliable repeatable results tends to get surprisingly slow) doesn't mean it wasn't still a damn sight harder than scaling the rest of the stack :)
Re: (Score:2)
Databases are not good development platforms.
Especially since, buzzword-compliance excepted, they are by far the least scalable part of your architecture.
... unless you're Google perhaps
Just because they've figured out how to scale it (for some jobs - anything needing reliable repeatable results tends to get surprisingly slow) doesn't mean it wasn't still a damn sight harder than scaling the rest of the stack :)
Yes that's probably true, but now they do have a scalable data layer that fits their purpose.
Re: (Score:3)
Is SQL really that right language for encoding business logic?
Probably not. And especially not if you would like your DB to be portable between various DB's.
Re: (Score:3)
Purely bogus argument. The counter is "put it in the database because it allows you to change out the front end". Both are stupid arguments because when you get around to rewriting anything, you're going to rewrite both layers. [Caveat for a company that sells their software -- having all of the code in one layer allows you to sell to more clients.]
Put the code in the right place. For large / massive data processing updates or crunching reports, the database is much more performant than doing it in the
Re:A few problems... (Score:5, Insightful)
- Triggers are kind of an anti-pattern.
Well, sort of the point of this style is to embrace triggers as a powerful and underused tool. I'm a big fan of powerful and underused tools, but generally there's a reason they're underused.
Pick the right tool for the job. Reactive programming seems like it makes life wonderfully easier for this very narrow set of problems. That's neat. But both trying to us it for everything and insisting that it's useless because it doesn't work for everything are mistakes. Like a power screwdriver with a U-joint attachment, some tools go from pointlessly awkward to awesomely helpful when faced with a particularly-shaped niche.
Re: (Score:1)
" Is SQL really that right language for encoding business logic? "
Depends on use. Some business logic could be device independent. SO creating a trigger that can be used by any device makes life a little easier.
"Triggers are kind of an anti-pattern."
No they aren't. For the reason hosted above it's an easy way to handle the same problem with many devices.
Re:A few problems... (Score:4, Insightful)
I don't know about "anti-pattern", but they cause trouble because they cause other code to be non-deterministic and it's very difficult to create patterns around that sort of behavior. They're practically the logical equivalent of the "COME FROM" in Intercal, which was originally a joke for goodness sake. I was flabbergasted when I found out people are vaunting code that actually works this way. It's particularly painful in implementations where the "reactions" can override program flow with errors or silent rejection or just running off and doing whatever they want. It's nearly impossible to debug since reactions (triggers) are almost always coded in a language or paradigm separate from some procedural language used to provide the UI or whatever other layer is being reacted TO.
I just don't like it! But that's just me.
Re: (Score:2)
"Triggers are kind of an anti-pattern."
No they aren't.
Oh yes they are. They weaken the client-server model.
When a client makes a request to a server, the server should try and fulfill exactly that request, to the best of its ability. When a client says INSERT or UPDATE, the server should INSERT or UPDATE if possible. Maybe fail due to constraint violation (or disk full), but that's it. When a client says EXECUTE, the server should execute the named procedure. That's remote execution right there and it's a Good Thing. (Multi-tier might be better, but stored pro
Re: (Score:3)
Re: (Score:3)
Is SQL really that right language for encoding business logic?
Yes, SQL is quite adequate, more so than most due to being declarative. The issue is not SQL per se, but poor support for it in everything but PostgreSQL and IBM DB2. The advantages of procedural languages (including OO and functional ones) are more in standardisation than in the language per se.
Re: (Score:3)
A few problems: - What about circular reactions? - Is SQL really that right language for encoding business logic? - Triggers are kind of an anti-pattern. - What about atomicity? What if I need the whole reaction chain to work or none of it. I'm afraid there more questions than answers with this proposed pattern.
Yes, TFA is a bit like saying "a hammer is better than a screwdriver because it was quicker at getting a nail in"
Re: (Score:2)
A few problems:
- What about circular reactions?
- Is SQL really that right language for encoding business logic?
- Triggers are kind of an anti-pattern.
- What about atomicity? What if I need the whole reaction chain to work or none of it.
I'm afraid there more questions than answers with this proposed pattern.
Yep. It's worth noting that in both of the articles linked the only reason the logic is complex is because their databases aren't correctly normalized. To be specific, their tables are not in 3NF.
No silver bullet (Score:5, Insightful)
It is a tool. Like any other tool you apply it when your skill and experience tells you to. I belive the term commonly associated with this is "professional".
Re: (Score:3)
Re: (Score:1)
lazy and memoized (Score:3)
It is a tool. Like any other tool you apply it when your skill and experience tells you to. I belive the term commonly associated with this is "professional".
My experience is that nearly anytime you see a problem reactive programming could address you would be better off designing a program in which evaluation is lazy, and every calculation is memoized. Spend a little time designing for laziness and memoization and there's no need to lock everything into being based on a reactive language.
Problem as I see it... (Score:2, Interesting)
It appears that reactive programming would require an incredibly bloated and powerful backend. In effect, it moves most of the logic to the framework and allows the programmer to just hook a few pieces together. I can't imagine it scaling well with all the extra event notifications one would introduce. It looks like it would change from one event causing the execution of a chunk of code to multiple chained events triggering a conditional series of smaller chunks of code.
The problem lies in the overhead o
Re: (Score:3)
It appears that reactive programming would require an incredibly bloated and powerful backend. In effect, it moves most of the logic to the framework and allows the programmer to just hook a few pieces together.
In the last thread on this, some slashdotter answered my question and pointed out that VHDL is a reactive language, since x=y means x is connected to y, so y will propagate to x on the next clock pulse and so on throughout the entire circuit.
This fits the model for FPGAs pretty well.
It's fair to say
Re: (Score:3)
>VHDL is a reactive language, since x=y means x is connected to y, so y will propagate to x on the next clock pulse and so on throughout the entire circuit.
And VHDL, as typically used, is completely static. that's because hardware is completely static. You can't just instantiate a new flop in your CPU. They're stuck there where you built them.
In it's various forms, this is known as CSP, Actors, Dataflow Programming, SISAL (Remember that?) and Excel. There are many others. Any producer-consumer message-as
Re: (Score:2)
>You are assuming ASICs where everything is static however FPGAs can do dynamic changes in some cases.
Correct. But the synthesizable subset of VHDL doesn't support that well at all.
>if one squint enough to see SISAL as a reactive programming model even assembly language looks reactive IMHO.
SISAL (single assignment language) was a language targeted at dataflow computers, which are trigger computations by variable updates. Hence it fits that parts of the reactive model, but predates it by a long time. O
however ... (Score:1)
it might be a good way of prototyping and get an early set of working, testable specs. i don't like the approach, though, seems awkward, but that's maybe just me ...
of course it can (Score:5, Insightful)
Re: (Score:2)
Re:of course it can (Score:5, Insightful)
But if developers are constantly writing slight variations on the same 500 lines of C, why not encapsulate it?
Sure, no problem with that. After all I just typed that into a text area in a web browser and hit send. There were probably *millions* of lines of encapsulated code in that one instant. The difference is that I'm not pretending that hitting "Submit" is the same as writing a web browser, a network stack, router firmware, etc. I didn't solve any problems. Those guys did.
Re: (Score:2)
Re:of course it can (Score:5, Informative)
"Reactive Programming is very capable of addressing many complex problems, and can address all other scenarios via a transparent integration with procedural languages."
Re: (Score:2)
That way I also can easily write a very powerful build environment:
I leave obvious improvements to the reader. ;-)
Re: (Score:2)
Re: (Score:2)
x = new WonderfulBusinessObject();
x.Invoke("5000 lines of C that some cheap outsourced programmer wrote");
FTFY.
5 lines and i don't know what they do (Score:5, Insightful)
I don't know much about this Reactive stuff, but i don't see anything in this sample code that tells me where the input is coming from or where it is going to or if it's being cleaned in the process. Somehow Reactive also creates an environment in which nothing unexpected ever gets entered?
Re: (Score:2)
Also, you can just assume that you have a reasonable number of connections to an adequately powerful database running in whichever replica is currently correct.
Most of those lines of Java are actually there for a reason, don't'cha'know.
Re: (Score:2)
That's because it's like agile or something.
Re: (Score:2)
We've outsourced data cleanup to Bobby Tables. His rates are low, and we haven't had a problem yet...
The usual consulting snake oil (Score:5, Insightful)
As background, I am the director of engineering in a small Java/Postgres-based shop. We run a cloud backend for our mobile apps.
This "methodology" reads from the first sentence like an extended infomercial for a consulting shop, or a company trying to create the aura of "thought leadership" to get more investment cash. The formula is simple and time-honored: (1) arbitrarily single out a well-worn software practice to receive a snappy marketing name and be held above all other practices, (2) claim it's new, and (3) offer to implement this bleeding-edge buzzword to clueless executives. For a small fee, of course. It's the same formula that gave us Agile.
In my opinion, what they've described here is a large step *backward.* Not only is this a relatively trivial use of the GoF Observer pattern, but bizarrely, it's done in SQL using triggers, causing immediate database vendor lock-in and creating a maintainability nightmare. It's how software was made back in the 90s when Enterprise SQL database vendors ruled the land. Sprinkling business logic around in the SQL instead of centralizing it in a much more suitable language for logic like Java is a completely terrible idea, unless you're an Oracle sales rep.
This one is safely ignored.
Re: (Score:1)
", it's done in SQL using triggers, causing immediate database vendor lock-in and creating a maintainability nightmare."
Only if you don't know what you are doing. I've create many cross platform triggers.
Properly organized code is the key to maintainability, regardless of language.
"Sprinkling business logic around in the SQL instead of centralizing it in a much more suitable language for logic like Java is a completely terrible idea, unless you're an Oracle sales rep"
you need to step away from the Java for
Re: (Score:3, Insightful)
That's certainly valid that proper organization is far more the key to good code than the use of any language - my comments should not be taken as an ad for Java or any other specific technology.
That said, certain language features lend themselves to good organization much better than others. Where SQL faces challenges is that (1) it's mostly a declarative language using set calculus, which (again, in my opinion) makes it ill-suited for non-trivial business logic, (2) because of the aforementioned, it can't
Re:The usual consulting snake oil (Score:5, Interesting)
Two points here I think:
1) Yes it is possible to build maintainable triggers - I'm doing it right now, as a matter of fact. However, it's certainly not my first choice since it's (a) hard to debug when they cascade and b) performance is hard to keep under control as they proliferate. Just look at Oracle's older products (or heck, look at Apex) and the huge amounts of triggers firing for even the most simple of tasks. It's a weed that you have to control rigourously or it will grow out and suffocate your software. It is NOT a best practice to use triggers if you can avoid them, they're a last resort if all other options are off the table.
2) Centralizing the business rules has a lot of repercussions beyond the technical side of things. Look at BeInformed's products for that. With proper definition of business rules, a good business rule engine can generate most CRUD-code from scratch, dynamically populating the screens with the required fields. BeInformed's latest product even generated the workflow at runtime, all business rule based. It was much more advanced than reactive. Unfortunately they invested too much and they're now up for grabs as they went under. As I understand it, SAP and Microsoft are fighting over the remains. Which is a much better buy than Reactive.
I'm sure you can find an edge case where some platform can't access the centralized business rule repository, or needs an exception. Or it becomes inflexible and unwieldy. Those are generally signs of failing organizational processes, not technical issues.
That said, there's another point: why can't databases integrate with business rule engines? We're still stuck with constraints from the 60's, even Domain-Key constraints have to be programmed instead of declared. Databases could leap forward if they would deal properly with time, versioning, and business rules. Instead, we get slightly higher marks on the TP benchmarks. That's useless.
Re: (Score:3)
Rule Engines are one very tenuous issue. Here are some thoughts on them as I see them:
1. It requires businesses significant overhead to bring in expertise to allow developers / architects / solutions providers for new products, but
2. most products are legacy, so when moving into a business rules eninge model, you need to essentially re-implement everything you've ever done, because
3. Integration with a system of this sort becomes very difficult, and somewhat unmanagable, especially when these outside system
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
That counts as definite proof that the article is BS.
Looks more like a formula (Score:3, Insightful)
Having read TFA, it looks to me like all they have done is compared a schema which was not properly normalised, with something which was; for example the 'reactive' code calculates total cost as quantity x price, where as the author is conjecting that the SQL version would have a total-price field, and therefore have to have '500' lines of code to keep this field updated.
Smells like snake oil to me.
You have to ask, "Why would the SQL schema need a totalprice field?" ... then you have to recalculate the totalprice every time you look at it.
If your business logic says that the totalprice is always Q x price, then ditch the field and ditch all the code which enforces the relationship. But
There are other examples of denormalised data in the sample provided, and in all cases the 'reactive' code simply calculates the value on the fly - and as other commenters have mentioned, this blows up as soon as the business rule is no longer valid, such as "when a product's price is changed, DONT change the price on quoted or shipped orders, DO change the price on scheduled or reoccuring orders"
Re: (Score:3)
And "this customer gets a 3% discount except on orders in the first month of the quarter when its 5% because they're massive and we want to encourage them to book early..."
Re: (Score:2)
Indeed. Their entire product seems to be "we've got this wonderful solution to problems caused by databases that aren't in 3NF: you put your database in 3NF and then calculate the dependent value on the fly" which is of course exactly the same thing we've been doing since 1971 when Codd first described 3NF, but hey, they've got a funky new buzzword for it so it's obviously cool again.
Why would I couple my hosting with my framework? (Score:1)
Sure, it may work exactly as hyped. But that doesn't matter.
Why would I want my hosting coupled to the framework I'm using, and to a particular database as well? If their hosting sucks, or if they raise their rates, I'm stuck.
No thanks!
Marketing Hype... (Score:4, Informative)
This is just marketing hype dressed up as a question. Having said that, anything that gets anyone enthused about programming is good, I guess.
What I really don't like is when Val Huber refers to a previous article he submitted as if it were written by a third party.
Now, I love SQL (and triggers are ok) - and so does Val Huber - I'm sure we would get along fine.
Val, you've been doing SQL for 20 years! woot. So that means you started back 'round '94.
(Aw. I started back in '85. I was doing websites in '94 - remember Lycos?)
But it's just using SQL Triggers, Val - why give it some sort of fancy name? Ohh everyone else does that, like "Web2"? or "The Cloud", etc?
Still stinks - but hopefully someone may actually pick up how to use some of the cool features of SQL.
Re: (Score:2)
Val, you've been doing SQL for 20 years! woot. So that means you started back 'round '94.
And it also means that the correct solution to this problem, third normal form, has been around for over twice as long as he has.
Performance nightmare in practice (Score:2)
I am so sick of slashdot. (Score:1)
This is stupid. Posting back to Slashdot BI. I'm really really close to leaving. Thanks for killing slash dot dice.
cherry picked scenerio (Score:2)
Results speak better than hype (Score:2)
Dataflow Book (Score:1)
Re: (Score:2)
Short comment, nothing to respond to other than yes people should. But nice to have you here when these sorts of topics arise.
Logic Programming? (Score:1)
Generally this model of thinking appeals to me, but in practice it is difficult to get right unless your language has explicit support f
Re: (Score:2)
If number of lines of code really counted... (Score:1)
We would all be programming in Perl, or better yet, how about APL?
Re: (Score:2)
or better yet, how about APL?
One of my favorite exchanges of all time:
Programmer: We wrote our entire application in one line of APL!
Tester: But it doesn't work!
Programmer: That's okay, I know exactly which line of code is broken!
Non-trivial (Score:3)
address not just typical problems, but complex ones as well
If they find that complex problems are not typical, that tells us a lot about the scope of their experience.
Please tell me I'm dreaming! (Score:2)
I hate to be negative but... (Score:2)
If you specify the same memory area in an application for your variables you open up the application for some serious illegitimate usage. It looks to me like using database triggers is pretty much the same thing. However, if someone has sufficient access to your database they could just make their own "triggers". It is a cool concept though.
Why Run This Crap a 3rd time? (Score:2)
This is the 3rd Reactive article in the past year. Whose dick at Slashdot is Val Huber sucking?
Each time it's this PR-ish piece on how his Reactive Progamming model isn't such a bad idea. How the hell does he get these articles to run when so many other good articles get shot down?
STOP IT SLASHDOT. No one wants your Reactive Programming marketing articles.
Constraints networks (Score:2)
Aren't these called constraints or propagation networks?
Structure and Interpretation of Computer Programs [mit.edu] and Higher-order Perl [plover.com] have got something to say about these.
Yes. (Score:2)
Reactive is too much active... (Score:2)
So, I have no idea what all this is about.
Betteridge's Law of Headlines (Score:2)
finally proven wrong?
Re: (Score:2)
finally proven wrong?
I think headlines to which the answer is "of course, duh" are a known class of exceptions.
And Why? (Score:2)
Re: (Score:2)
You sound like you would consider it wasteful. Reactive programming is a paradigm for when views dominate and uses an more sophisticated variant of lazy evaluation to allow for mutable variables that are only fully evaluated when needed, rather than when defined. Lazy is really useful for being able to manipulate indefinite or even infinite data structures without introducing elements of implementation into algorithms. So it makes your code vastly more maintainable but often at the cost of quadratic memor