[robbbbbb]

Actually your last point was the aspect of this article I liked the most. Most examples I come across of applying non-imperative patterns to fundamentally stateful applications (UI, games) cheat at the last hurdle.

It's usually "we take a model, apply a transformation, creating a new model, and display it - no side effects, we're heroes, now everyone agree to never use imperative languages ever again!" but then forget that they've now created a copy of their entire system, which may cause havoc with anything from memory budgets to publish-subscribe setups or asynchronous update/display loops.

At least by not sidestepping this thorny part of the problem the authors are showing a sensible solution which doesn't try to pretend a UI composed from NSViews is a stateless system. Instead they show a reasonable way to maintain its state through diffing it against an idealised model, localising the changes (additions, deletions, updates) to the minimum necessary.

[encloser]

> ...but then forget that they've now created a copy of their entire system

With persistent data structures you don't have a whole copy of the entire system. The two views of your system share memory where information didn't change. Sort of like how Git works.

[robbbbbb]

You're absolutely right, and persistent datastructures are exactly the right solution for this problem domain. But that doesn't get round the fact that they are a hell of a lot harder to implement and to understand in comparison to what you had before in an imperative, mutable world (as a UI programmer I now deal with diffing and versioning whereas before I simply mutated variables).