6 ms·

I must say I welcome it, unreadable tangles are agnostic, and can be written with any kind of pattern or language, and stack traces still work as you expect (al

I must say I welcome it, unreadable tangles are agnostic, and can be written with any kind of pattern or language, and stack traces still work as you expect (although stack traces never been great on iOS). In every project you always end up trying to solve the same problem of how to best propagate events and errors, often in an asynchronous fashion. So you end up with delegates, notifications, callbacks - but after a while you realize that all of that can be neatly distilled down to a single way of doing things. Then you got all these powerful build-in operations, which come in handy sometimes, and it's also much better at making sure you're actually handling all the possible cases.

skohan 7y ago
> In every project you always end up trying to solve the same problem of how to best propagate events and errors, often in an asynchronous fashion. So you end up with delegates, notifications, callbacks - but after a while you realize that all of that can be neatly distilled down to a single way of doing things. I have seen this argument in favor of FRP a lot of places, but in my experience the problem is just vastly overstated. In terms of practical mobile development, the asynchronicity you're dealing with is mostly network operations which execute exactly once per page. The abstractions RxSwift, for example, give you for that are complete overkill for something which can be handled perfectly well by throwing a few lines of imperative code onto a background thread. Besides that, you might have a few global events to handle like login and logout, which can be handled perfectly well by any number of event/emitter APIs or even a hand-rolled implementation of a few dozen lines. I don't understand why I need to import thousands of lines of code into my project just to "unify" these concerns.
- dep_b 7y ago
  > In terms of practical mobile development, the asynchronicity you're dealing with is mostly network operations which execute exactly once per page. Absolutely not true, I have been dealing with a lot of "simple" apps and always once you start introducing stuff like Push Notifications that trigger actions, websockets that send and receive messages and other "unexpected" messages to handle the traditional MVC methods just fall apart. Having said that you can do pretty similar stuff without introducing RxSwift into your application. With or without it, getting these entangled multi-source event handling mechanisms to work well takes a really disciplined approach.
  - skohan 7y ago
    Both of the cases you mentioned could easily be modeled by simple event emitters. Yeah you could use and RX implementation, but 90% of the library would not be relevant and you'd be adding a lot of complexity without adding any value.

skohan 7y ago

> In every project you always end up trying to solve the same problem of how to best propagate events and errors, often in an asynchronous fashion. So you end up with delegates, notifications, callbacks - but after a while you realize that all of that can be neatly distilled down to a single way of doing things. I have seen this argument in favor of FRP a lot of places, but in my experience the problem is just vastly overstated. In terms of practical mobile development, the asynchronicity you're dealing with is mostly network operations which execute exactly once per page. The abstractions RxSwift, for example, give you for that are complete overkill for something which can be handled perfectly well by throwing a few lines of imperative code onto a background thread. Besides that, you might have a few global events to handle like login and logout, which can be handled perfectly well by any number of event/emitter APIs or even a hand-rolled implementation of a few dozen lines. I don't understand why I need to import thousands of lines of code into my project just to "unify" these concerns.

dep_b 7y ago
> In terms of practical mobile development, the asynchronicity you're dealing with is mostly network operations which execute exactly once per page. Absolutely not true, I have been dealing with a lot of "simple" apps and always once you start introducing stuff like Push Notifications that trigger actions, websockets that send and receive messages and other "unexpected" messages to handle the traditional MVC methods just fall apart. Having said that you can do pretty similar stuff without introducing RxSwift into your application. With or without it, getting these entangled multi-source event handling mechanisms to work well takes a really disciplined approach.
- skohan 7y ago
  Both of the cases you mentioned could easily be modeled by simple event emitters. Yeah you could use and RX implementation, but 90% of the library would not be relevant and you'd be adding a lot of complexity without adding any value.