| > great comparison of FP/OO approaches to UI Thanks! I think your analysis is very insightful, but there are some additional wrinkles. I don't really think it's just OO vs. FP or Desktop vs. Web, though those aspects definitely play a role. First, if it's an actual User Interface, something that the user interacts with, stability is not something imposed by platform convention or frameworks, but an inherent requirement: if I edit text, my text field (or editor) better be stable as I type, or it will be impossible (and infuriating)
to actually interact with. If I interact with a list, that list better be stable. etc. If it's just (mostly) visualisations that I consume mostly passively, that's a different matter (and then there are games, where you interact with a full-screen visualization). That's not to deny your observation that interfaces have become more fluid, certainly on mobile and web, and that there isn't a certain kind of desktop application with very static/forms based interfaces (business CRUD...). You can be more static on desktop because you have the screen real estate, and disabled but visible controls are generally considered to be better than things that hide/show/slide. So there's a bit more going on, and I think a crucial difference is how the more dynamic parts of interfaces are created. After all, it's not as if "classic" user interfaces are incapable of doing dynamic visulations and interfaces: you create a view, and within your view your drawRect: (Cocoa) method draws whatever you want however dynamically you want it. As an extreme example, 3D games tend to have an OpenGLView (now a MetalView) and inside that you have all the action. After all, "object orientation" has both: data-structures and methods that act on them, and OO user interfaces also have both, meaning you can get as "functional" as you want. You can compose objects, draw procedurally/functionally and mix and match both to your heart's content. For some reason, or maybe set of reasons, that doesn't seem to happen much any longer. Instead "object oriented" appears to be interpreted more in the way of "object oriented graphics", where you have a set of shapes (or widgets) that you can assemble, but without the part where objects can have arbitrary behaviour. What this unwillingness or inability to embrace the full capabilities of OO means is that when you have dynamically varying content, you now have to dynamically change the composition of your objects/widgets. Which, admittedly, those frameworks were not created for, I am guessing at least partly because they have a different mechanism for achieving those effects. > [Lists, functional approach, re-compute ] If you look at NSTableView and related, you will see that they also provide a fully lazy interface to the data source[1], which can be infinite. However, the caveat from above applies: those lists better be at least somewhat stable if you want to be able to interact with them. [1] https://developer.apple.com/documentation/appkit/nstableview... |
The point about stability as an inherent need for good UIs is true. I'll keep it in mind when thinking about this problem.
Here's two examples I can quickly think about where web interfaces are more fluid than desktop ones: 1) new UIs on hover. 2) accordions. In https://unsplash.com/, when you hover over any image, three new buttons appear; all of them are interactive elements. And accordions are anything that expands on click to reveal more content - expanding a Twitter thread in the web UI is one example.
These kind of interfaces were very rare in the desktop world. Winamp was one of the rare UIs in popular memory that worked like that. I think they were rare because the tooling - static widget-based UIs made with form builders like Delphi and VB6 - made them very difficult.
But even if we fully code the UI using objects; like say in Qt, or even in Cocoa, I think the development experience and the robustness of the code is better expressed in a functional paradigm.
I think both of us are ultimately using the affordance of writing UIs to judge OO and FP as computational paradigms. I think UI is one of the most concrete but underlooked ways to discuss this topic and measure relative trade-offs.
I've been doing OO programming for about a decade, but recently something clicked about "computation" which I've tried explaining in the first section here: https://protoship.io/blog/how-functional-is-ruby/. It is something around "OO vs FP = Stateful programming vs Explicit/pure programming = Turing Machine vs Lambda Calculus"