Hacker News Reader

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.

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

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

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.

More reactive usually means less global state, which is generally for the better. It also encourages functional purity where possible. Previously (briefly) in iOS/macOS there was an attempt to move to closure-based APIs, which led to unreadable tangles of function invocations with often surprising calling threads. Before that for a long time there was a weak delegate object pattern, probably the least convenient way of interacting with things.

It also means more memory being used.

Do you mean that it tends to require using immutable data structures?

Yes, and that it gets generated and thrown away in each view update, even if a view diff is taken into account.

At least with closure based code, you can set a breakpoint and see the chain of executions which led to your critical portion. With FRP, basic flow of control is surrendered to the scheduler, and your stack trace doesn't tell you anything.

The other thing I'm not a fan of with FRP is that it makes the assumption that it's somehow good to deal with everything through one big unified abstraction layer. Rather than just dealing with your concrete business logic, you also have to set-shift to think about the flow of your program in terms of abstract chains of observables.

This level of abstraction makes the interfaces in your code less clear as well. For instance, with the delegate pattern, you can take a look at the protocol of the object you're consuming and get a clear idea about what the intent of that protocol is. In an FRP world, your interface point might be an Int-valued observable, which could be just about anything. To see how it's going to behave, you have to go see how that particular observable is defined in the calling context, which might end up being some chain of map-zip-filter-debounce operators which further obfuscate the intent. More abstraction rarely makes a program more readable or more performant, and FRP is all about abstraction.

Also I think you're poking at a false dichotomy with reference to things like global state, and functional purity. It's very possible to write simple, imperative code which makes use of pure functional programming, and immutable state. FRP puts you in kind of a "jail" which encourages you to produce code with those properties, but it comes with a lot of unnecessary costs as well.

There is no dichotomy here, it's perfectly fine to use imperative code where it fits better.

I would not agree that using any particular technology makes code less clear. Also, I'm not sure how protocol interfaces, callback-based interfaces and reactive event sources differ in readability as they all basically provide a way to call your code at (without referring to documentation) random times.

Doesn't an application still have a state, even if you don't store/manage it explicitly?

Isn't a program more understandable if that state is sometimes made explicit rather than implicit?

Also if your goal is 'functional purity' then you might want to read this article from ten years ago.

https://prog21.dadgum.com/55.html

The state is there, of course. The goal here is to minimize the amount of state the code has access to at any particular time.

Functional purity is not the goal, it's just one way to reduce state.

So you still have state, but you can't get at it because it's been moved from the heap to the call stack?

I'm not sure that makes programs:

1. Easily evolve-able.

2. Easy to understand.

Well managed accessible state can be greatly simplifying.

In my view the goal should be simple understandable code, not a meta-goal like removing all accessible state.

I don't know, actually. Should the state other that what the task (or sub-task) can observe matter for it to function? Where would be the boundary, as there are lots of things happening simultaneously in a computer, and the global state is huge.

> Well managed accessible state can be greatly simplifying.

Absolutely--and functional programming is one way to achieve that. From the perspective a given function, all "state" is captured in its inputs and outputs. You know exactly what existing state can be used by the function (inputs) and exactly what state can be generated by the function (outputs) simply from looking at the signature.

I'm talking about the difficultly of reasoning about high level application state when it isn't explicit.

To take a low level example - sorting a list efficiently is easy with imperative programming and mutable state ( Note you can still encapsulate that state within a object - it doesn't need to be global ).

On the other hand took about 20 years before somebody worked how to do it reasonably with a functional approach.

Being obsessive about a pure functional approach and/or having a holy war against heap managed state is a mistake in my view.

Functional approach is a tool in the toolbox, not a golden hammer.

Totally agreed. Being obsessive about (almost) anything in software is a recipe for pain.

I couldn’t agree more. « All reactive GUI» on iOS has been a total disaster in the only place i’ve seen it tried. It’s just the new fashion buzzword of the day, and it will follow the same bell-curve as the rest : people will use it everywhere, then after they realize it sometimes makes simple things harder, will learn to use it only where it really makes sense.

Since when did FRP come to denote any random framework that focused on reactivity and was somewhat functional vs the stuff Elliott and Hudak did in Haskell?