14

I'd like to know how Reactive Programming is tied to Functional-Programming.

Most papers refer "Reactive Programming" as "Functional Reactive Programming".

Does Reactive Programming can be implemented outside Functional Programming?

Is it easier to write Reactive Programs with Functional Language?

edubriguenti
  • 3,488
  • 3
  • 31
  • 43
  • 1
    Your questions is maybe better fitted for this site: http://programmers.stackexchange.com/ – mwhs Nov 08 '13 at 13:26
  • 2
    There's one wikipedia for Reactive programming, and another for Functional Reactive programming. I'd start there. – keyser Nov 08 '13 at 13:27
  • 2
    If you look at the definition of reactive programming you will see that the concept behind it can be achieved with any paradigm that supports the idea of eventing or signaling. This just means that it is highly concurrent. And functional languages do support concurrency very well (by design / lamda calculus). That is all – mwhs Nov 08 '13 at 13:29
  • 1
    also: http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming?rq=1 – ljgw Nov 08 '13 at 13:33
  • 1
    @mwhs how lambda calculus enables good support for concurrency? – om-nom-nom Nov 08 '13 at 13:54
  • 1
    @om-nom-nom lambda calculus is the theoretical foundation of functional languages which, by describing how variables are bound by functions, at the same time offers a paradigm that is open to parallelity without any side effect. This means, that if you look at your programm (which is a function) then every node on the same level can in theory be executed in parallel. This is why you will never find any "thread" or "synchronized" keywords or language constructs in functional programming. It doesn't need it. And the foundation for this is lamda calculus. – mwhs Nov 08 '13 at 14:18
  • @mwhs, you are confusing parallel programming with concurrent programming. Functional languages make parallel programming particularly convenient, but when it comes to concurrent programming they aren't much different—the essential challenges of concurrent programming remain. It will, however, be very clear where parallel calculation is taking place and where concurrent actions are taking place, as these will look completely different. – dfeuer Mar 19 '14 at 05:05

5 Answers5

12

I use what I would call Reactive Programming or SEDA (Staged Event Driven Architecture) but I don't use much in the way of functional programming. http://www.slideshare.net/PeterLawrey/writing-and-testing-high-frequency-trading-engines-in-java

While it is easier to write reactive programs functionally it is not easier to write them to perform faster by using functional programming. Reusing mutable state is often 2-5x faster than creating new immutable objects all the time. So if you are using the reactive programming for performance, I wouldn't use functional programming.

Often developers feel they have to use multiple threads or cores, because they are there. This is like saying you need to use 100% of disk space or you are wasting it.

IMHO you should only add the complexity of multiple threads if it improves performance and it is the simplest way to achieve this improvement. What is often forgotten in the discussion about making concurrency easier is that the easiest solution is to use one thread, and, unless you have proven your solution is faster than that, you haven't convinced me that using multiple threads was ever helpful.

Nathan Hughes
  • 85,411
  • 19
  • 161
  • 250
Peter Lawrey
  • 498,481
  • 72
  • 700
  • 1,075
  • Not using provisioned resources *is* wasting them, in fact. – Randall Schulz Nov 08 '13 at 14:38
  • @RandallSchulz true, but putting in extra effort to use all the resources and being worse off is wasting more. – Peter Lawrey Nov 08 '13 at 14:56
  • @Peter, thanks for your response. I agreed with you that sometimes you just don't need to use parelallel programming. But I'd like to know more about the principles of reactive programming and how it affects the design as we do today in O.O. programming. I'm reading a paper from Odersky that he "deprecated" the observer pattern and he stated how the observer violetes some software engineering principles. So do we need to think about functional programming in order to make reactive applications? – edubriguenti Nov 09 '13 at 13:03
  • Actually yes, you should use multiple threads and cores. That is the hardware we have at our hands now. If this isn't important then lets all fall back to some Intel Pentium or so. – Chiron Nov 12 '13 at 10:41
  • 1
    @Chiron So you would use multiple threads even if that were slower than using one thread, just so you can use all the CPUs? So the priority is to burn all the CPUs, not make programs go faster? – Peter Lawrey Nov 12 '13 at 14:01
  • @EduardoBriguentiVieira IMHO, reactive programming can help improve the performance of functional program. This assumes you have to have functional programming and you just need a bit more speed. If your priority is performance, the fastest option is to use reactive/event driven programming and not use functional at all. – Peter Lawrey Nov 12 '13 at 14:03
  • @Chiron Think of this way. You want to travel from from A to B by road, Sometimes taking one street is the quickest and sometimes taking four streets is the quickest, but you don't say, I could take 10 streets so I need to go up and down every one otherwise what is the point in them being there. The priority should be what is the simplest, quickest or most reliable way to get from A to B. – Peter Lawrey Nov 12 '13 at 14:09
  • @PeterLawrey The original post is about "Reactive Manifesto" which implicitly includes concurrent, distributed and fault tolerant systems. I would be really interested how to achieve this without using Threads (at least in Java). – Chiron Nov 12 '13 at 16:16
  • @Chiron You can have a single threaded socket service which uses non-blocking IO, processes them and sends responses all in the same thread. This is an event driven, reactor with just one thread. – Peter Lawrey Nov 12 '13 at 19:32
4

My guess is you are taking the Reactive Programming course by Odersky/Meijer/Kuhn? Then you will have seen Martin Odersky's interpretation in the first session: He uses a very broad description from a dictionary, whereby reactive means "readily responsive to a stimulus". So it's about a program observing and waiting for some stimulus to which it responds.

So from this perspective reactions are fore most some sort of observation triggered functions. When you can compose them, e.g. you map events or dataflow variables, you would probably call this "functional" in the sense that a set of future values is declared as a function of event originated values.

Functional reactive programming or FRP on the other hand is a term coined by Conal Elliott and Paul Hudak (originally: Functional Reactive Animation, as it was referring to graphical interfaces). It is closely tied to their work and the Haskell programming language.

Many libraries which implement reactive ideas (see the WP article on reactive programming for example) share the event composition aspect with FRP, while they do not necessarily extend to the analytical/continuous signals or "behaviours" of FRP which complement the events.

You will find that some people claim that reactive programming without adhering to the canonical FRP—e.g. when using actors or channels—is "stealing" the term from the "true bearers" of that title. So this discussion can easily become ideological. On the other side of ideological, you will find that reactive is often (ab)used as a new buzz word. The "reactive manifesto" (manifesto… really!? you can even sign that stuff…) would probably be an example of this side.

0__
  • 64,257
  • 16
  • 158
  • 253
  • Good point. I'm reading a paper from Odersky that he "deprecated" the observer pattern and he stated how the observer violetes some software engineering principles. This paper, IMHO, shows that the future is functional programming, because this paradigm addresses most of concerns in reactive programming. Here the link for this paper [link]http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf – edubriguenti Nov 09 '13 at 12:52
  • 1
    Not everything can be nicely composed, so the idea that functional is the only remedy doesn't hold. An example are collection views: A view shows a list of elements, and some related views need to react to elements being added or removed from the underlying model. This is trivial with standard MVC, but how do you define that purely functional? What is the type to be composed, a `Seq[A]`? This can get very inefficient when you really want to know which element was added/removed. Functional is good for expressions, things that evaluate to an individual, but for collections it is less suitable. – 0__ Nov 09 '13 at 13:15
2

To me, this "Reactive Manifesto" is just a buzzword. Erlang is implementing the whole thing since the 80s for free -and silently-.

I would say it is easier to adhere to reactive principles in functional programming since FP is usually embracing immutable states and free side-effects functions. This means it is easier to implement concurrent, distributed and parallel systems.

Good luck implementing a "Reactive" system using shared states, threads, locks, semaphores... And you know, they say only two people can get Java concurrent system right, Doug Lea and Brian Goetz.

Chiron
  • 19,366
  • 15
  • 74
  • 132
0

You may be interested to take a look at the Reactive Manifesto.

I think it's possible to write reactive applications with OO language (by ex. Java as NIO2 and Netty web server) but it is far more appropriate to use a functional language.

Yann Moisan
  • 7,685
  • 6
  • 35
  • 83
  • I sign up. I think the principles and quality attributes that they present as being the keys to reactive programming are valid. My main concern is that to achive this level of resiliance, and paralellism and fault tolerance, the "only" way is through functional programming. – edubriguenti Nov 09 '13 at 15:39
0

No it is not both are independent programming paradigms, reactive being stream based approach and functional based on the philosophy of pure functions for all.

Krishna Ganeriwal
  • 1,555
  • 15
  • 15