×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Can Reactive Programming Handle Complexity?

Soulskill posted about a month ago | from the 8,000-nested-if-statements dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

149 comments

No (1)

Anonymous Coward | about a month ago | (#46279159)

I disagree.

Drive-by disagreements (1)

Anonymous Coward | about a month ago | (#46279233)

You must be British.

Re:Drive-by disagreements (2)

TechyImmigrant (175943) | about a month ago | (#46279615)

No. He's an Anonymous Coward.

I'm British.

Re:Drive-by disagreements (0)

Anonymous Coward | about a month ago | (#46279701)

No, he's Sir Basilington Ulysis Rawthorneburton Preston-Wang-Upon-Themes

Re:Drive-by disagreements (0)

Anonymous Coward | about a month ago | (#46279951)

No. He's an Anonymous Coward.

I'm British.

No. He's an AC (American Colonialist); not a British Subject (BS).

Re:Drive-by disagreements (0)

Anonymous Coward | about a month ago | (#46280145)

http://en.wikipedia.org/wiki/American_Revolution
America:1
British:0

Apologies to Douglas Adams (4, Funny)

Hognoxious (631665) | about a month ago | (#46280233)

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:Apologies to Douglas Adams (1)

weilawei (897823) | about a month ago | (#46280503)

That's just revisionism (they tried awfully hard not to let go); the correct parallel is Aesop's The Fox and the Grapes.

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:Drive-by disagreements (1)

Anonymous Coward | about 2 months ago | (#46281757)

http://en.wikipedia.org/wiki/American_Revolution
France:1
Great Britain:0

(America was also present).

Ditto (5, Insightful)

goombah99 (560566) | about a month ago | (#46279709)

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

goombah99 (560566) | about a month ago | (#46279793)

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 well but anyone can be crappy at it and get the job done. It's the only program I've felt comfortable modifying in the middle of an experimental run. It's just really robust in that the errors one makes tend not to be fatal. Maybe it's because visually you can see the logic and know the scope of any side effects. But major application complexity? nope. Get complex interfaces hacked together fast? yes.

Re:Ditto (0)

Anonymous Coward | about a month ago | (#46280483)

One word ... monads.

That other part of the program shouldn't assume the variable is fixed. You should wrap your function in a contination so that you're not relying on the variable directly, or you should be able to tell the function/object that you pull the variable from to update you if it changes.

Re:Ditto (1)

Chalnoth (1334923) | about a month ago | (#46280631)

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.

Are there good uses? (1)

turp182 (1020263) | about a month ago | (#46280881)

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:Are there good uses? (1)

ChunderDownunder (709234) | about 2 months ago | (#46281565)

Martin Odersky, Scala inventor, recently held a course [coursera.org] on Coursera.

From a functional perspective the basic idea is to handle asynch callbacks with a Future monad.

I'm so reactive... (-1)

Anonymous Coward | about a month ago | (#46279161)

I'm first.

Re:I'm so reactive... (0)

Anonymous Coward | about a month ago | (#46279245)

I'm first.

... at sloppy seconds.

Also (2, Insightful)

oldhack (1037484) | about a month ago | (#46279213)

Can bullshit walk?

Proactive (0)

Anonymous Coward | about a month ago | (#46279313)

You are absolutely correct. What is needed is proactive programming.

Re:Proactive (1)

sexconker (1179573) | about a month ago | (#46279449)

You are absolutely correct. What is needed is proactive programming.

Fuck that.
Counteractive Programming, or better yet, Deactive Programming.

Re:Also (1)

ChunderDownunder (709234) | about 2 months ago | (#46281603)

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...

A few problems... (5, Insightful)

Ckwop (707653) | about a month ago | (#46279217)

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.

Re:A few problems... (2, Interesting)

Anonymous Coward | about a month ago | (#46279367)

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 would solve the problem most efficiently. You can either learn what tools are available and use the one that seems like the best fit, or you can master one tool and apply it to everything, both work because in the end you're still translating a vague idea into something that can become distinct instructions for the same computers.

*I think I just started development on the 3rd worst D20 product.

Re:A few problems... (5, Funny)

Qzukk (229616) | about a month ago | (#46279755)

I think I just started development on the 3rd worst D20 product

*rolls a 1*

Your fingers fumble over the keyboard, striking keys almost under their own accord.

UPDATE customer SET lastname='Jones'

*rolls save vs. WHERE clause... 3*

;

With horror you look on as you strike a glancing blow to the enter key.

Re:A few problems... (1)

Gestahl (64158) | about a month ago | (#46279409)

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: A few problems... (0)

Anonymous Coward | about a month ago | (#46279857)

I've never seen it embedded in the database. I've seen it embedded as small snippets among regular OOP/MVC code.

Re:A few problems... (1)

rjstanford (69735) | about a month ago | (#46279877)

Databases are not good development platforms.

Especially since, buzzword-compliance excepted, they are by far the least scalable part of your architecture.

Re:A few problems... (2)

LoRdTAW (99712) | about a month ago | (#46279431)

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:A few problems... (2)

SQLGuru (980662) | about 2 months ago | (#46281889)

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 front-end code. For CRUD actions, having the work be performed in the front end makes the app more responsive.

I'm an application developer who has extensive experience as a database developer (not a DBA). I'm in favor of implementing keys and relationships to ensure that your data remains pure (bad data is one of the biggest reasons that analytics is "hard"). I'm also in favor of triggers and stored procedures if it makes sense in the context of the application. But I'm not opposed to reading a set of data into memory and looping over it when it makes sense as well.

Re:A few problems... (5, Insightful)

lgw (121541) | about a month ago | (#46279475)

- 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:A few problems... (0)

geekoid (135745) | about a month ago | (#46279611)

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

ZahrGnosis (66741) | about a month ago | (#46279931)

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:A few problems... (2)

Ziggitz (2637281) | about a month ago | (#46279775)

It is taking away exactly the key features that languages like Java have that make them ideal for business logic. It takes away the generalist properties and ties each line of code into a database process, removing the separation of logic from implementation. It encapsulates functionality without giving access to it by tying procedural code to relationship statements rather than to actual calls, making it extremely vulnerable to the law of leaky algorithms, making it more difficult to both debug and optimize. There's no way this could actually produce scalable, stable codebase that you could use to provide a large scale solution to any business problem.

Re:A few problems... (2)

leandrod (17766) | about a month ago | (#46279833)

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:A few problems... (0)

Anonymous Coward | about a month ago | (#46280541)

- What about circular reactions? - what about em? do they converge? - then determine when good enough is good enough. Do the diverge? -sounds like a programing of logical error.

- What about atomicity? - Use the maybe monad

Apples and Oranges (0)

Anonymous Coward | about a month ago | (#46279243)

You can program reactively in Java?

reactive programming? (0)

Anonymous Coward | about a month ago | (#46279273)

is that sorta like web 2.0?

Abandon Ship (0)

Anonymous Coward | about a month ago | (#46279275)

active programming
re-active programming
quantum programming
recursive programming
state dependent programming
mindful programming
VR programming
genetic programming
dna programming

yep, the universe is a simulation
It's actively trying to find out how many ways it can screw itself over, and over, and over again.
Jerking off,
Masturbating,
you can't get past the fact that you're a seed of the universe, stuck in itself.

VR Programming (0)

Anonymous Coward | about a month ago | (#46279753)

Actually, I think VR programming would be useful. Imagine this: instead of needing to purchase 2 or 3 monitors to see all the information you need (and still sometimes needing to change what takes up a whole screen), you could wear something like the Oculus Rift, and have as many virtual monitors around you as you need.

No silver bullet (4, Insightful)

Rumagent (86695) | about a month ago | (#46279287)

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

lazy and memoized (2)

goombah99 (560566) | about a month ago | (#46279841)

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... (2, Interesting)

Anonymous Coward | about a month ago | (#46279289)

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 of notifications.

It might be "fewer lines of code" to write, but there's just no way in hell it could be as run-time efficient.

Re:Problem as I see it... (2)

serviscope_minor (664417) | about a month ago | (#46279447)

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 that it does move most of the logic to the FPGA iteslf :)

So, it can scale well and do all the things well, if it has dedicated hardware to run it on. Fortunately, such things exist, are quite common and are showing no sign of dieing out.

Re:Problem as I see it... (2)

TechyImmigrant (175943) | about a month ago | (#46279679)

>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-event passing system.

however ... (1)

znrt (2424692) | about a month ago | (#46279497)

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

istartedi (132515) | about a month ago | (#46279323)

x = new WonderfulObject();
x.Invoke("5000 lines of C that somebody wrote");

Re:of course it can (1)

PRMan (959735) | about a month ago | (#46279349)

But if developers are constantly writing slight variations on the same 500 lines of C, why not encapsulate it?

Re:of course it can (5, Insightful)

istartedi (132515) | about a month ago | (#46279375)

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:of course it can (1)

jythie (914043) | about a month ago | (#46279571)

People often do, it is called a library. What the OP seems to be doing is throwing a scripting language on a library and calling it 'reactive'.

Re:of course it can (4, Informative)

phantomfive (622387) | about a month ago | (#46279389)

Your comment made me laugh, but then I read the article, and that's exactly what the author said. From the article:

"Reactive Programming is very capable of addressing many complex problems, and can address all other scenarios via a transparent integration with procedural languages."

Re:of course it can (2)

maxwell demon (590494) | about a month ago | (#46280215)

That way I also can easily write a very powerful build environment:

#include <stdlib.h>
 
int main()
{
  return system("make");
}

I leave obvious improvements to the reader. ;-)

Re:of course it can (1)

eulernet (1132389) | about a month ago | (#46280427)

x = new WonderfulBusinessObject();
x.Invoke("5000 lines of C that some cheap outsourced programmer wrote");

FTFY.

Re:of course it can (0)

Anonymous Coward | about 2 months ago | (#46281365)

x = new WonderfulObject();
x.Invoke("5000 lines of C that somebody wrote");
}
catch(Exception e)
{
        System.out.print("Oh shit, that somebody just changed their 5000 lines of code with unintended side effects")l;
} // that's all I need to say about this

5 lines and i don't know what they do (4, Insightful)

shadowrat (1069614) | about a month ago | (#46279439)

I don't know what the 500 lines of java code are, but i guess they are grabbing input and cleaning it and opening database connections and whatnot. assuming that he's counting import statements and puts curly brackets on their own lines. sure 500 lines.

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:5 lines and i don't know what they do (1)

rjstanford (69735) | about a month ago | (#46279895)

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:5 lines and i don't know what they do (1)

Hognoxious (631665) | about a month ago | (#46280337)

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.

That's because it's like agile or something.

The usual consulting snake oil (5, Insightful)

engineerErrant (759650) | about a month ago | (#46279443)

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:The usual consulting snake oil (0)

geekoid (135745) | about a month ago | (#46279543)

", 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 a while. Centralizing the business rules can also be bad.

Re:The usual consulting snake oil (3, Insightful)

engineerErrant (759650) | about a month ago | (#46279737)

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 be hooked up to a debugger in any normal sense, making maintenance and troubleshooting that much harder, (3) it's a separate "codebase" and technical competency than the "main" codebase (whether it's in Java, C#, Ruby or whatever), thus creating a competency barrier that must be crossed every time work needs to be done on that code, (4) it's not stored with the main codebase, but as a form of data, raising the issue of out-of-sync deployments with the app servers, and (5) far fewer developers know it well enough for complex uses than typical app-server languages, making staffing difficult.

Finally, I have personally always found large codebases much more manageable when written in a statically typed language (which SQL is obviously not). Not wanting to spark a flame war with Ruby or PHP fans, though, I will caveat my statement that those languages are also much better suited for business logic than SQL's declarative style is.

Re:The usual consulting snake oil (4, Interesting)

St.Creed (853824) | about a month ago | (#46279871)

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:The usual consulting snake oil (2)

ADRA (37398) | about a month ago | (#46280715)

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 systems share much of the same behaviour

I have a customer who's debating 'replacing the crown jewels' with a rules engine, and every time I hear them talk about it, it makes me cringe. This mind you is replacing the implementation of 10's of millions of lines of code and hundreds or even thousands of inter-dependent data elements with multiple workflow stages increasing the complexity factor. The higher ups just don't realize how complicated their system really is and someone was like 'fuck it, its the new buzz word!'.

Re:The usual consulting snake oil (0)

Anonymous Coward | about a month ago | (#46279561)

I don't know if this article is BS or not, but reactive programming isn't new. However, it is getting increased attention in research papers as more and more programming languages and libraries support reactive-style programming.

Re:The usual consulting snake oil (2)

munch117 (214551) | about a month ago | (#46279861)

All the links point to slashdot.org/topic/bi/...
That counts as definite proof that the article is BS.

Re:The usual consulting snake oil (0)

Anonymous Coward | about a month ago | (#46280207)

Agile came out because Extreme Programming sounded unprofessional and a lot of companies were ignoring it. That term came out when Extreme Sports were big. Whoever thought it was a good idea to call Agile Extreme Programming at the outset was a fool. Thankfully someone fixed this and you can now tell brain dead execs that you are "Agile"

Re:The usual consulting snake oil (1)

tomhath (637240) | about a month ago | (#46280267)

Sprinkling database updates around in Java (which for most Java programmers means Hibernate) is almost always a terrible idea. Use the appropriate tool to implement your business logic; often that tool is SQL.

Re:The usual consulting snake oil (1)

engineerErrant (759650) | about a month ago | (#46280705)

Clearly, one-time structural updates during system upgrades are a different ballgame. The pattern described is for ongoing use in deployed production code, and my assertion is limited to that context.

For upgrading Hibernate-based systems (or any other O/R-based system), I'd totally agree that short SQL scripts are in many cases the only reasonably performant solution.

As an aside, I don't really like "classical" O/R (meaning, every field is a column and object relations are explicitly embodied in the DB layer) either because it is so brittle. It lacks any ability to "soft-upgrade" the data because the code is so rigidly tied to the DDL that you're forced to write tons of SQL or other migration scripts for every system upgrade. This, in turn, drags the deployment process into an hours-long affair and sharply discourages frequent upgrades. Despite being no fan of Agile overall, I have found that frequent, granular upgrades are usually better than months-long waterfall cycles, which I feel that classical O/R tends to promote.

Re:The usual consulting snake oil (1)

Pino Grigio (2232472) | about a month ago | (#46280365)

In 15 years as a developer I have never used a trigger and I don't intend to in the next 15 years either. If you need to use triggers, you're either (a) lazy or (b) haven't thought the problem through adequately.

Re:The usual consulting snake oil (1)

engineerErrant (759650) | about a month ago | (#46280783)

Amen to that. Their (remotely reasonable) use is probably limited to maintaining legacy systems from back when people thought the database should rule the application stack, and an "app server" meant Perl scripts in the cgi-bin folder.

Re:The usual consulting snake oil (0)

Anonymous Coward | about 2 months ago | (#46281923)

Rubbish.

Looks more like a formula (3, Insightful)

Anonymous Coward | about a month ago | (#46279491)

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?"
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 ... then you have to recalculate the totalprice every time you look at it.

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:Looks more like a formula (2)

rjstanford (69735) | about a month ago | (#46279915)

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

What about reactive Fuzzy Logic? (0)

Anonymous Coward | about a month ago | (#46279503)

What ever happend to Fuzzy Logic?

Why would I couple my hosting with my framework? (1)

Scotland (3022857) | about a month ago | (#46279565)

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... (3, Informative)

mrthoughtful (466814) | about a month ago | (#46279705)

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.

Performance nightmare in practice (1)

Mostly a lurker (634878) | about a month ago | (#46279863)

A lot of what is in the example reminds me of a 4GL I worked with in the 1980s that had a feature called "computed fields". The idea is extremely nice conceptually, and seems to nest nicely, as well as be easily integrated with other functionality. The main problem is performance. Some pretty smart people worked on the tools, but (with the complexity of real life systems) you tend to end up with the same values being continually recalculated. It turns out that (because of the generality of the functionality, and the inability to predict when values will be updated or queried) it is extremely difficult to suppress these duplicate calculations. A typical application developer will create code that results in values being recalculated thousands of times in a single transaction. The problem is both worse and more intractable than is experienced with computed columns in spreadsheets.

I am so sick of slashdot. (1)

Anonymous Coward | about a month ago | (#46279929)

This is stupid. Posting back to Slashdot BI. I'm really really close to leaving. Thanks for killing slash dot dice.

cherry picked scenerio (1)

trybywrench (584843) | about a month ago | (#46279939)

I'm a fan of reactive programming, it's pretty neat. However, the article cherry picked the scenario that perfectly fits reactive programming. Furthermore, calculating a couple formulas is hardly complex, show me geographically distributed caches kept in sync with a few lines of code and I would be more impressed.

Results speak better than hype (1)

ZombieBraintrust (1685608) | about a month ago | (#46279971)

Show me a dozen enterprise apps written in this style that work well. I don't care about sample methods. There are plenty of developers who have rewritten Excel documents into Java applications with proven benifits. Where are the testimonials for doing the opposite? Is Amazon using this for its shopping cart? Did NASA use it? Are big open source project being made with it?

Logic Programming? (1)

ionrock (516345) | about a month ago | (#46280051)

This seems like a magic version of logic programming. Rather than defining precedural instructions, you provide a set of rule that a logic engine then uses when accepting input. My understanding is this is how Prolog and Datalog work, an example being Cascalog in Clojure where you define a query and the logic engine will infer the necessary joins and such to make it happen.

Generally this model of thinking appeals to me, but in practice it is difficult to get right unless your language has explicit support for it. Functional languages with tools like pattern matching and multimethods are a great example of supporting this kind of workflow.

In some ways I can see the model handling extremely complex problems. With that said, the reactive programming model seems like it misses the advantage by simply reacting to changes in input. As others have mentioned, what happens with circular reactions or highly inefficient operations? A logical programming model allows for an engine of sorts that analyzes the "reactions" in order to find where it can be optimized as well as decide whether it is flawed.

Obviously a logical programming model is not a panacea, and I'm not an expert, but it seems a more genuine attempt at handling the sort of complexity that reactive programming aims to solve.

If number of lines of code really counted... (1)

Anonymous Coward | about a month ago | (#46280081)

We would all be programming in Perl, or better yet, how about APL?

Re:If number of lines of code really counted... (1)

tomhath (637240) | about a month ago | (#46280297)

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!

Re:If number of lines of code really counted... (1)

ccanucs (2529272) | about a month ago | (#46280653)

I prefer one line of Perl over one line of APL any day :-) Having said that - this seems more like it's a solution that Prolog would be better suited to address. I work in all three when needed - choosing the best language (those among others as well) to suit that task. Oh - except Java - I try and avoid that... :-)

Hardware description languages (0)

Anonymous Coward | about a month ago | (#46280129)

Reactive programming as a concept is pervasive in hardware description languages, such as Verilog and VHDL. These languages are largely event based, support concurrent function evaluation, deferred assignment, etc.

This is just tasks in ada (0)

Anonymous Coward | about a month ago | (#46280309)

This seems extremely similar to tasks in ada. The variables are in the sensitivity list.

For unrolling component kits, (0)

Anonymous Coward | about a month ago | (#46280513)

brandish elegantly terse accessors!

Non-trivial (2)

Livius (318358) | about a month ago | (#46280681)

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.

are we finally back to client-server? (0)

Anonymous Coward | about a month ago | (#46280709)

Are we in the great circle of IT change where the business logic is being taken back to the data-level where it was originally before the joys of middleware. Used properly database triggers are the perfect place to enforce business data rules - because you cannot enforce them at a lower level.

Please tell me I'm dreaming! (1)

wdhowellsr (530924) | about 2 months ago | (#46281317)

Please tell me the browser cache is screwing with me. Please tell me that my wife wants to have sex more often ( ok that isn't going to happen, I have a 12 and 15 year old) Do we really have Slashdot.org back?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...