Slashdot Mirror

← Back to Stories (view on slashdot.org)

Can Reactive Programming Handle Complexity?

Posted by Soulskill on from the 8,000-nested-if-statements dept.

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

105 of 149 comments (clear)

  1. No by Anonymous Coward · · Score: 1

    I disagree.

  2. Also by oldhack · · Score: 2, Insightful

    Can bullshit walk?

    --
    Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    1. Re:Also by logjon · · Score: 3, Funny

      Don't know about walking, but it can clearly get posted to Slashdot.

      --
      The stories and info posted here are artistic works of fiction and falsehood.
      Only fools would take it as fact.
    2. Re:Also by ChunderDownunder · · Score: 1

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

  3. A few problems... by Ckwop · · Score: 5, Insightful

    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.

    1. Re:A few problems... by Anonymous Coward · · 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 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.

    2. Re:A few problems... by Gestahl · · 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.

    3. Re:A few problems... by LoRdTAW · · Score: 2

      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.

    4. Re:A few problems... by lgw · · 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.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    5. Re:A few problems... by Qzukk · · Score: 5, Funny

      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.

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    6. Re:A few problems... by Ziggitz · · Score: 2

      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.

      --
      There is no memory shortage. yes I have heard of XFCE. Go away.
    7. Re:A few problems... by leandrod · · Score: 2

      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.

      --
      Leandro Guimarães Faria Corcete DUTRA
      DA, DBA, SysAdmin, Data Modeller
      GNU Project, Debian GNU/Lin
    8. Re:A few problems... by rjstanford · · Score: 1

      Databases are not good development platforms.

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

      --
      You're special forces then? That's great! I just love your olympics!
    9. Re:A few problems... by ZahrGnosis · · Score: 3, 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.

    10. Re:A few problems... by SQLGuru · · Score: 2

      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.

    11. Re:A few problems... by gargleblast · · Score: 1

      "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 procedures aren't fundamentally wrong.) When a client doesn't say EXECUTE, the server should NOT go off and do a bunch of unrequested stuff and maybe fail to do what it was asked to do.

      Keep it simple: client makes requests, server fulfills requests.

    12. Re:A few problems... by ignavus · · Score: 1

      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.

      No problem if you live in the right part of Wales: http://en.wikipedia.org/wiki/File:Jones.png

      --
      I am anarch of all I survey.
    13. Re:A few problems... by Chrisq · · 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.

      Yes, TFA is a bit like saying "a hammer is better than a screwdriver because it was quicker at getting a nail in"

    14. Re:A few problems... by Chrisq · · Score: 1

      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

    15. Re:A few problems... by rjstanford · · Score: 1

      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 :)

      --
      You're special forces then? That's great! I just love your olympics!
    16. Re:A few problems... by Chrisq · · Score: 1

      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.

    17. Re:A few problems... by julesh · · Score: 1

      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.

  4. Drive-by disagreements by Anonymous Coward · · Score: 1

    You must be British.

    1. Re:Drive-by disagreements by TechyImmigrant · · Score: 2

      No. He's an Anonymous Coward.

      I'm British.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    2. Re:Drive-by disagreements by ChunderDownunder · · Score: 1

      http://en.wikipedia.org/wiki/W...
      America:0
      British:0

      never start a war you can't win.

      Oh and, don't fuck with Canada.

    3. Re:Drive-by disagreements by Anonymous Coward · · Score: 1

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

      (America was also present).

  5. No silver bullet by Rumagent · · Score: 4, 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".

    1. Re:No silver bullet by jythie · · Score: 2

      Yeah, but there is money to be made in claiming your tool is appropriate far beyond its domain.

    2. Re:No silver bullet by Mister+Liberty · · Score: 1

      Wish I had mod points of the UP kind.

  6. Problem as I see it... by Anonymous Coward · · 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 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.

    1. Re:Problem as I see it... by serviscope_minor · · Score: 2

      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.

      --
      SJW n. One who posts facts.
    2. Re:Problem as I see it... by TechyImmigrant · · Score: 2

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

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    3. Re:Problem as I see it... by Megol · · Score: 1

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

      That depends on a lot. You are assuming ASICs where everything is static however FPGAs can do dynamic changes in some cases. But most standard programming languages doesn't support runtime patching either.

      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.

      Your brush is quite wide here. If one squint enough to see SISAL as a reactive programming model even assembly language looks reactive IMHO.

    4. Re:Problem as I see it... by TechyImmigrant · · Score: 1

      >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. Of course you can implement any programming style in assembly, but you have to build a lot of the infrastructure yourself.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  7. of course it can by istartedi · · Score: 5, Insightful

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

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    1. Re:of course it can by PRMan · · Score: 1

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

      --
      Peter predicted that you would "deliberately forget" creation 2000 years ago...
    2. Re:of course it can by istartedi · · 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.

      --
      For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    3. Re:of course it can by phantomfive · · Score: 4, Informative
      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."

      --
      "First they came for the slanderers and i said nothing."
    4. Re:of course it can by jythie · · Score: 1

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

    5. Re:of course it can by maxwell+demon · · Score: 2

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

      --
      The Tao of math: The numbers you can count are not the real numbers.
    6. Re:of course it can by eulernet · · Score: 1

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

      FTFY.

    7. Re:of course it can by phantomfive · · Score: 1

      Your skills of awesomeness are overwhelming

      --
      "First they came for the slanderers and i said nothing."
  8. Yes by i+kan+reed · · Score: 2

    I concur.

  9. 5 lines and i don't know what they do by shadowrat · · Score: 4, Insightful

    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?

    1. Re:5 lines and i don't know what they do by rjstanford · · Score: 1

      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.

      --
      You're special forces then? That's great! I just love your olympics!
    2. Re:5 lines and i don't know what they do by Hognoxious · · Score: 1

      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.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    3. Re:5 lines and i don't know what they do by Rich0 · · Score: 1

      We've outsourced data cleanup to Bobby Tables. His rates are low, and we haven't had a problem yet...

  10. The usual consulting snake oil by engineerErrant · · 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.

    1. Re:The usual consulting snake oil by engineerErrant · · 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 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.

    2. Re:The usual consulting snake oil by munch117 · · Score: 2

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

    3. Re:The usual consulting snake oil by St.Creed · · Score: 4, 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.

      --
      Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
    4. Re:The usual consulting snake oil by tomhath · · Score: 1

      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.

    5. Re:The usual consulting snake oil by Pino+Grigio · · Score: 1

      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.

    6. Re:The usual consulting snake oil by engineerErrant · · Score: 1

      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.

    7. Re:The usual consulting snake oil by ADRA · · Score: 2

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

      --
      Bye!
    8. Re:The usual consulting snake oil by engineerErrant · · Score: 1

      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.

  11. Re:Proactive by sexconker · · Score: 1

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

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

  12. Looks more like a formula by Anonymous Coward · · 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?"
    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"

    1. Re:Looks more like a formula by rjstanford · · Score: 2

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

      --
      You're special forces then? That's great! I just love your olympics!
    2. Re:Looks more like a formula by julesh · · Score: 1

      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.

  13. however ... by znrt · · 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 ...

  14. Why would I couple my hosting with my framework? by Scotland · · 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!

  15. Marketing Hype... by mrthoughtful · · Score: 3, 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.

    --
    This comment was written with the intention to opt out of advertising.
    1. Re:Marketing Hype... by julesh · · Score: 1

      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.

  16. Ditto by goombah99 · · 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

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:Ditto by Chalnoth · · Score: 1

      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.

    2. Re:Ditto by geminidomino · · Score: 1

      Brian Kernighan's famous quote comes to mind. I wonder what the multiplier becomes for something like this...

    3. Re:Ditto by cduffy · · Score: 1

      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.

      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.

    4. Re:Ditto by goombah99 · · Score: 1

      RIght. but now you are deleting most of the appeal of reactive programming by having to go back to explicitly managing dependencies.

      --
      Some drink at the fountain of knowledge. Others just gargle.
    5. Re:Ditto by cduffy · · Score: 1

      RIght. but now you are deleting most of the appeal of reactive programming by having to go back to explicitly managing dependencies.

      I do? I didn't notice myself explicitly managing dependencies when using Trellis or Hoplon.

    6. Re:Ditto by cduffy · · Score: 1

      even worse then. you must be paying for the automation with speed.

      "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 abstractions aren't doing much that the language's designers haven't already put a lot of effort into making fast.

      Sure, there's performance overhead -- but it's overhead that's built to parallelize well. Whereas traditional locking can deadlock, Clojure ensures that there's always useful work going on somewhere -- the worst case you get into is that other threads' work needs to be thrown away on conflict. That's a model that scales a lot better to the highly parallel hardware of a decade from now than the conventional approaches today.

  17. Labview by goombah99 · · Score: 2

    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.

    --
    Some drink at the fountain of knowledge. Others just gargle.
  18. lazy and memoized by goombah99 · · Score: 2

    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.

    --
    Some drink at the fountain of knowledge. Others just gargle.
  19. Performance nightmare in practice by Mostly+a+lurker · · Score: 1

    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.

  20. I am so sick of slashdot. by Anonymous Coward · · Score: 1

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

  21. cherry picked scenerio by trybywrench · · Score: 1

    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.

    --
    I came to the datacenter drunk with a fake ID, don't you want to be just like me?
  22. Results speak better than hype by ZombieBraintrust · · Score: 1

    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?

  23. Dataflow Book by mattcarkci · · Score: 1

    If you want to learn how to do it yourself I am writing a whole book on the topic, "Dataflow and Reactive Programming Systems" http://dataflowbook.com/

    1. Re:Dataflow Book by jbolden · · Score: 1

      Short comment, nothing to respond to other than yes people should. But nice to have you here when these sorts of topics arise.

  24. Logic Programming? by ionrock · · Score: 1

    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.

    1. Re:Logic Programming? by Ziggitz · · Score: 1

      If a more declarative/rule based model appeals to you, you should check out Drools.

      --
      There is no memory shortage. yes I have heard of XFCE. Go away.
  25. If number of lines of code really counted... by Anonymous Coward · · Score: 1

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

    1. Re:If number of lines of code really counted... by tomhath · · Score: 1

      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!

    2. Re:If number of lines of code really counted... by ccanucs · · Score: 1

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

  26. Re:Proactive by maxwell+demon · · Score: 1

    Th ultimate programming model: Inactive programming. You do nothing, but still get a working program.

    --
    The Tao of math: The numbers you can count are not the real numbers.
  27. Apologies to Douglas Adams by Hognoxious · · Score: 4, 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.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    1. Re:Apologies to Douglas Adams by weilawei · · Score: 1
      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."

    2. Re:Apologies to Douglas Adams by geminidomino · · Score: 1

      No, that's just humor (or humour, considering the source).

  28. Re:Proactive by Hognoxious · · Score: 1

    Prostate programming? You know where you can shove that...

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  29. Non-trivial by Livius · · Score: 2

    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.

  30. Are there good uses? by turp182 · · Score: 1

    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.

    --
    BlameBillCosby.com
    1. Re:Are there good uses? by ChunderDownunder · · Score: 1
      Martin Odersky, Scala inventor, recently held a course on Coursera.

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

  31. Please tell me I'm dreaming! by wdhowellsr · · Score: 1

    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?

  32. 20 GOTO 10 by JayJay.br · · Score: 1

    It is basically the same deal over and over. We need to reduce complexity in programming, so we build yet another abstraction layer. We hide the complexity from the programmer and deal with it in the infrastructure, thus creating more bugs and worse performance. The bugs get (very) slowly fixed and the performance issues are compensated by evolving hardware, which takes a few years. Such is life. If it were not for some initiatives like this one, SAP would be written in machine code.

    That is not to say that this is the solution to all problems, neither that this is even the best alternative for anything, but it's just the way that software evolves, and as such, time will tell.

  33. I hate to be negative but... by sgt+scrub · · Score: 1

    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.

    --
    Having to work for a living is the root of all evil.
  34. Why Run This Crap a 3rd time? by scorp1us · · Score: 1

    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.

    --
    Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
  35. Constraints networks by chthon · · Score: 1

    Aren't these called constraints or propagation networks?

    Structure and Interpretation of Computer Programs and Higher-order Perl have got something to say about these.

  36. Yes. by Paradigma11 · · Score: 1

    Reactive Programming (RP) is just flow based programming (FBP) which has been used successfully for 40+ years. Modern RP adds some nice syntactic sugar that makes it more feasable. I have been using RX https://rx.codeplex.com/ some time ago and am pretty happy with it. It combines very well with f# and functional programming. Always try to isolate small autonomous components and test them seperately with http://blogs.msdn.com/b/rxteam... and http://visualrx.codeplex.com/ . Here is a free book about FBP http://www.jpaulmorrison.com/f... You get comparable easy message based concurrency but you have to take care to stay synchron as much as possible because it can get complex pretty easily.

  37. Reactive is too much active... by lfourrier · · Score: 1

    all /. articles on the subject load, then reload, then reload, then I close the tab.
    So, I have no idea what all this is about.

  38. Re:Proactive by Yakasha · · Score: 1

    Th ultimate programming model: Inactive programming. You do nothing, but still get a working program.

    Already have that.

    Its called "Management".

  39. Betteridge's Law of Headlines by allo · · Score: 1

    finally proven wrong?

    1. Re:Betteridge's Law of Headlines by julesh · · Score: 1

      finally proven wrong?

      I think headlines to which the answer is "of course, duh" are a known class of exceptions.

  40. And Why? by Greyfox · · Score: 1
    I've been watching developers a lot lately. The ones I've been watching will do anything in their power to not have to think about the data they're dealing with. Rather than code an SQL query, they'll harp at their manager that they need a object persistence framework. Rather than deal with hardware, they'll build everything as web services, until even a time query takes several seconds and 14 layers of abstraction. Rather than consider a data structure, they'll stuff everything into a map whether the application fits or not. Rather than take advantage of the speed of local storage, they'll mount everything on NFS. Every time the choice is between applying brute force and ignorance and actually thinking about what they're doing, they'll choose brute force and ignorance.

    So really, what is reactive programming trying to accomplish here? Can I write tight, fast code that is sustainable over the long term, or is it just another stupid fucking thing bad developers insist they need so they can browse the web while the company struggles under the weight of their shoddy software?

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    1. Re:And Why? by jbolden · · Score: 1

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

  41. Unit testing? by CmdrTamale · · Score: 1

    TFA - TL;DR
    Can you write a test suite in the time this tool saved in coding?
    I didn't think so either.