iOS: FRP or classical imperative programming?
I definitely find FRP compelling, especially latest (swiftest?) ReactiveCocoa3 implementation.
But should I really consider switching to this FRP mental model of making iOS applications? Should one consider the good old imperative model of making software as predecessor of modern, functional, reactive way?
Having been reading all this articles about advantages of FRP I sometimes find myself as a programmer who had been writing software in ASM before C came. I mean, OK I agree that sometimes managing exponentially growing state is overkill but is transforming Signal/SignalProducer's to _declare_ what I want to achieve a good tradeoff?
0 comments
[ 0.20 ms ] story [ 11.9 ms ] threadNo comments yet.