Is Reactive Programming bounded to Functional programming?
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?
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.
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, eg 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—eg 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.
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.
链接地址: http://www.djcxy.com/p/47724.html上一篇: 在c＃中实现反应式编程/函数
下一篇: 函数式编程是否反应式编程？