Slashdot Mirror


Why Reactive Programming For Databases Is Awesome

Nerval's Lobster writes "'Building on many lessons learned from spreadsheets, functional languages and model-driven application development environments, Reactive Programming (RP) is a recent approach to creating applications,' Val Huber, CTO of Espresso Logic, writes in a new column. 'In the RP paradigm, you can create complex applications from a series of simple declarative statements. Many of the details of implementation and work of gluing together various sorts of application constructs can be hidden because of the declarative approach.' He goes on to argue that RP makes maintenance easier and applications more adaptable, because RP offers automatic dependency management and reuse; at the same time, he also acknowledges that RP has some shortcomings. What say you?"

125 of 165 comments (clear)

  1. I for one would love to see DBs be more like Excel by idioto · · Score: 5, Funny

    I think excel is one of the greatest programs ever and reactive programming sounds great. This article isn't very specific as to how to get started though. Is it a concept, a product or something I have to implement myself?

  2. How does this differ from Drools or Clips? by Anonymous Coward · · Score: 1

    How does this differ from what the rule engines Drools or Clips provide? They are reactive systems that update state by monitoring changes in the underlying data.

  3. Re:But... by K.+S.+Kyosuke · · Score: 1

    Well, yeah, after a fashion, since web servers themselves are reactive entities. ;-)

    --
    Ezekiel 23:20
  4. Sounds like VHDL and similar approaches... by Lisias · · Score: 3, Interesting

    Interesting.

    Code modeled in RP sounds like VHDL, Verilog et all - the languages used to model modern Programmable Logic Arrays, Programmable Gate Arrays and Programmable Logic Devices - aka, hardware.

    No doubt this approach has its merits, but this kind or "programming" has its gotchas - a lot of gotchas.

    I stand aside for now, looking with great interest.

    --
    Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
    1. Re:Sounds like VHDL and similar approaches... by ackthpt · · Score: 1

      I think they should change the "Reactive" to something like "Proactive" as Reactive has such a negative connotation.

      It's late on Friday, lots of plans for the weekend, but need to hit a few stores on the way home and maybe top of the tank ...

      then it hits, "Oh, you're still here we need WHUMP (massive request hits the inbox) kthxbaihavagudwkendlol" ... yuh.

      --

      A feeling of having made the same mistake before: Deja Foobar
    2. Re:Sounds like VHDL and similar approaches... by mlts · · Score: 1

      I'm curious if this could be used with a FPGA card array to help with I/O or transaction processing, assuming the disk I/O isn't the bottleneck.

  5. Spreadsheets? by Animats · · Score: 4, Informative

    Did this guy just reinvent spreadsheets? There's something to be said for this, but having written in Prolog, which works that way, the 'reactive programming' people have to make a better case than the article does.

    On the other hand, one of the big problems in databases is change notification. Microsoft at one point had a research project on this. The concept was that you could make a request to be notified when something of interest changed in the database. This was expressed as an SQL SELECT statement. When some change was made that would affect the output of your pending SELECT, you'd be notified. The problem was to figure out some efficient way to do this with thousands or millions of pending SELECT statements.

    Finance people use notifications like that all the time. Limits on stocks, limits on combinations of stocks, changes in key ratios, that sort of thing. But the systems for that are specialized, a special case of a more general problem. The most general form of the problem is that B wants to know when something has changed at A. Most of the solutions for this have problems. Polling is either inefficient or slow. B relying on A to message them on a change has a failure problem. Both approaches can result in overloading A with checks for events that aren't happening.

    1. Re:Spreadsheets? by Anonymous Coward · · Score: 3, Insightful

      A trigger on INSERT or UPDATE of a watched entity should kick off an INSERT into a message queue, and a trigger on INSERT in the message queue should run a script to send the message where it needs to go. Now you have a self-managing, self-logging, asynchronous system that only uses system resources when needed.

      Don't reinvent the wheel. Do learn your craft and become a master at it.

      This was solved decades ago. Next question, please.

    2. Re:Spreadsheets? by ubergeek65536 · · Score: 1

      A SQL Server CLR trigger, a message bus, a reactive object. I'm off to try it. Thanks for the idea.

    3. Re:Spreadsheets? by MrBigInThePants · · Score: 1, Flamebait

      A great answer with a completely unnecessarily Douchy tone thrown in for free - brought to you by "Misplaced Sense of Self Importance(TM)", arrogance and "Fragile Ego INC.".

      Well done, sir, for keeping alive the IT stereotype...

    4. Re:Spreadsheets? by sribe · · Score: 3, Insightful

      A trigger on INSERT or UPDATE of a watched entity should kick off an INSERT into a message queue, and a trigger on INSERT in the message queue should run a script to send the message where it needs to go. Now you have a self-managing, self-logging, asynchronous system that only uses system resources when needed.

      Yes, exactly. OK, sometimes it can actually be a little tricky to figure out who needs notification and what data they need, but that's application/business logic that just needs to be worked out. (Example: client was not interested in a particular "master" record, and therefore has not received it, but the addition of a particular "detail" record means that client is now interested, so sending the changed record is not enough, the update needs to include the master and all related details. And so on and so forth, for a really rich app with rich workflow, there winds up being a surprising amount of logic required to get the right updates but no more than needed out to each client.)

      This was solved decades ago. Next question, please.

      Well... No, not really, at least not that I know of. The ability for "trigger on INSERT in the message queue should run a script to send the message where it needs to go" has actually *not* been around for decades. For way too long, this had to be a process *polling* the message queue. Triggers were limited to whatever "procedural SQL" flavor your db had, and had no access to file or network resources. Now you can write triggers in many languages, sometimes with full access to the system. Now you can from a SQL trigger send a notice, which a client can listen for via select/kqueue/libevent etc. But that's all much more recent.

    5. Re:Spreadsheets? by VortexCortex · · Score: 1

      Did this guy just reinvent spreadsheets?

      When I saw spreadsheets for the first time I said the same thing:

      Did they just reinvent state machines?

      Von Neumann would be proud.

    6. Re: Spreadsheets? by viperidaenz · · Score: 1

      Publish changes to a topic and have whatever needs notification subscribe to the topic. If they don't need all changes, apply a message filter to the subscriber.

      Aka JMS and other messaging systems. Solved last century.

    7. Re:Spreadsheets? by KingOfBLASH · · Score: 1

      Putting in things like triggers require fore thought as to what could change. This is a process that can take as much time (or even more) as your original task. If you are a clever programmer, you might still miss something. And if you're not a programmer, you may find this an impossible task.

      Things like "reactive programming" make it easier for non-techies to process data. It is a little bit funny that they write it up in this manner (next up, an article about "round transportation" describing how to move things with no friction using circular objects!)

      However, I think it's worth exploring things like this. These days people are tracking and storing vast amounts of data and non-DBAs are trying to find answers. Excel like ease of use makes data more accessible to people, and is going to be something you'll see more of in the future

    8. Re:Spreadsheets? by Horshu · · Score: 1

      They've got a framework extension for .Net that works similarly, not coincidentally named "Reactive Extensions". The typical sample usage is iterating through a collection of mouse events. The enumeration is observable, so the code can be written as a traditional foreach loop, but the iterator will increment a step every time a mouse event occurs. Simple, yet very powerful, like much of .Net's newer asynchronous constructs.

    9. Re:Spreadsheets? by LordWabbit2 · · Score: 2

      Therein lies the problem, your simple trigger will fire ALL THE TIME. When all I want to watch is record A value B. Triggers are expensive, do you really want to weigh your tables down with unnecessary trigger calls? Clearly you are only dealing with a couple hundred transactions a second, but when things get into the thousands, and at peak millions, placing a trigger on a database is sheer stupidity. Triggers which are utilized are due to bad planning, last resort efforts/or because of crap code. Three guesses which one is usually the culprit? No wonder DBA's are annoyed with programmers.

      --
      There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
    10. Re: Spreadsheets? by loufoque · · Score: 1

      It's only fairly recent in MySQL, MariaDB or whatever web people use these days. Real databases already had this decades ago.

    11. Re: Spreadsheets? by sribe · · Score: 1

      It's only fairly recent in MySQL, MariaDB or whatever web people use these days. Real databases already had this decades ago.

      No, they did not. They had triggers. They had neither active notifications, nor any way to write a trigger that accessed the file system or network "decades ago". (I'm talking specifically about the "Big Two" of times past, Oracle and Sybase.)

    12. Re: Spreadsheets? by loufoque · · Score: 1

      PostgreSQL has allowed functions to be written in plenty of programming languages for at least 10 years.
      Also, with Oracle it was possible to use Java in addition to PL/SQL since 2002. I don't know about Sybase but I guess it probably got .NET support around 2003 or so.

    13. Re: Spreadsheets? by Attila+Dimedici · · Score: 1

      PostgreSQL has allowed functions to be written in plenty of programming languages for at least 10 years. Also, with Oracle it was possible to use Java in addition to PL/SQL since 2002. I don't know about Sybase but I guess it probably got .NET support around 2003 or so.

      Perhaps you failed to notice, but 2002 is only just shy of 12 years ago. The word "decades" (note the fact that this is the plural not the singular) implies at least 20 years. So, the poster you replied to was exactly correct, they did not have this "decades ago".

      --
      The truth is that all men having power ought to be mistrusted. James Madison
    14. Re: Spreadsheets? by sribe · · Score: 1

      Perhaps you failed to notice, but 2002 is only just shy of 12 years ago. The word "decades" (note the fact that this is the plural not the singular) implies at least 20 years. So, the poster you replied to was exactly correct, they did not have this "decades ago".

      Yes, and I, the poster he replied to, have been doing this kind of work for 3 decades, so I know good and damned well that the capabilities being discussed were not around 20 years ago ;-)

      But this being /., home to "highly oppositional" personalities, I'm sure that next we'll hear that 1.2 decades is most certainly more than 1 decade, therefore plural. Then we can devolve into arguing about whether the linear scale is correct, or whether we should use a logarithmic one ;-)

    15. Re:Spreadsheets? by Luyseyal · · Score: 1

      In general, it is bad form to peek under the sheets in the database. However, it could be extremely useful to tie a trigger to a primary key + address for these specific cases. The database should also not block on it if there is no DML or DDL going on -- just piping to a message queue or executing an external script or whatever.

      Blue-skying. It's still early, here.

      -l

      --
      Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
  6. New buzzword? by rev0lt · · Score: 2

    From the article description I couldn't figure out a) what is actually reactive programming; b) how will that help me build better applications. Complex applications are already built from a series of simple declarative statements. In fact, we call the most simple declarative statements language available "assembly". We call the machine representation of those very complex applications built with simple declarative statements "binary". On the other hand, Brainfuck also allows you to build complex applications with very simple statements, and I'm not migrating to it anytime soon.
    Not cool, Slashdot, I'm going to have to read TFA!

    1. Re:New buzzword? by rev0lt · · Score: 1

      Ok, I've read the article diagonally (hey its slashdot!), and apparently someone will have a big surprise when arriving to the letter T (triggers) in their SQL manual. And if it is an actual PostgreSQL manual, imagine their surprise when they find out they can actually code said "triggers" using several high-level languages.
      Next week I'm expecting a blog article explaining why it is a bad idea to embed application logic in the database... Then again, this will still be slashdot :P

    2. Re:New buzzword? by ebno-10db · · Score: 2

      Complex applications are already built from a series of simple declarative statements.

      I'm not being pedantic, as I'll be first to say that software buzzwords are not used consistently, but what you call declarative I believe they'd call imperative, as in "do this", whereas declarative is "this is the way it is (or I want it to be)". I don't know Prolog, but I believe that's considered declarative, as opposed to imperative (which describes most languages, C/C++, Java, Python, etc.).

      Haskell, which I do know, is considered at least partly declarative. You declare the relationships between variables, and the compiler figures out how to compute the stuff. For that reason, you can make the declarations in any order. For example:

      x = foo y
      y = bar 3.14

      is legal, but doesn't work the same as in imperative languages. All "variables" are immutable, and hence can only be assigned a value once (essentially initialization). In the above, y is computed first, then x is calculated using that value of y. The order of the declarations doesn't matter.

    3. Re:New buzzword? by sribe · · Score: 2

      Complex applications are already built from a series of simple declarative statements. In fact, we call the most simple declarative statements language available "assembly".

      No we don't. We call assembly, and most every language in common use, "imperative", not "declarative", because, you know, that's what they actually are. Off the top of my head, I can think of exactly 1 declarative language that is in common use: SQL. (Well, OK, I know, it's not terribly precise to call SQL just 1 language...)

    4. Re:New buzzword? by sribe · · Score: 1

      Ok, I've read the article diagonally (hey its slashdot!), and apparently someone will have a big surprise when arriving to the letter T (triggers) in their SQL manual. And if it is an actual PostgreSQL manual, imagine their surprise when they find out they can actually code said "triggers" using several high-level languages.

      You forgot "N" for "notify" ;-)

    5. Re:New buzzword? by rev0lt · · Score: 1

      This is my personal opinion, but the whole "lets fit languages into predefined buzzwords" is f*** bullshit. Every strong typed language has a declarative section with static or partially static values, that define data structure. So before the "do this", you define "where". Moving to your example, x = bar 3.14 and not necessarily y. Out-of-order declaration is allowed because there is no cascading dependency (eg. y value cannot change globally, so it doesn't matter where it is declared). That is syntax sugar (again, my opinion) that adds nothing to the problem. As an example, its a bit like declaring functions external (as references not solvable in compile time) and be surprised when the linker does its job.
      In the end, its all ones and zeros. And AFAIK, processors don't eat up stuff like "this is the way it is", but rather direct, declarative/imperative (is there an actual difference?) statements.

    6. Re:New buzzword? by rev0lt · · Score: 1

      So, what you're saying is that "Memory position X has value Y" is different from "Move Y to memory position X" in programmable logic?

    7. Re:New buzzword? by rev0lt · · Score: 1

      Yes I did :D And that will actually come handy in a current project, tnx for the refresh!

    8. Re: New buzzword? by Great+Big+Bird · · Score: 1

      Essentially yes. One is saying a fact, the other telling it to do something. A good example is quick sort in Haskell vs C. In the former, you say what the sorted list looks like. In the latter you tell it the operations to perform.

    9. Re:New buzzword? by sribe · · Score: 1

      So, what you're saying is that "Memory position X has value Y" is different from "Move Y to memory position X" in programmable logic?

      Honestly, of the top hits in google for "declarative vs imperative programming", wikipedia explains it best.

    10. Re: New buzzword? by rev0lt · · Score: 1

      Again, programmable logic. Do you know the actual difference between one and the other? You could even do "push Y to stack / call X to decide what to do with it". and in both examples you provided, the generated code for programmable logic would be stuff like "memory position X has value Y; compare [X] with [Z]". There is no friggin difference, since most processors dont understand actual complex data structures (eg. a quicksort of a bunch of strings).

    11. Re:New buzzword? by rev0lt · · Score: 1

      The point is that *every* imperative or functional language has a declarative part. Even SQL. And in the end, every language that is compiled into dynamic programmable logic (as in actual microprocessor instructions) is translated into simple statements, and at that level there is no difference between declarative and imperative - there is usually no practical difference between "assume X is 5" or "move 5 to value of X". If you want to be "scholar" about it, go ahead. In the end, it's all ones and zeros, so I'd guess you'll have a hard time figuring out if they are declarative (as in defining rules and limits) or imperative (performing operations).

    12. Re:New buzzword? by khellendros1984 · · Score: 2

      I've done small amounts of both. Haskell definitely reminded me of Prolog in some ways. I used to think of programming Prolog as building a database of facts and relationships, then executing queries against the database.

      --
      It is pitch black. You are likely to be eaten by a grue.
    13. Re:New buzzword? by sribe · · Score: 1

      Yes I did :D And that will actually come handy in a current project, tnx for the refresh!

      Well then, don't forget kqueue (or libevent)--select is so nasty ;-) Also don't forget pq_consume_input...

    14. Re:New buzzword? by sribe · · Score: 1

      The point is that *every* imperative or functional language has a declarative part. Even SQL.

      SQL is a declarative language, not an imperative one.

      And in the end, every language that is compiled into dynamic programmable logic (as in actual microprocessor instructions)...

      Yes, machine language is imperative. That has nothing whatsoever to do with which higher-level languages are imperative vs declarative.

      ...so I'd guess you'll have a hard time figuring out if they are declarative (as in defining rules and limits) or imperative (performing operations).

      Actually, no, I would have not any difficulty at all figuring that out--it's really quite easy for me to spot whether or not a programming language requires/allows me to specify control flow. Really, please read the wikipedia article before responding, because what you're saying strongly suggests that you don't know what declarative programming is at all.

    15. Re: New buzzword? by DahGhostfacedFiddlah · · Score: 2

      This article's about programming paradigms, not hardware implementation. There's no difference at the processor level between assigning a variable in javascript and assembly, but that doesn't make the languages equal.

    16. Re: New buzzword? by rev0lt · · Score: 1

      True, but the replies aren't against the (non) article - they are about me stating assembly is a declarative language. You add nothing to it.

    17. Re:New buzzword? by rev0lt · · Score: 1

      SQL is a declarative language, not an imperative one.

      Actually, its not. DDL is declarative. DML, while usuallly vendor-dependent, its not necessarily declarative, and most often than not, is imperative. But anyway.

      Yes, machine language is imperative.

      Actually, its not. Machine language is declarative - you DESCRIBE values and operations (scroll up for people talking about VHDL and Verilog similarities) . Assembly is usually considered to be imperative. But, because of that, most languages are imperative at some level - regardless of how you describe shit. That is still the point.

      Actually, no, I would have not any difficulty at all figuring that out--it's really quite easy for me to spot whether or not a programming language requires/allows me to specify control flow.

      HTML allows you to specify control flow for some given browsers - does that make HTML a programming language?
      Grow out of your shell. The world is not black and white.

    18. Re:New buzzword? by rev0lt · · Score: 1

      You're having fun heh? At least I'm learning something :D Thank you. Really

    19. Re:New buzzword? by rev0lt · · Score: 1

      what you're saying strongly suggests that you don't know what declarative programming is at all.

      Or I do and I still call it bullshit. Which one will make you think twice about stuff?

    20. Re:New buzzword? by sribe · · Score: 1

      Or I do and I still call it bullshit. Which one will make you think twice about stuff?

      Wait, call bullshit on what? The original article? Be my guest! Me? No, I actually know the difference pretty damned well.

    21. Re:New buzzword? by sribe · · Score: 1

      Actually, its not. DDL is declarative. DML, while usuallly vendor-dependent, its not necessarily declarative, and most often than not, is imperative. But anyway.

      Wrong. DML is declarative as well.

      Actually, its not. Machine language is declarative - you DESCRIBE values and operations (scroll up for people talking about VHDL and Verilog similarities) .

      Wrong again.

      HTML allows you to specify control flow for some given browsers - does that make HTML a programming language?

      Meh. I wouldn't go that far. The thing is, HTML doesn't really have the other elements of a programming language, in particular you can only branch on that very limited set of conditions, and you don't have any way to store a computed value, much less any way to branch on it.

      Grow out of your shell. The world is not black and white.

      The world, no? Some technical definitions, yes. If the language has no explicit flow control it's declarative. If it has explicit flow control, it's imperative.

    22. Re:New buzzword? by siride · · Score: 1

      I'm not sure how you can argue that "INSERT INTO foo VALUES (bar)" is anything other than a command to do something. The subpieces of DML may be declarative, but then again, to some extent, so are big groups of mathematical operations in C (if they don't have side-effects).

    23. Re:New buzzword? by rev0lt · · Score: 1

      DECLARE foo(last) = VALUES(bar)

    24. Re:New buzzword? by rev0lt · · Score: 1
      From another reply you gave me:

      then again, to some extent, so are big groups of mathematical operations in C (if they don't have side-effects)

      And replying to

      No, I actually know the difference pretty damned well.

      Shure you do, shure you do.

    25. Re:New buzzword? by sribe · · Score: 1

      So, I guess you haven't figured out yet that declarative and imperative are not disjoint, but rather there's a subset relationship. Imperative includes declarative functionality; declarative excludes flow control. Quit being a dumbass and accept the very lucid and completely correct explanation in the wikipedia link I provided oh so long ago!

  7. Re:my database is reacting? by ackthpt · · Score: 1

    Complex applications from simple declarative statements?

    I have a button you can push and it will create an app for you.

    George Jetson, have you been playing with the time machine at Spacely Sprockets again?

    --

    A feeling of having made the same mistake before: Deja Foobar
  8. Views? by DogDude · · Score: 1

    I had never heard of Reactive Programming before, but after reading the article, it seems that Reactive Programming is the same thing as using views, which have been a part of mature RDBMS's for several decades now. Am I missing something obvious?

    --
    I don't respond to AC's.
    1. Re:Views? by beelsebob · · Score: 2

      No, the article is just terrible at explaining what FRP is. The idea of FRP is that you stop simply having the idea of having values, and start having the idea of "time varying values". So instead of having an int, which I change the state of at a bunch of times, I can have a Reactive which represents the value of the int at all possible times. You can then treat these as first class citizens, which you can manipulate, so if you have a Reactive representing the time, you can do things like time + 1, and get a new reactive int representing one second later than the current time.

      These can be combined in much more complex ways to produce much more interesting behaviours than "hey, what will the time be in one second".

      You can see a simple example of this, describing the n-bodies problem here http://noordering.wordpress.com/2009/02/01/simulating-n-bodies-and-functional-programmingre/

    2. Re:Views? by rev0lt · · Score: 1

      Yes. "Views" and "Mature" are not cool buzzwords for CTOs.

    3. Re:Views? by DogDude · · Score: 1

      Right. I understand. You're still describing Views.

      --
      I don't respond to AC's.
    4. Re:Views? by rev0lt · · Score: 1

      Expressing variables as functions is not new - most modern languages allow you to use them to some extent, and many database systems also - specially considering the NoSQL kind. Automata and state machines are also not new (counting decades), and actually I find your link way more interesting and informative than TFA.

    5. Re:Views? by Desler · · Score: 1

      and actually I find your link way more interesting and informative than TFA.

      That's because the article is a fluff piece.

  9. Re:I for one would love to see DBs be more like Ex by rev0lt · · Score: 4, Insightful

    Usually database manuals calls them triggers.

  10. Spreadsheet programming by ilsaloving · · Score: 3, Insightful

    I can see this being useful for problems that are extremely linear and require extreme parallelization on large quantities of data, but that's about it.

    I've done this 'methodology' many times using Excel. I did it because I I needed to give the spreadsheet to other people, and wanted to avoid having Office nag about 'potentially dangerous VBA'.

    It makes it very easy to see *exactly* how your data is flowing, which is a bonus. It also uses a *lot* more ram because you are now maintaining a permanent block of memory for every single operation, for every different piece of data you are coding against. Of course, the second you get a cyclic dependency, the whole thing blows up.

    But this method of 'programming' was a natural and convenient extension based on how Excel (or any spreadsheet) operates. Nothing more.

    Is it just me, or does it seem like everyone now-a-days is trying very hard to come up with new methodologies and paradigms and web 6.5isms, so they can get their 5 minutes in the lime light?

    1. Re:Spreadsheet programming by rk · · Score: 1

      Is it just me, or does it seem like everyone now-a-days is trying very hard to come up with new methodologies and paradigms and web 6.5isms, so they can get their 5 minutes in the lime light?

      Hey! You're violating my business process patent! ;-)

    2. Re:Spreadsheet programming by gtall · · Score: 1

      "Of course, the second you get a cyclic dependency, the whole thing blows up." Yes and no.

      Think of a state machine with one equation:

            s = a s

      You can code that in Haskell because Haskell has lazy evaluation. The equation (actually we'd call this a co-equation) describes an infinite string of 'a's. There is even a set theory to go with it, non-wellfounded set theory. What you cannot execute is

          s = s

      It is "non-productive". Many process algebra expressions are stated with co-equations. They also come with their own proof method, co-induction. It is a theorem of most process algebras that any well-formed series of equations has solution. Stated this way, it becomes a way of axiomitizing non-wellfounded set theory.

    3. Re:Spreadsheet programming by KingOfBLASH · · Score: 1

      Is it just me, or does it seem like everyone now-a-days is trying very hard to come up with new methodologies and paradigms and web 6.5isms, so they can get their 5 minutes in the lime light?

      Hey! You're violating my business process patent! ;-)

      Watch out! Someone might have patented finding people to patent troll via slashdot.

    4. Re:Spreadsheet programming by mutube · · Score: 1

      Is it just me, or does it seem like everyone now-a-days is trying very hard to come up with new methodologies and paradigms and web 6.5isms, so they can get their 5 minutes in the lime light?

      That's nothing. My new product turns the light plaid.

    5. Re:Spreadsheet programming by benjymouse · · Score: 5, Informative

      I can see this being useful for problems that are extremely linear and require extreme parallelization on large quantities of data, but that's about it.

      That's the danger: Relying on your own lack of imagination to support your argument. If you cared to google a little you would realize that there are many other areas where RP could be relevant.

      Erik Meijer who pioneered the RP push at Microsoft and which lead to the Reactive Extensions for C# and JavaScript (on which the current implementations in Java are based) wrote an article with a thoughtful title: "Your mouse is a database". I could as "so is your finger".

      The idea is that a mouse is a series of "rows" with mouse positions and button states. Instead of viewing them as series of *events*, RP views them as streams of objects. That allows you to apply filters, actions, transformations etc.

      Suddenly, the events become *composable*.

      Think of a touch interface. The touch surface fires events. But if you view the events as streams of objects you can define filters and transforms which let only certain "events" through, like a stream which accepts objects starting/resetting at the "touch" but only accepts messages as long as they describe an ever longer diatance in a certain direction until the finger is lifted again. Now you have a composable stream of "flicks". You can define similar streams which will filter/generate circular moves, pinching with 2, 3 or 4 fingers.

      Think of the problem of cache eviction. You can define sweeping/eviction algorithms as (simple) streams.

      Think of asynchronous programming in a web browser. Parred with web sockets (or in .NET the awesome SignalR which uses web sockets but automatically falls back to other channels when web sockets are not available) you can build responsive, asynchronous interfaces where you *declare* what should happen as server messages are received.

      Think of a dealer system where the dealer wants to track certain papers, positions, rates. RP enables you to build a chained, composable filter where alarms are raised (alarms being messages on streams) when a rate changes more than a certain percentage within a given time period.

      I've done this 'methodology' many times using Excel.

      Sure. Haven't we all?

      It also uses a *lot* more ram because you are now maintaining a permanent block of memory for every single operation, for every different piece of data you are coding against.

      Not neccesarily . In .NET, Reactive Extensions are integrated with LINQ. As a supplement to IObservable, Reactive Extensions also define IQbservable (a *queryable* observable). Analogous to LINQ for IQueryable, LINQ applied to a IQbservable is actually capable of combine criterias and transformations "up the chain" all the way to the source. I.e. if the "event" source is capable of filtering/transforming - like a SQL database or a RSS based web feed is - LINQ for Reactive Extensions can apply the filter very early in the chain and avoid uneccesary progression of objects which would be masked later anyway.

      Is it just me, or does it seem like everyone now-a-days is trying very hard to come up with new methodologies and paradigms and web 6.5isms, so they can get their 5 minutes in the lime light?

      It is not just you. There a scores of other people out there who have always done it before 20 years ago.

      Grow up. Sometimes Computer Science does see advanced. Realizations. Erik Meijer did an awesome job with Reactive Programming. He found a *duality* between actively "pulling" objects from sequences and reactively receiving "pushed" objects from a source. Given the mathematical duality he even managed to find places where the LINQ pull model was not complete yet.

      Reactive Programming is not new. Nor was OO when it really took off. OO actually was don back in the 1970ies with Simula (IIRC). But now RP has *matured* as

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    6. Re:Spreadsheet programming by ilsaloving · · Score: 1

      You make your points very well and I found your post to be very informative However, the conclusion of your post is unreasonably harsh, for a variety of reasons.

      Despite having been around for a long time, it has never really caught on. I had never heard of reactive programming until this particular article appeared, and I've been doing software development for a long time. To me that means it is nowhere near as good in practise, as it sounds in theory. Maybe it was too impractical to implement before now, who knows. But the fact remains that it is up to proponents such as yourself to *demonstrate* the value of this new method and how it is superior to current methods. And based on my moderation score, it's clear that I'm not the only one who is dubious about this new method.

      Your accuse me of having a lack of understanding and imagination. I will grant you the former to an extent, but I challenge the latter. I can hand you a clump of mud and say, "You can build a skyscraper with this, if only you had the imagination!". Of course, then you could try building a mud skyscraper only to have it tumble into a pile of mess.

      I am one of those people that becomes intensely skeptical, the instant someone starts to go on about how the latest new technological whatchamabob will make our lives easier, increase productivity, cure world hunger, etc., Simply put, I will not waste my own time and energy imagining the possibilities, when you have not yet demonstrated that this new methodology is even fit for purpose. Perfect example: People were falling over themselves about how fantastic Ruby on Rails was. Twitter even wrote their entire backend with it.... Only to have to rewrite their entire backend in Java, because it turned out RoR had very poor scalability.

      And now here you are, describing this wonderful new implementation of reactive programming by Microsoft. A proprietary implementation by a company whose name is a synonym for 'ulterior motives'. While this has nothing to do with the technical merits of reactive programming, it goes a long way to getting people interested enough to look at it. I simply don't trust anything that comes out of Microsoft. From stealing work from supposed 'partners', to subverting industry standards bodies, they have a long and well documented history of screwing over *everybody* to get what they want. Even if reactive programming is as good as you say, I absolutely will not trust Microsoft's implementation of it.

      But thank you for the brief intro into reactive programming. It does sound interesting, and I will have to do additional research on it to find out more.

  11. New? by mwvdlee · · Score: 2

    I remember experimenting with a C++ framework that would work somewhat similar. Lazy evaluation and such. http://sourceforge.net/projects/ditto, it's long since been abandoned because, well... the only thing this way of programming solves is a small part of the "R" in "CRUD". It worked brilliantly for showing information on screen and automatically updating all kinds of stuff whenever some data changed, but in the end it only solved the least difficult part of creating an application, and doing so at a relatively high CPU% cost.

    It was also supposed to have lazy/dynamic/late-binding expressions (i.e. lazy_int a = b + c;), but it turns out you only very rarely have any use for that type of expressions. At the time, there were also far superiour C++ frameworks being developed which could do these things as a side effect of supporting more useful programming models.

    This RP thing doesn't really seem to do anything more than that.

    --
    Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  12. Not an app by Todd+Knarr · · Score: 1

    This won't create an application. It just automates calculations that populate form fields. That's the easy part of most applications. The hard parts are the business logic that isn't just figuring out the values for form fields. In addition, you have nasty cascade effects. What happens in this system when the price for an item changes at the same time the customer's changing the number of that item they want to order, the customer's credit limit is being updated and payments are being applied to his 26 orders each of which causes an update to his balance due? You end up with a massive cascade of updates propagating up the chain, with each change causing changes to values that depend on it which in turn cause yet more changes. Multiply that by thousands of customers and it can kill the systems dead. Meanwhile a non-RP system will handle it cleanly and without dying by simply not updating values until everything's finalized. So as the accounts payable system applies payments to his 26 invoices his balance doesn't change, then when payments are done it updates the balance once to reflect the payments.

    I'd use RP to help with things like forms where I want live updates and RP will help automate what I need done anyway. Lots of other areas... not so much. It'd be just another tool in the toolbox, and it's not quite as useful in the real world as it appears in simple academic examples.

    Part of it's that the people describing these things often haven't dealt with truly large, complex applications before. Simple example: we have 5 fields in a request, each data file has a match value for each of those fields, and we want to grab the file that matches any one of the fields in the current request. "The" file? Um, what happens when I have 3 files each of which matches a different field of the request? Which one should be grabbed? Nobody thought of that. They say "It doesn't matter, just grab one.". And then later "We wanted file 17 that matched field 3 being X, why aren't we getting that file?", answer "Because file 9 matches when field 1 is A, which it is in your request, and we find file 9 first when checking.". Simple request, just grab an arbitrary file. Translated into the real world, complications pile up that were always there but nobody wanted to talk about because they were... well, complicated.

    1. Re:Not an app by lennier · · Score: 1

      What happens in this system when the price for an item changes at the same time the customer's changing the number of that item they want to order, the customer's credit limit is being updated and payments are being applied to his 26 orders each of which causes an update to his balance due?

      At a first glance, I would imagine a real-world RP transaction processing system would handle that problem much the same way real-world paper based transaction processing systems have handled it for hundreds of years: by grouping field updates into documents, and then talking about updates to and within documents. For example, at the time the customer creates a 'new order' form they would get a frozen local value of the current price for the widget at the time they placed the order and further updates wouldn't propagate until they sent the order. When they pressed 'ok', the fact of a new order would be created; another system would deal with receiving and processing the order, and at that time the quoted price on the order would have to be reconciled with the current price at the time it was received. And so on.

      After all, this is how we currently do things - we have things like 'quotes', 'orders', 'invoices', which are all different documents, exactly because the world is constantly in flux and we have to deal with it; why would using a new programming paradigm change any of the organisational checks and balances we already have?

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
    2. Re:Not an app by Todd+Knarr · · Score: 1

      Except that then you remove the basic principle of RP: that updates are done live. Freeze things like that and you've reduced it to the current model where you just dump values into variables and then run calculations on them to set the values of other variables which then don't change until you go and recalculate them yourself.

    3. Re:Not an app by Todd+Knarr · · Score: 1

      Those above are just form fields by another name. And the game engine, the application, is doing a lot more than just calculating those stats.

      Also, an awful lot of what's being calculated does in fact depend on things like position relative to the mob. How hard a mob's attacks hit, for instance, often depends on how far away the player is. How effective the player's attacks are depends on whether they're in front of the mob, off to one side or behind it. Which means in practice you can't avoid that kind of frame-by-frame recalculation using the RP model. Conventional models avoid it by only updating the base numbers frame-by-frame, then doing the full calculations based on the current situation only when needed. Eg. you update the player's position relative to the mob frame-by-frame, but only calculate how effective his attacks are when he actually attacks (with game clients running at 30+ FPS and player attacks happening once every 1-3 seconds, you avoid 30-90x the calculations).

    4. Re:Not an app by lennier · · Score: 1

      Except that then you remove the basic principle of RP: that updates are done live. Freeze things like that and you've reduced it to the current model where you just dump values into variables and then run calculations on them to set the values of other variables which then don't change until you go and recalculate them yourself.

      Not quite. As I understand it, the big idea of RP is not that everything has to be live, but that everything is capable of being live. If you have pervasive liveness given to you by an underlying framework in a safe and cheap manner, it becomes a lot simpler for the programmer to turn it off in the cases where you want to freeze a value, than to manufacture it out of nowhere in the places where you finally realise you need constant event-driven updates.

      The former could take just one keyword in a reactive-declarative language; the latter (in current imperative languages) takes a whole lot of complicated, unsafe, gymnastics like spawning a new process/thread, passing a callback (which might involve security vulnerabilities since you're exposing a raw memory address), arranging your own concurrent synchronisation primitives, and so on. It's a world of pain and it really shouldn't be up to the programmer to solve this thorny problem, since they'll inevitably get it wrong, and in very nasty ways.

      In the Internet age, it becomes a whole lot easier to see the entire Net - and in fact your own server/desktop - as looking less like a von Neumann computer with one 'processor' doing one thing at a time, than a network of components operating on streams of messages. So the theory is, if you had a programming language which looked more like operations on event streams, you'd have something that could work nicely with a single paradigm at all three levels: at the CPU level, it could let compilers scale your code out nicely across arbitrary numbers of cores; at the desktop level, it could provide really simple, clean descriptions of windows and UIs as time-varying functions over the state of other windows/datasources, making it a lot faster and safer to write and change UIs; and at the Internet level, where the world really does look very much non-von, it could do the same thing for entire networks of processes running on servers. Heck, maybe we could even describe our hardware network toplogies as programs? Wouldn't that be something? Especially if more and more our 'networks' aren't physical patch plugs in ports, but virtual topologies running on VM environments?

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
    5. Re:Not an app by lennier · · Score: 1

      Also, an awful lot of what's being calculated does in fact depend on things like position relative to the mob. How hard a mob's attacks hit, for instance, often depends on how far away the player is. How effective the player's attacks are depends on whether they're in front of the mob, off to one side or behind it. Which means in practice you can't avoid that kind of frame-by-frame recalculation using the RP model. Conventional models avoid it by only updating the base numbers frame-by-frame, then doing the full calculations based on the current situation only when needed. Eg. you update the player's position relative to the mob frame-by-frame, but only calculate how effective his attacks are when he actually attacks (with game clients running at 30+ FPS and player attacks happening once every 1-3 seconds, you avoid 30-90x the calculations).

      Right. So, a back-of-the-envelope sketch on how you might do this in RP:
      * Don't try to have each mob directly checking every other mob's position all the time, since that requires geometric time
      * Instead create 'attack' objects which represent attacks in progress. They're only created when an actor pushes the 'attack' button. You probably already need this, since attacks probably have stats linked to them: animation cycles, cooldowns, maybe coordinates of their own if they're projectiles
      * Have a container of such pending attacks
      * A mob connects to the container and watches for nearby attacks, and only when it discovers that it has a connected attack does it do the damage calculations for that attack
      * If the gamespace gets too big, divide it into sectors and attach the mobs and the attacks to sectors, so each mob only has a very short list of pending attacks to scan, and you could parallelise the gamespace easily

      Granted there's probably lots of thorny issues here, especially to do with how lightweight all the objects need to be, but the point is that you could use the typical OO-style division of concerns in an RP framework to make it so that everything isn't watching everything else all the time; each object only connects to the event streams that interest it, and there could be a whole network of observers and re-re-republishers that minimise the notification traffic. Much like how we do it on the Internet, where packets get sent to a local switch, but only forwarded on if they're of interest elsewhere. And once you've got that, you could probably scale it right out to the MMO level much easier than imperative OO programming.

      The trick is that we need good formal semantics for how all this works. It's nice that we're getting reactive libraries, but I think we need more work at the underlying mathematical layer to make sure that what we're implementing is correct. Something like Kahn process networks is probably the best approximation at this point; what we really want to get away from is the horrible mess that is imperative objects and threads.

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
    6. Re:Not an app by Bay+Area+Programmer · · Score: 1

      I see your concern, but I think it is solvable... First, the original article was about transaction (save) processing, so populating form fields is important but different. You are absolutely right that changes can cascade A LOT, but that can be addressed by pruning the Reactive Expressions - on a per-transaction basis - to just those that apply to the actual changes. So a change to an order date affects no dependents, and it's a simple 1-row update. And, changes can be done efficiently, such as 1 row update for totals (vs. an aggregate query). This enables Reactive to scale to very large applications, since it should be possible to limit the SQLs to no more than would be coded by Imperative code.

  13. Where do I comment? by wjcofkc · · Score: 1

    I don't understand this new slashdot scheme where the link to the story in the summary, leads to another story under the slashdot domain. Slashdot Business Intelligence? It's still slashdot... The summary on slashdot.org proper and the story under Slashdot Business Intelligence both offer a comments section. Am I supposed to double post or what? I'm posting this here out of habit but in the midst of confusion. The road to hell is paved by websites that suffered unrecoverable identity crisis.

    --
    Brought to you by Carl's Junior.
    1. Re:Where do I comment? by Lunix+Nutcase · · Score: 1

      They're trying to increase page hits and ad impressions on the BI sites that next to no one cares about. It's one of those Dice.com side effects.

  14. It is awesome. by ubergeek65536 · · Score: 1

    I started using reactive extensions for .Net for over a year ago and am constantly learning new ways to use it. UI, message busses, async calls, business objects, the list keeps growing. It is by far the most useful programming concept I've learned in the last year. There is one for javascript if you are not into .Net

  15. Why Reactive Programming For Databases Is Stupid by ttucker · · Score: 1

    This article is just marketing bullshit double speak without a concrete implementation.

  16. Is auto-recaluation always a good thing? by JoeyRox · · Score: 1

    I like the idea of having variables auto-recalculate based on a dependency tree built automatically by a tool. But recalculating vars sounds kinda slow, esp when resolving the dependency calculations involves time-consuming operations like database fetches. What control does the tool provide in limiting the timing and scope of the recalcs?

  17. Re:silver bullet by istartedi · · Score: 1

    I hope this silver bullet is better than the last one.

    "I'm not too worried about that" said every vampire on the planet.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  18. I did quite a bit with Openlazlo by rsilvergun · · Score: 1

    which I think fits into this model. It was neat, but kind of a mess. As soon as I wanted to do something the creators of OL didn't think of I ended up writing a lot of JavaScript and stuffing it in weird places.

    I like the HTML/Android approach: Use Declarations for the UI layout and let old fashion code control the logic.

    --
    Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
  19. Re:silver bullet by philip.paradis · · Score: 2

    Vampires do not fear silver bullets. They fear stakes and sunlight. Werewolves fear silver bullets.

    --
    Write failed: Broken pipe
  20. Im still trying to get accustomed by Mister+Liberty · · Score: 2

    to /active/ programming.

    Anyways, seriously, please, please please my fellow programmers. Don't jump
    on this just because it looks or sounds esoteric.

  21. HDL by Omega+Hacker · · Score: 1

    Tl;DR [yet], but initially this sounds a lot like HDL's like Verilog and VHDL. The two fundamental constructs there are things that happen continuously (collections of simple logic gates) and things that happen based on a clock (registers, built around flip-flops). At a high level, this sounds like A = B+C is a continuous adder, and A is changed instantaneously with B and C. In the HDL world, this gets "compiled" down to silicon, but in a software world this would be radically harder to do, because you have to notify anybody listening to A that B and/or C has changed. Yes, it's like a spreadsheet in that sense.

    --
    GStreamer - The only way to stream!
  22. The microfilm by Mister+Liberty · · Score: 2

    is in its usual place.

  23. The programmer still has to think by istartedi · · Score: 2

    OK, B+C can be evaluated once when you assign A, or it can be evaluated every time you evaluate A. Sometimes you know that A will not change after you calculate it, or that a fresh value of A is required, and sometimes you don't.

    Delaying the evaluation of A is usually safe; but it can sometimes be very slow. Like it or not, performance still matters. If you evaluated A unnecessarily inside a tight loop in a game, you'd be dead. Even less CPU intensive thinks like web apps could be killed by this kind of thing, if A is evaluated in JavaScript every time you move your mouse pointer.

    Evaluating A every time is not only slow, it might not even be correct. Let's say you pull in some weather data and then render a map. The frontal zone should be a smooth line. If you pull in new frontal boundary data while rendering the map... you'll render a broken front.

    Sorry. It looks like the programmer still has to think. Re-calculating A every time the symbol A occurs may or may not be required.

    --
    For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
  24. Re:silver bullet by Wintermute__ · · Score: 1

    Vampires do not fear silver bullets. They fear stakes and sunlight. Werewolves fear silver bullets.

    That's why they said, "I'm not too worried about that"

  25. recent? by stenvar · · Score: 1

    Reactive Programming (RP) is a recent approach to creating applications,

    That is "recent" as in "about half a century old"?

    1. Re:recent? by 3dr · · Score: 1

      Exactly. So far RP in the article sounds a lot like data-flow engines (spreadsheets, various visualization tools, DB triggers, even make builds). It has spanned decades and fields, too. Many artificial intelligence systems used this type of reactive engine; for example, the CLIPS engine "reacted" by matching conditions to a subset of currently-asserted facts to trigger actions (which can then cascade by asserting new facts and causing other patterns to match). The common aspect to all these applications of a data-flow engine is that a Result has Dependencies, and those Dependencies may be "atomic" (like a file timestamp in make), or a Result from an earlier conclusion. At any point in time, the entire scenario can be paused, and each pending Result has a list of Dependencies that may or may not be satisfied at that point. Spreadsheet calculation 101.

    2. Re:recent? by lennier · · Score: 1

      Exactly. So far RP in the article sounds a lot like data-flow engines (spreadsheets, various visualization tools, DB triggers, even make builds). It has spanned decades and fields, too.

      Yes. But it's been reinvented differently on an ad-hoc basis with different semantics each time. And each implementation does a slightly different subset of the same idea, and can't communicate natively with the others. Imagine if, say, there were no lambda calculus and everyone writing a programming language had to take a stab at rebuilding from scratch all the underlying mathematical axioms of computation. (Or - to put it in more modern terms - imagine if everyone were using object oriented programming, and there were no... well, there actually aren't any core axioms of OOP that current languages all agree on, and as a result we're in pretty much the same situation - try to get C++, JavaScript and .NET objects all interoperating and see how closely the semantics mesh).

      What would be really nice would be if reactive/dataflow/spreadsheet programming could be recognised for the fundamental paradigm it is, and coded as a basic language feature, so we could get on with using it rather than saying 'oh, that was invented 50 years ago so it's old hat now'. Yes, it was invented a long time ago; so was Lisp. And we're not yet using either.

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
  26. Views, Materialized views? by slimdave · · Score: 1

    The idea of embedding a calculation into the system that is automatically updated by underlying data changes -- is that not just a database view?

    We use this sort of technique quite widely in a Ruby on Rails app I work on -- complex calculations such as for profitability and cash flow are defined as views in Postgres, and referenced by the app as read-only models. Thus we can: Profitability.where(product_id: 27).group(:month).sum(:value)

    Performs monstrously fast, as is extremely flexible. It breaks the whole "for the love of gods don't put business logic in the database" separation of concerns idea, but we have a system to ship right now and we can't wait for RoR performance and flexibility to catch-up that much.

  27. Re:I for one would love to see DBs be more like Ex by VortexCortex · · Score: 2

    Yeah, and in client side systems they're known as call-backs or event driven, etc. etc.

    I don't know about you, but if it's old let's call it new!

  28. Re:silver bullet by khellendros1984 · · Score: 1

    Blade wants a word with you.

    --
    It is pitch black. You are likely to be eaten by a grue.
  29. Arg NOOOOOOO by Press2ToContinue · · Score: 1

    Event-driven programming is HELL, except for interfaces. Every once in a while a DB trigger is justified, but event-driven languages have failed time and time again because... it's impossible to predict what will happen when and avalanche of eventual complexity causes the system to implode under its own weight.

    For a programming language to make the cut, it must be utterly predictable down to the last side-effect.
     

    --
    Sent from my ENIAC
    1. Re:Arg NOOOOOOO by lennier · · Score: 2

      Event-driven programming is HELL

      Isn't that right there a good reason for it being implemented once, correctly, as a core OS/language feature so that the programmer doesn't have to micromanage all the interactions, and instead just say 'this is a dependency on that; event engine, you sort it out'?

      For better or worse, ever since the mouse we've lived in an event-driven world. From what I can see, it's mostly worse, because our software tools haven't adapted to minimise the complexity, so we have the monstrous Byzantine complexity of signals, slots, callbacks, etc. RP - if it were done properly - seems like a good way of encapsulating a lot of this back into the system levels where it belongs.

      I agree that RP has to have rock-solid formal semantics for it to be dependable; that's a job for computer scientists rather than library programmers, so I hope somone in PhD land is looking seriously at this.

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
  30. Basic design patterns being discussed by WinstonWolfIT · · Score: 1

    I'm just seeing an observer pattern with publishers and subscribers. It's been done time and again in probably all the major languages. In the .NET space, using aspect-oriented decoration and an expression store, both of which are declarative, well understood, and promote reuse, this concept is already covered. Regardless of the platform, any implementation is going to be constructed in the context of the domain being addressed, and I believe any one-size-fits-all approach would lead to a confusing mess.

    1. Re:Basic design patterns being discussed by Bay+Area+Programmer · · Score: 1

      Totally agree that 1-size-fits all is a mess. I think a database-focused "Domain Specific Language" can be tuned for performance, since it can (should) know about the database, costs of SQLs, and so forth. As long as it is extensible with an Imperative Language.

  31. Oh Great by sexconker · · Score: 1

    'In the RP paradigm, you can create complex applications from a series of simple declarative statements. Many of the details of implementation and work of gluing together various sorts of application constructs can be hidden because of the declarative approach.'

    Sounds like another wishy-washy piece of shit language designed to be "easy", "fast", and "human readable" that will end up being kludgey, slow, and a pain in the ass.

    1. Re:Oh Great by Bay+Area+Programmer · · Score: 1

      Reactive/Declarative absolutely needs to be complemented by a procedural language such as JavaScript, and integrated so both work together. This is straightforward - just provide for "events" on tables, using a well known language (e.g., JavaScript).

  32. Examples? by GWBasic · · Score: 1

    Are there any examples of real-world reactive databases in production or development?

    1. Re:Examples? by benjymouse · · Score: 1

      Are there any examples of real-world reactive databases in production or development?

      yes: http://technet.microsoft.com/en-us/library/hh750618(v=sql.10).aspx

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    2. Re:Examples? by Bay+Area+Programmer · · Score: 1

      Wang/Pace and Versata used this approach. Several thousand production apps between the 2.

  33. Hiypercard, anyone? by dltaylor · · Score: 1

    'In the RP paradigm, you can create complex applications from a series of simple declarative statements. ..."; or, even , visually:

    http://hypercard.org/

    It's too bad the Newton wasn't just a hypercard engine, preloaded with a couple of removable apps.

  34. Re:silver bullet by mugnyte · · Score: 1

    Everyone knows the last vampire was killed off by a teenage film series.

  35. Re:I for one would love to see DBs be more like Ex by blue+trane · · Score: 5, Informative

    In Coursera's Reactive Programming MOOC, the difference between reactive programming event-handling and traditional event-handling is described in two slides from the introductory lecture:

    http://subbot.org/coursera/reactive/callbacks.png
    http://subbot.org/coursera/reactive/howtodobetter.png

    A traditional Java event-handler is first presented, and the problems enumerated: it relies on a side-effect (the variable "count" in the example), which involves shared mutable state; events and their handlers are not first class. Reactive programming tries to do better so that complex handlers can be composed from primitive ones.

  36. Re:I for one would love to see DBs be more like Ex by LordWabbit2 · · Score: 2, Insightful

    Good god (or in this case bad god)
    Every damn company I have ever worked in has some (albeit smart) idiot who creates a smart excel/access application which does wonderful things.
    Who then distributes it to xyz people
    Then the datasource (ip address) changes and the thing breaks.
    Or the datasource changes (database table changes) and the thing breaks
    Or his hardcoded status codes changes or is expanded and the thing breaks
    Then they call you out of the blue and say, please fix it!
    Access is an evil which should die. Advocates of it are welcome to come debate the matter with me. I need fresh meat.
    Excel is extremely powerful and a handy tool, but as soon as anyone adds a datasource they should come and debate the matter with me.

    --
    There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
  37. Re:But... by davester666 · · Score: 1

    Yes. After the site stops processing once it gets about 20-50 users, you react by displaying a 'failwhale' graphic, firing your development department and hiring new developers that don't code in 'hip new language that just entered alpha last week'.

    --
    Sleep your way to a whiter smile...date a dentist!
  38. Re:I for one would love to see DBs be more like Ex by coolsnowmen · · Score: 1

    The rules engine I've seen (BRMS) utilizes the Rete algoritm (http://en.wikipedia.org/wiki/Rete_algorithm)

  39. Re:at a db level if I want to react to a change I' by lennier · · Score: 1

    actual cascading data modification based on reverse trigger like syntax would seem to have the level of intelligent design choice on par with Intercal's comefrom statement.

    Right, I don't think current DB technology, based as it is on 1970s timesharing mainframes, is up to the task. I suspect to make RP work nicely with distributed updates you would need to abstract out the idea of 'database' a bit; make it more like the Git/Mercurial model, where there's a big tree of data that anyone can hook into and receive updates, but can't affect anyone else directly.

    This is the direction I think the Net will eventually have to evolve; things like Content Centric Networking are a step in this direction, if we added computation on top of that, we'd be getting very close to something much like the original 1970s 'hypertext' concept. Ted Nelson's Xanadu -- confusing, patent-ridden and badly-specified as it was -- I think had a concept of 'applitudes', applications as spreadsheet-like cells that can import data from anywhere and use it to update themselves. Imagine what you could do with a Web of live data like that.

    --
    You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
  40. This is really enticing ! by Taco+Cowboy · · Score: 1

    I remember experimenting with a C++ framework that would work somewhat similar. Lazy evaluation and such. http://sourceforge.net/projects/ditto

    MUCHO KUDOS FOR THE LINK, my man !

    It was also supposed to have lazy/dynamic/late-binding expressions (i.e. lazy_int a = b + c;), but it turns out you only very rarely have any use for that type of expressions. At the time, there were also far superiour C++ frameworks being developed which could do these things as a side effect of supporting more useful programming models.

    This RP thing doesn't really seem to do anything more than that.

    Looks like this weekend I'll be fully occupied

    I need to know more about all this !

    Thanks again, man !!

    --
    Muchas Gracias, Señor Edward Snowden !
  41. A mixture of prolog (1970) and lisp (1958)? by drolli · · Score: 1

    Yeah but if we can put it in the Web 2.0 then its for sure something new.

    1. Re:A mixture of prolog (1970) and lisp (1958)? by Bay+Area+Programmer · · Score: 1

      Yes, the concept is not new, but Web 2.0 is a good angle. The author (Espresso) has made a REST server out of it.

  42. ah.... by Charliemopps · · Score: 1

    In the RP paradigm, you can...

    I'm sorry, but as soon as I read the word "paradigm" I knew you were management and therefor had no idea what you were talking about. I could be wrong, but I can' risk reading any more of the post for fear of running into that word again. I don't want to get contaminated.

    1. Re:ah.... by maxwell+demon · · Score: 2

      I see that you've used that word in your reply, and therefore I have to conclude that you have no idea what you were talking about. ;-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
  43. Re:I for one would love to see DBs be more like Ex by maxwell+demon · · Score: 1

    Also I think the Observer pattern is all about this.

    --
    The Tao of math: The numbers you can count are not the real numbers.
  44. Re:End of the world! by maxwell+demon · · Score: 1

    No magic smoke. Just an infinite loop. Unless they have made precautions to prevent recursive re-evaluation. In that case it's either a simple update or an error. Or if they use lazy evaluation, it's even no action at all (but any subsequent read of A or B may result in any of the previous options).

    --
    The Tao of math: The numbers you can count are not the real numbers.
  45. Re:I for one would love to see DBs be more like Ex by chthon · · Score: 1

    There is a nice book about composing complex systems from more primitive ones: Structure and interpretation of Computer Programs

  46. Re:I for one would love to see DBs be more like Ex by elvis+the+frog · · Score: 1

    shhh. don't mention this. it's a secret weapon. well, it has limitations, but it's very useful under the covers.

  47. Re:I for one would love to see DBs be more like Ex by Hognoxious · · Score: 1

    This article isn't very specific as to how to get started though.

    Just instinct, but I'm guessing you can buy something that does it from Espresso Logic, of which Val Huber is the CTO.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  48. Re:I for one would love to see DBs be more like Ex by blue+trane · · Score: 1

    I guess you're talking about http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%25_sec_3.3.4 "A Simulator for Digital Circuits":

    This system typifies a kind of program called an event-driven simulation, in which actions (``events'') trigger further events that happen at a later time, which in turn trigger more events, and so so [sic].

    I suppose the modern version uses events more for user interaction, and also gets rid of lots of idiotic, stupid parentheses.

  49. Re:I for one would love to see DBs be more like Ex by spectrumlogic · · Score: 1

    Yes...sorry I have no mod points for you Bugs...

  50. Re:"What say you?" by Impy+the+Impiuos+Imp · · Score: 1

    Boy, they really hate grammar Nazis around here, don't they?

    --
    (-1: Post disagrees with my already-settled worldview) is not a valid mod option.
  51. Re:I for one would love to see DBs be more like Ex by jscoder · · Score: 1

    Yes, there are products and libraries that do this for you. It is probably not something you'd want to implement yourself. Espresso Logic has a commercial offering that provides a combination of declarative logic, declarative security, and actions extensible with JavaScript to build complex SQL based REST systems.

  52. Re:But... by val5772 · · Score: 1

    Performance is absolutely a key concern. But in the same way a database query optimizer can (usually!) select an access plan, it should be possible to do the same for reactive update logic. At the systems level, reactive servers can be stateless rest servers that cluster. Within the rest server, a transaction can be analyzed to determine what *actually* changed, and prune the dependency graph and save (you are right - tons of) SQLs.

  53. Re:I for one would love to see DBs be more like Ex by Bay+Area+Programmer · · Score: 1

    It is a product. A service actually, so you can fiddle without download or install, at espressologic.com. Earlier generations were Wang Pace and Versata. We'd love to hear your reaction. On the client side, EL is a very close approximation, and Microsoft has done some work: http://msdn.microsoft.com/en-us/data/gg577611.aspx

  54. Apologize by benjymouse · · Score: 1

    I sincerely apologize for the harsh tone. That was uncalled for, and I shot off without reading what I wrote and how it comes across. Again, I apologize.

    Like you I have some "triggers". One of my triggers is blanket dismissal. I think what I perceived as your blanket dismissal was what triggered. You are correct about Ruby-on-Rails. It turned out that it was not up to the job. But at the same time it *did* popularize the "web-MVC" pattern in a way that Java frameworks (e.g. Struts) never achieved.

    When someone praises a new technology as the new "best thing since sliced bread", we should approach it with a healthy portion of skepticism. However, we must also keep our minds open to new advances.

    Reactive Programming is not an alternative to OO or FP. It complements both, and at the same time it promises to make certain aspects much more manageable, like e.g. asynchronous and parallel processing.

    --
    Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    1. Re:Apologize by ilsaloving · · Score: 1

      Thank you. I apologize as well, as my original message was prematurely dismissive. So in that respect I deserved some chastising because I should have spent a little more time researching before I commented.

      That being said, as developers we are being bombarded by so many new things on a regular basis, there simply isn't enough time in the day to get involved with more than a handful. But this definitely looks like it's worth taking a closer look at. Apparently Netflix made a Java version available too.

      Incidentally, have you ever been here? http://en.wikipedia.org/wiki/List_of_programming_languages

      That's my goto page to show people how inundated we are.

  55. Reactive Programming : OOP Style by D-Duff · · Score: 1
    A few years ago, I was curious to know how reactive programming would work on object oriented programming so I wrote an open source tool that tries it out using Java to define the reaction rules:

    http://deduced.sourceforge.net/

    I liked the amount of functionality I could get in just a few lines of code. Even the user interface was generated by reactive rules.

    The thing that puzzled me the most with this tool is the lukewarm reaction of most developers who looked at it even when I proved that it could do things in about 10 times less code than a typical OOP solution.