Yeah, in my experience, just MV is largely just fine.

I like the term "GluePuppy". It absolutely is a crucial part, or parts.

Basically, it defines the architecture of the system, pulls all the objects together and connects them to create a useful system.

It doesn't help that we don't have linguistic support for "glueing things together", we only have procedure calls. So that's one of the issues I am addressing with Objective-S, actual linguistic support for "glue". And yeah, please don't put the rules/distinctions over designing a clean system.

That was a thing I discovered only recently when working with two teams, one Android and one iOS: developers in general, and particularly good architects, want to build these uniformly recursively decomposed modules.

You can't do that with a good OO architecture, because you absolutely need the GluePuppy to tie things together. That one is different from the other modules. If you don't allow for a GluePuppy, but instead insist on uniform modules, you inescapably get procedural decomposition instead of OO decomposition. If you are in an OO language, that means singletons everywhere, because every module needs to know about its dependencies. And that gets you into a world of hurt when you want to do what OO is supposed to be good for, handle variation.

Embrace the GluePuppy! It loves you and wants to make your life simpler.

The "lets-use-the-call-tree-to-mirror-the-view-tree" fashion also has to do with this, IMHO, because our languages only have support for writing down procedures. So if you can get your view-tree expressed by the call-tree, you get to write it down directly in the code, rather than constructing it indirectly, with the view-tree being a hidden side effect.

That is a clear benefit, but the costs are pretty horrendous.

How about we extend our languages so that we can also write down those view hierarchies directly in the code, and at the same time using a format that can also be read/written as data (down LISPers, down)?