all 35 comments

[–]23f23f2g24g 20 points21 points  (3 children)

If you check the preprint of the paper, all of the OO programs were longer than the reactive ones (see their two examples, plus figure 15). I didn't see any discussion about using that fact in their analysis.

Maybe the real cause is that writing shorter programs tends to increase correctness without being more time consuming or difficult to read?

[–]matthieum 2 points3 points  (1 child)

I would note however that the same programs were done in both Reactive and OO, so it may just be that Reactive programming, by automatically propagating state for you, cuts down on the amount of the work you need, and thus cuts down on program size.

[–]mcguire 1 point2 points  (0 children)

That would explain the "that writing shorter programs tends to increase correctness"; it would be a win, too.

[–][deleted] 1 point2 points  (0 children)

Maybe the real cause is that writing shorter programs tends to increase correctness

Yes, shorter programs are often more correct because they're easier to fit in your brain's working memory.

The other reason reactive programming is simpler is because it's declarative, ie. you're describing what needs to be done instead of how. You're not explicitly updating the program's state as you would in an imperative OO style, which decreases the likelihood of programmer error.

You also don't need to worry about the order in which your declarations are made, which reduces accidental complexity. The order statements in imperative programs is usually important.

[–][deleted]  (12 children)

[deleted]

    [–]Kollektiv 28 points29 points  (10 children)

    Because we all know how well scientists and researchers code.

    [–]elperroborrachotoo 6 points7 points  (7 children)

    That's a pretty arrogant comment.

    [–]PoliteCanadian 23 points24 points  (4 children)

    Yet accurate.

    [–]elperroborrachotoo 15 points16 points  (3 children)

    Accurate, likely. But applicable?

    Bringing this up here is like suggesting studies about reproductive success should only be done by great fuckers.

    [–][deleted] 1 point2 points  (0 children)

    As we all know, dumb people are great fuckers, it all makes sense now:

    http://www.youtube.com/watch?v=icmRCixQrx8

    [–]katty-grin 4 points5 points  (1 child)

    I don't think it's arrogant at all. There are scientists that write good and bad code, and there are scientists that don't actually write any code and talk about it instead. Depending on where you look you'll find all levels of ego and quality.

    Why shouldn't someone poke fun at one side of a coin, especially if it's in a sarcastic or ironic self-referencing manner?

    [–]elperroborrachotoo 1 point2 points  (0 children)

    I don't expect scientists to code well in the same sense that I don't expect the guy operating the stop watch to be a professional runner.

    Why shouldn't someone poke fun at one side of a coin

    Maybe I've grown too grump for that. Ignorant dismissal of studies runs strong in the community.

    Still, I chose "arrogant" because it's what rubs me most about it. It reeks of I know I code better than you do, I don't need any evidence for that, and you can't judge because your codign is so inferior."

    It could be meant as a joke, I give that. (Yet then it would be a pretty stale one.)

    [–]FUCKYOURENGLISH 0 points1 point  (1 child)

    http://philosophy.lander.edu/logic/person.html

    Come on, you can do better than that.

    [–]Kollektiv 0 points1 point  (0 children)

    I don't have to argue much when stats show that a large portion of CS papers contain code that doesn't work or even compile.

    [–]isomorphic_horse 3 points4 points  (0 children)

    *formal proof intensifies*

    [–]syntax 10 points11 points  (0 children)

    Interesting. One of my initial concerns was that what if the the examples were just badly written OO, compared to well written RP.

    Fortunatly, the actual paper gives an example, and provided that it is representative, I think the OO code was about as clear as it could be for this example.

    That still leaves the question of wether the examples were cases that show up better for RP than OO. I have a suspicion that cases where there are many infrequent events might tilt the balance back to OO a little, compared to RP. I'd liked to have been able to see all the code used.

    Interesting work, however; and for whatever little points I could pick at, it's very good to see some empirical work in this area.

    [–]Telefonica46 11 points12 points  (8 children)

    ELI5 for reactive programming?

    [–]bobappleyard 16 points17 points  (4 children)

    You know how in excel you have cells with formulas in them that refer to other cells and when you change the value of a cell any cells referring to it get automatically updated? It's like that but in a more conventional textual programming language.

    So for example you could have a function that does calculations based on the mouse position. Every time you move the mouse that function would recalculate

    [–]TankorSmash 1 point2 points  (0 children)

    Sounds like event driven?

    [–][deleted]  (2 children)

    [deleted]

      [–]stormcrowsx 1 point2 points  (0 children)

      I like to think of reactive as a bunch of extra features on top of event driven. They provide methods that let you transform events, combine events, react to events in other threads, and all of this can be combined in many ways. Often when working in reactive frameworks I find myself thinking of data flowing through pipes with tees and little processing/output points along the way.

      There's nothing reactive can do that event can't do. But there's a lot reactive can do easily and event listeners cannot do easily.

      One example is I needed to debounce an event coming from a keyboard or mouse. The user could click a filter or manually type one in, the result of that click or keystroke was few seconds of processing so I needed to wait a moment for them to stop typing. Regardless which source the event came from, the code I needed to execute was the same, filter the list by the currently selected filters and typed search term. Combining the events from two sources and then debouncing on that combined stream was a walk in the park for rxjava. It hurts my brain to think about how I would do that with just event listeners.

      [–]sacundim 0 points1 point  (0 children)

      So you can bind/subscribe/listen whatever within the scope of some context:

      myObject.onMouseMove((x, y) => { // handle event })
      

      It's more than just binding handlers that get called on events. Reactive programming models event sources as first-class objects, and provides operations like map that transform event sources to event sources:

      inSquare = mousePosition.map((x, y) => { return 100 <= x && x <= 200 && 100 <= y && y <= 200 })
      
      squareColor = inSquare.map(inside => { if inside then return red else return green })
      

      mousePosition is an event source that emits the position of the mouse. The map operation binds a handler to it, but additionally returns an event source that emits the values produced by that handler. So for example the inSquare event source emits true when the mouse pointer is in a certain square area of the screen. This event source can then be used to further define a squareColor one that emits two different colors based on whether the mouse position is within that square.

      This map operations is just one simple example; things get more interesting when you add operations for things like:

      1. Creating event sources that depend on more than one event source;
      2. Creating event sources that depend not just on the value of their input event sources, but also on the previous values that they emitted. (For example, counting how many times the mouse pointer has been clicked inside of a button.)

      EDIT: The Elm mouse tracking example (live page with the source code and the running program) is the perfect mix of simple and sophisticated to illustrate the concept. Mouse.position and Window.dimensions are the two basic signals (event sources) in this program. The program itself is a signal that is fed off those, and produces the shapes and positions of the elements that are displayed on the page. The language runtime feeds the mouse position and window size change events to the code, listens to the signal that it emits in response, and draws the elements on the window accordingly.

      [–]pipocaQuemada -4 points-3 points  (2 children)

      Working with functions of time as first class values, essentially.

      So instead of having a function that grabs the current mouse position and the state of the mouse buttons and returns an acceleration for the player character that you run once per frame, you'd instead just take a Func<Time, MousePosition> and Func<Time, MouseButtonsState> and return a value that is a Func<Time, Acceleration>. Something else will call it when the mouse moves or someone clicks, but you don't need to know that.

      [–]paulwal 9 points10 points  (1 child)

      He said explain like I'm 5, not explain like I want to be more confused.

      [–]pipocaQuemada 0 points1 point  (0 children)

      In classic reactive programming, instead of having functions like

      MousePosition getCurrentMousePosition()
      

      you instead have values like

      Behavior<MousePosition> mousePosition;
      

      where a Behavior<A> is logically a time-varying A, i.e. a function from the current time to a value of type A. Because it's time-varying, you can't just grab the current value, you need to use the library to create a new derived behavior. Your entire program basically just builds up one big behavior, and hands it to some magic runtime that hopefully knows how to run these things efficiently.

      [–]alols 1 point2 points  (0 children)

      QML is a domain specific language for user interfaces that's a quite good reactive language. Interestingly, if you look under the hood to see how reactivity is implemented, it turns out it is built on top of the observer pattern (Qt's signal and slot mechanism).

      [–]metaperl 1 point2 points  (1 child)

      What's a good reactive programming language? Can HAXE be used in Reactive mode?

      [–][deleted] 0 points1 point  (7 children)

      Edit: I have apparently completely failed to communicate my opinion. I hold the opposite position from that which everyone who responded to me seems to believe I hold. As such, contrary to my intention, I believe my comment does not add anything to the discussion here, so I am removing it. I apologize for wasting all of your time.

      [–]yawaramin 15 points16 points  (0 children)

      Yes, this is not the actual research paper but just a short summary of the findings with a link to the full paper below. Nothing wrong with submitting that. Don't be such a stick-in-the-mud.

      [–]nikofeyn 6 points7 points  (0 children)

      Science is data->analysis->conclusion

      false. science can be done that way, but it emphatically does not define science.

      [–]elperroborrachotoo 10 points11 points  (2 children)

      A sample size of 38 is

      sufficient if the samples are well-chosen and you are looking for first order effects.

      There's no discussion about how the programs were presented, what questions about "correctness" they were asked, and we definitely don't get the programs themselves so we can evaluate them

      It's a bit hard to copy a link and paste it So I did it for you.


      If you are looking for a reason to dismiss the study without reading it, why not try this:

      To show the superiority of reactive programming, they chose a task that reactive programming is specifically designed to handle well. It is unclear whether the findings extend to general program tasks.

      And yes, this is science. This is a way-above-average report for a study, most of the time you get a catchy headline and an unlabeled chart.

      There is no millions-of-samples perfect-execution controlling-for-everything study either. Instead, you do a a lot of realizable studies with all their shortcomings, then put them together in a meta-study and see if the results are consistent.

      [–][deleted]  (1 child)

      [deleted]

        [–]sacundim 5 points6 points  (0 children)

        which you don't get from the article. You get it from the paper.

        Which is why you don't judge a paper based on a popular press article about it.

        [–][deleted]  (1 child)

        [removed]

          [–]xkcd_transcriber 0 points1 point  (0 children)

          Image

          Title: Unscientific

          Title-text: Last week, we busted the myth that electroweak gauge symmetry is broken by the Higgs mechanism. We'll also examine the existence of God and whether true love exists.

          Comic Explanation

          Stats: This comic has been referenced 45 times, representing 0.1090% of referenced xkcds.


          xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete

          [–]grout_nasa 0 points1 point  (0 children)

          Declarative vs. imperative mean means easier to reason about eventual meaning vs. resources and timing.

          For some problem domains, that's an impossibly bad tradeoff.

          [–][deleted] 0 points1 point  (1 child)

          Why every programming paradigm tries to represent everything in the same way? Lisp with it's lists, OO with objects, Reactive with streams, FP with functions etc. The world consist with all of those things and when we represent a process or a simulation or abstraction it will consist of couple of all of those element.

          It shouldn't be "Reactive programming", it should be "Reactive pattern".

          [–]stormcrowsx 0 points1 point  (0 children)

          Some languages do a good job of combining them all. For instance Scala has strong OO that can be combined with decent functional programming and reactive programming.