
What is the fuss with Reactive Cocoa? - khanlou
http://khanlou.com/2014/02/reactive-cocoa/
======
mpweiher
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...](http://repository.cmu.edu/cgi/viewcontent.cgi?article=1761&context=isr))
[PDF]

~~~
memracom
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.

~~~
mpweiher
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](http://en.wikipedia.org/wiki/ThingLab)

------
danpalmer
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](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](http://shaffner.us/cs/papers/tarpit.pdf).

------
frankus
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.

~~~
memracom
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.

------
seivan
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](https://github.com/seivan/SHRACComparison)

Still not getting it.

------
memracom
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.

~~~
mpweiher
"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.

------
kreeger
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.

------
dtm3dd
[http://blog.maybeapps.com/post/42894317939/input-and-
output](http://blog.maybeapps.com/post/42894317939/input-and-output)

------
corristo
Big Nerd Ranch RAC sample is just a nonsense. Non-idiomatic RAC code, using
nested callbacks completely defeats the purpose.

