What is the fuss with Reactive Cocoa?(khanlou.com)
khanlou.com
What is the fuss with Reactive Cocoa?
http://khanlou.com/2014/02/reactive-cocoa/
8 comments
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.
This is pretty much exactly what I am talking about:
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
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
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.
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.
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.
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.
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.
Sometimes I feel the same way.
Other times I feel stupid 'not to get it'
I did sit down to make a comparison to their readme. https://github.com/seivan/SHRACComparison
Still not getting it.
I did sit down to make a comparison to their readme. https://github.com/seivan/SHRACComparison
Still not getting it.
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.
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.
"You showed two Reactive examples. One was written with Reactive Cocoa, and one was written with the normal Cocoa reactive API."
Exactly. Cocoa already is reactive.
Exactly. Cocoa already is reactive.
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.
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.
Big Nerd Ranch RAC sample is just a nonsense. Non-idiomatic RAC code, using nested callbacks completely defeats the purpose.
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]