Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Excerpt from https://reactivex.slack.com about API design, especially as it relates to RAC

carlossless [09:50] So anyone used RxSwift? I’m wondering what are your thoughts and opinions vs RAC3.

jspahrsummers [10:00] @carlossless: https://github.com/ReactiveCocoa/ReactiveCocoa/blob/07813339d3c44aa02fb1b71777baa4ede0f0f77a/README.md#how-does-reactivecocoa-relate-to-rx

carlossless [10:13] Yeah, I was looking for a more practical point of view but even so. RxSwift has UI bindings, it follows the haskell naming for most transformation and composition functions ​map​, ​filter​ etc. rather than ​select​, ​where​.

carlossless [10:14] I find some things harder to do with RAC3 than with RAC2, and this is probably because of the standpoint ​_not_making_things_we_dont_want_you_to_do_easy_to_do_​.

carlossless [10:15] that was a mouthful.

jspahrsummers [10:16] The patterns that are easier in RAC 2 vs. 3 are usually those patterns that:

  1. Confuse newcomers
  2. Turn off people considering RAC
  3. Cause unexpected difficulty down the road

jspahrsummers [10:16] My usual philosophy is: pay a marginally higher difficulty cost up-front, to avoid unexpected problems later

jspahrsummers [10:16] e.g. error handling in RAC 3 property bindings

jspahrsummers [10:17] Rx and RxSwift probably do not agree with that philosophy, in general.

carlossless [10:20]

My usual philosophy is: pay a marginally higher difficulty cost up-front, to avoid unexpected problems later

So isin’t this like the main reason why rac would attract seasoned developers, and shun away newcomers. Same problem Haskell probably has.

jspahrsummers [10:20] Obviously, all else being equal, it would be great to have ​_no_​ cost now or later. But that’s rarely how API design works.

jspahrsummers [10:21] If people get “taken in” by an easy-to-use API, and then run into a shitstorm down the road, they blame it and swear it off forever.

jspahrsummers [10:21] see: Core Data, etc.

jspahrsummers [10:21] I guess I would rather have fewer users, but cause those users fewer problems overall. 😛

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment