> I also thought the implementation was a little muddled
Yes! That was the point of that section of the paper, that doing the straightforward thing leads to a muddle:
"At this point, it becomes clear that our original strategy of updating the UI from the individual setter methods is probably not tenable in the long run."
A little later:
"As we have seen, even a conceptually very simple application such as a temperature converter quickly attracts significant complexity with non-obvious trade-offs once the requirements of an interactive version of that application are taken into account."
The fact that you need to create these centralised updater methods is non-obvious, and leads to a bunch of related non-local changes. Also a muddle.
"This complexity is not the result of a complicated domain model, but rather of the architectural embellishments required to move data from location to location in order to keep the different parts of the application (model, user interface, persistence) synchronized. In the next section, we will look at a mechanism for simplifying this kind of overhead."
> ReactJS (uses HOM like Objective-Smalltalk)
ReactJS uses Higher Order Messaging? Where?
> Chatty: "We highlight a strong coupling between languages and architecture,..."
Which was my point, yes, thank you! We are limited in what languages let us express cleanly. React/SwiftUI etc. are workarounds for this issue: they try to re-cast the GUI "problem" as a simple function/procedure. "The UI is a pure function of the model". If it were true, that would make things very simple. Alas, it isn't true: https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
But even without being true, it makes things very convenient, particularly for simple cases.
> feature rich FP languages around, aren't popular for GUI development. If there was a tangible benefit, I believe it would have been demonstrated.
Yes. There isn't. If you look at the papers, you will see that the benefit isn't so much claimed as assumed: "now we can get the wonders of FP for nasty GUI development".
> "And not group little bits of GUI+model together, that way madness lies." - almost every game engine and GUI framework uses it.
Yep, and that's why they all share the same problems (roughly "Massive View Controller"). It's not a trivial issue, because reusable widgets definitely make sense, but they lead you down a nasty path. https://blog.metaobject.com/2015/04/model-widget-controller-...
You need to treat those widgets as easy-to-use Views, and interact with them largely as if they were just views.
> It means you work with constraints, for example dataflow constraints.
I'm not sure anyone else would call that anything but an interface (not an "implements programmatic interface"). I was being gracious with separation of concerns, because a SoC implies a dataflow constraint that isn't necessarily enforced only by mechanism, where there can also be convention.
> What's VNA?
von Neumann Architecture
> The fact that you need to create these centralised updater methods is non-obvious, and leads to a bunch of related non-local changes. Also a muddle.
Synchronization requires synchronous operations. There are refresh rates physically and render methods virtually. This is obvious and not adhering to that is unmaintainable, due to confounding variables. If there were {N} programs to manage {N} components under a singular view, how is messaging handled? Messaging requires synchronization, which requires something akin to a render().
You have physical limitations on how many states can be maintained at any given moment and mapping limitations ie 2^3 (DNA) > 2 (Turing) states giving you more complexity, which is still bounded. An underlying dataflow constraint is still fundamentally a system that has to transfer the same information.
>> It means you work with constraints, for example dataflow constraints.
> I'm not sure anyone else would call that anything but an interface
I am sure that nobody calls that an "interface". First, a dataflow constraint is nothing like an interface (for one it is an implementation). It's also a standard term of art.
> This is obvious and not adhering to that is unmaintainable, due to confounding variables
It's actually not obvious, as shown in the paper. And it is not intrinsically necessary. It is necessitated by the architectural mismatch.
> Messaging requires synchronization, which requires something akin to a render().
Exactly. Messaging pretty much requires this, or more generally "call/return" requires this as a user-visible and user-defined construct, due to to the mismatched architectures.
Dataflow constraints, as shown in the paper, do not require anything like this at all. A more appropriate architectural style makes the requirement vanish into nothingness.
> An underlying dataflow constraint is still fundamentally a system that has to transfer the same information.
Exactly, but it allows us to structure those transfers in a vastly more straightforward and obvious manner, as demonstrated in the paper.
It doesn't. It means you work with constraints, for example dataflow constraints.
For example: https://dl.acm.org/doi/abs/10.1145/506315.506318
> I also thought the implementation was a little muddled
Yes! That was the point of that section of the paper, that doing the straightforward thing leads to a muddle:
"At this point, it becomes clear that our original strategy of updating the UI from the individual setter methods is probably not tenable in the long run."
A little later:
"As we have seen, even a conceptually very simple application such as a temperature converter quickly attracts significant complexity with non-obvious trade-offs once the requirements of an interactive version of that application are taken into account."
The fact that you need to create these centralised updater methods is non-obvious, and leads to a bunch of related non-local changes. Also a muddle.
"This complexity is not the result of a complicated domain model, but rather of the architectural embellishments required to move data from location to location in order to keep the different parts of the application (model, user interface, persistence) synchronized. In the next section, we will look at a mechanism for simplifying this kind of overhead."
> ReactJS (uses HOM like Objective-Smalltalk)
ReactJS uses Higher Order Messaging? Where?
> Chatty: "We highlight a strong coupling between languages and architecture,..."
Which was my point, yes, thank you! We are limited in what languages let us express cleanly. React/SwiftUI etc. are workarounds for this issue: they try to re-cast the GUI "problem" as a simple function/procedure. "The UI is a pure function of the model". If it were true, that would make things very simple. Alas, it isn't true: https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
But even without being true, it makes things very convenient, particularly for simple cases.
> Backus (https://dl.acm.org/doi/pdf/10.1145/359576.359579) proposed that FP was possibly preferable.
Yep, but he later said that FP was a mistake (Interview with Grady Booch).
https://www.youtube.com/watch?t=3896&v=dDsWTyLEgbk&feature=y...
> The main problem with presenting FP as a different architecture, is that it's just a bunch of abstractions on top of VNA
That is also one of my contentions: FP, procedural and OO are just variants of the call/return architectural style.
https://dl.acm.org/doi/10.1145/3397537.3397546
Which is why they are insufficient for today's systems.
What's VNA?
> you might enjoy watching https://www.youtube.com/watch?v=otAcmD6XEEE
Yes, already seen it. Was good.
> feature rich FP languages around, aren't popular for GUI development. If there was a tangible benefit, I believe it would have been demonstrated.
Yes. There isn't. If you look at the papers, you will see that the benefit isn't so much claimed as assumed: "now we can get the wonders of FP for nasty GUI development".
> "And not group little bits of GUI+model together, that way madness lies." - almost every game engine and GUI framework uses it.
Yep, and that's why they all share the same problems (roughly "Massive View Controller"). It's not a trivial issue, because reusable widgets definitely make sense, but they lead you down a nasty path. https://blog.metaobject.com/2015/04/model-widget-controller-...
You need to treat those widgets as easy-to-use Views, and interact with them largely as if they were just views.