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]
Your premise is that "building apps around event streams was the right model". Well, I don't buy that premise. I am open to it as a conclusion, but I don't buy it as a premise.
The examples don't support your premise, because they do not demonstrate that anything got simpler, at least not in any obvious ways. It's not less code, and the code isn't simpler in obvious ways. Saying that I would need prior exposure to F(R)P programming also does not help, it reinforces the point that this is more complicated.
The analogy to "imperative looping" also does not help, Smalltalk has had fancy higher-order loop constructs since the 70ies and is not FP and does not require FRP or "event streams".
Please don't think I am not open to cool things like stream programming, I did my own FilterStreams back in the 90ies. My initial version of Higher Order Messaging also lifted sequential message sends into streams of filters.
I thought this was way cool when I came up with it, but a slightly more mature me realized that it was not nearly as useful as it was cool. To me, the FRP hype seems a lot like that: yes, I can see it's cool that you hook something up over here and then it just keeps going, but the seasoned programmer in me is wary and can't detect the useful as distinct from the cool.
And, just to repeat, I am open to seeing the useful, I just haven't seen it yet.
Finally, we've had constraint programming also since the late 70ies (and spreadsheets as a form of constraint programming is probably the most popular form of programming), and I don't see what FRP brings to the table relative to constraints, at least after you strip it of the FP baggage.
See ThingLab, 1978: http://en.wikipedia.org/wiki/ThingLab
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.
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.
I did sit down to make a comparison to their readme.
Still not getting it.
Exactly. Cocoa already is reactive.
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.