I've been meaning to write something along those lines, thanks for stepping up!
Virtually all the examples I've seen on the various sites/tutorials etc. seem to be more complicated, sometimes significantly, than their straightforward imperative counterparts.
In addition, FRP is required to bring reactiveness to the stateless world of pure functional programming. OO, on the other hand, already is reactive. It's sort of the definition of an object, it reacts to messages. So I am not quite sure what FRP is bringing to the OO world, and again none of the explanations appear to make sense, because they tend to just lift the FP explanations, which aren't applicable.
I can see the appeal of just setting up certain relationships and then having the system maintain them, but we've had constraints since forever to handle that case: Lessons Learned About One-Way, Dataflow Constraints (http://repository.cmu.edu/cgi/viewcontent.cgi?article=1761&c...) [PDF]
It is only more complicated if you have no prior exposure to Functional or Reactive programming. Those of us who cut our teeth on Desktop GUI apps understand Reactive quite well. And combining Reactive with the most modern Functional paradigm is just icing on the cake. It means that building apps around event streams was the right model all those years ago, and that we really can use Functional style to tame those event streams in the same way that we used it to tame imperative looping.
Reactive Cocoa, and functional reactive programming in general, is difficult to get your head around. I've tried several times to see why it's worth it, and each time come a little closer. After 3 attempts, I finally do think it is beneficial, but it's not immediately obvious. Here are a few reasons:
1. It enables you to eliminate state. My view controllers always end up with various handles to objects on them so that I can access things during a complicated processing sequence. These things cause edge case bugs, and are generally not a nice thing to have lying around in code.
2. The more I write data processing algorithms, the more I think about them in terms of map, reduce, filter and other similar operations. Reactive Cocoa allows those to be used to control the flow of execution even more, and it fits really nicely with how I'm thinking about algorithms.
3. I've tried some development in QML for Ubuntu Touch, a language which is very declarative, and it was wonderful. It's a very different way of working, but I can really imagine that being the norm in 20 years. Reactive Cocoa, allowing for more declarative coding, brings a small element of that to Objective-C, which is nice.
4. Finally, I found it fits really nicely with the MVVM (Model, View, View-Model) architecture, which in turn feels like a nice and clean way of structuring applications, and appears to be really easy to test. I haven't got too far into testing Reactive Cocoa applications yet, but it looks like they should be very easy to test as the boundaries between each component are much better defined, and inherently more testable.
I highly recommend "Functional Reactive Programming on iOS" by Ash Furrow: https://leanpub.com/iosfrp – I'm nearly at the end of it, and it's helped me understand more about Reactive Cocoa and make it seem a bit less 'magic', which was a feeling I got from the readme on the project's GitHub repo.
The two really cool things about it is that it's declarative (you set up some rules in your -viewDidLoad: and you're done) and it's easy to reason about (e.g. how an output will vary based on inputs).
But at the same time it's just crying out for some sort interface-builder-style GUI that lets you wire everything up graphically.
My biggest gripe (beautifully illustrated by OP's post) is how un-Apple-like it is at a code level. If you're familiar with standard Cocoa patterns the second code block is quite a bit more understandable.
Finally, in defense of ReactiveCocoa, that code is probably a bit like writing "99 bottles of beer" recursively: it's useful because it's a (relatively) understandable example, not because it's a good use of that programming style. If you start having multiple interdependent network requests, then something like ReactiveCocoa probably starts to come into its own.
Interestingly, it is on OS/X that people are still working on the GUI builder idea, not just for the interface but to entirely replace (or automatically write) the code for an app. Google for Marten IDE to see what I mean. It's a free download but warning... Prograph is a deep subject and if you are mainly an iOS app developer it may be too much, too soon.
You showed two Reactive examples. One was written with Reactive Cocoa, and one was written with the normal Cocoa reactive API.
Simple examples like this are only the Reactivity 101 of Reactive Cocoa and do not fully showcase the power. Also, part of the power of using Reactive Cocoa on iPhone/iPad apps is that you can build them using the same Functional Reactive Programming style that you would use in Android, .NET, Javascript, Scala and so on. Reactive extensions is an API that is available in all those platforms, and it not only simplifies code overall, but it allows the use of the same powerful architectural style across all of the platforms that a typical company needs to support.
Granted, to each their own, but the one thing I concern myself with is readability and learning curve, especially on projects where there's even the remotest possibility that somebody could be inheriting my code. If I toss in a library like ReactiveCocoa, that's an incredibly steep learning curve that a developer will have to master in addition to any other curve presented by Cocoa Touch / Foundation / Core Data / whatever's already there.
The argument could be made for lots of other Objective-C libraries and frameworks, I suppose, but ReactiveCocoa doesn't seem to offer more in benefits than what it costs to learn it.
[+] [-] mpweiher|12 years ago|reply
Virtually all the examples I've seen on the various sites/tutorials etc. seem to be more complicated, sometimes significantly, than their straightforward imperative counterparts.
In addition, FRP is required to bring reactiveness to the stateless world of pure functional programming. OO, on the other hand, already is reactive. It's sort of the definition of an object, it reacts to messages. So I am not quite sure what FRP is bringing to the OO world, and again none of the explanations appear to make sense, because they tend to just lift the FP explanations, which aren't applicable.
I can see the appeal of just setting up certain relationships and then having the system maintain them, but we've had constraints since forever to handle that case: Lessons Learned About One-Way, Dataflow Constraints (http://repository.cmu.edu/cgi/viewcontent.cgi?article=1761&c...) [PDF]
[+] [-] memracom|12 years ago|reply
[+] [-] danpalmer|12 years ago|reply
1. It enables you to eliminate state. My view controllers always end up with various handles to objects on them so that I can access things during a complicated processing sequence. These things cause edge case bugs, and are generally not a nice thing to have lying around in code.
2. The more I write data processing algorithms, the more I think about them in terms of map, reduce, filter and other similar operations. Reactive Cocoa allows those to be used to control the flow of execution even more, and it fits really nicely with how I'm thinking about algorithms.
3. I've tried some development in QML for Ubuntu Touch, a language which is very declarative, and it was wonderful. It's a very different way of working, but I can really imagine that being the norm in 20 years. Reactive Cocoa, allowing for more declarative coding, brings a small element of that to Objective-C, which is nice.
4. Finally, I found it fits really nicely with the MVVM (Model, View, View-Model) architecture, which in turn feels like a nice and clean way of structuring applications, and appears to be really easy to test. I haven't got too far into testing Reactive Cocoa applications yet, but it looks like they should be very easy to test as the boundaries between each component are much better defined, and inherently more testable.
I highly recommend "Functional Reactive Programming on iOS" by Ash Furrow: https://leanpub.com/iosfrp – I'm nearly at the end of it, and it's helped me understand more about Reactive Cocoa and make it seem a bit less 'magic', which was a feeling I got from the readme on the project's GitHub repo.
Also for some of the reasoning behind FRP, the paper "Out of the Tar Pit" is a good read: http://shaffner.us/cs/papers/tarpit.pdf.
[+] [-] frankus|12 years ago|reply
But at the same time it's just crying out for some sort interface-builder-style GUI that lets you wire everything up graphically.
My biggest gripe (beautifully illustrated by OP's post) is how un-Apple-like it is at a code level. If you're familiar with standard Cocoa patterns the second code block is quite a bit more understandable.
Finally, in defense of ReactiveCocoa, that code is probably a bit like writing "99 bottles of beer" recursively: it's useful because it's a (relatively) understandable example, not because it's a good use of that programming style. If you start having multiple interdependent network requests, then something like ReactiveCocoa probably starts to come into its own.
[+] [-] memracom|12 years ago|reply
[+] [-] seivan|12 years ago|reply
I did sit down to make a comparison to their readme. https://github.com/seivan/SHRACComparison
Still not getting it.
[+] [-] memracom|12 years ago|reply
Simple examples like this are only the Reactivity 101 of Reactive Cocoa and do not fully showcase the power. Also, part of the power of using Reactive Cocoa on iPhone/iPad apps is that you can build them using the same Functional Reactive Programming style that you would use in Android, .NET, Javascript, Scala and so on. Reactive extensions is an API that is available in all those platforms, and it not only simplifies code overall, but it allows the use of the same powerful architectural style across all of the platforms that a typical company needs to support.
[+] [-] mpweiher|12 years ago|reply
Exactly. Cocoa already is reactive.
[+] [-] kreeger|12 years ago|reply
The argument could be made for lots of other Objective-C libraries and frameworks, I suppose, but ReactiveCocoa doesn't seem to offer more in benefits than what it costs to learn it.
[+] [-] dtm3dd|12 years ago|reply
[+] [-] corristo|12 years ago|reply