Functional reactive programming was born in the '90s and is all about simple, precise semantics and continuous time. Not exactly what most of us face in our code every day. What we usually mean when discussing FRP is implementing reactive programming concepts and turning code declarative with the help of functional primitives. Wondering what’s the relation between the original idea and today’s plenty implementation inspired by it, like Rx?
After learning, working, and falling in love with reactive programming and declarative style, I have quite some thoughts to share about the ups and downs of building a production app with (F)RP deeply involved. How it makes code clean, more concise, less error-prone, bit difficult to test and really hard to debug.
Steep learning curve has some additional meaning in this case, adjustments might be necessary when adopting, and not just on the code level. Its inherited fundamentals are not trivial to implement in imperative, object oriented environments, like most of the commonly used languages. Especially on a platform with limited resources like mobile, success with (F)RP depends on, and is very sensitive to the existence of various conditions when introducing it to our code. It’s crucial to understand the prerequisites and to measure the possible benefits for the given context in advance, otherwise it's easy to end up with an asynchronous mess of code with performance issues.
Agnes Vasarhelyi (@vasarhelyia) is an iOS developer in love with open source. She likes to build up software from streams of values and automate things in the meantime. Her blog tells you about reactive programming and her tweets about organizing community events.
