[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: 1735502257275393.jpg (333 KB, 1700x2000)
333 KB
333 KB JPG
>OOP is great for GUIs, it's actually the best
Is this actually the case though? Or are we just mistaking the natural mapping of OOP onto the logic of our naive mental frameworks?
I don't think I've ever seen a UI paradigm that even attempted doing something that's not OOP or a similar imperative approach.
>>
>>107262633
You're coping hard, OP. OOP does map nicely to widget hierarchies and event handling because GUIs are inherently stateful and compositional—buttons have properties, containers hold children, etc. But it's not the only game in town, and claiming it's "the best" is peak Stockholm syndrome from decades of Smalltalk/Windows hegemony.

There are plenty of non-OOP paradigms that work just fine, or even better for certain use cases:

>Declarative/Functional UIs**: Think React (with hooks/functional components), Elm, or Flutter. You don't mutate objects imperatively; you declare what the UI should look like based on state, and the framework diffs/reconciles changes. No "class Button extends Widget" boilerplate—just pure functions mapping data to UI trees. Elm in particular is purely functional, no side effects, and it's great for web UIs without the OOP cruft.

>Immediate Mode GUIs**: Libraries like Dear ImGui or Nuklear ditch the retained object model entirely. Every frame, you procedurally describe the UI in code (e.g., if (imgui.Button("Click me")) { do_stuff(); }). No persistent objects, no inheritance hierarchies—just functions calling functions. Super lightweight for games/tools, and it avoids the memory/state management hell of OOP GUIs.

- **Data-Oriented/ECS Approaches**: In game engines like Unity (with newer DOTS) or Bevy, UI can be treated as entities with components, not objects. It's more about data transformation than method calls on instances.

We've stuck with OOP for GUIs mostly because early frameworks (MFC, Swing, GTK+) were built that way, and it mirrors how we think about physical interfaces (e.g., "this window owns these buttons"). But if you look at modern web dev or mobile, declarative is eating OOP's lunch for productivity and maintainability. Try building something in Svelte or SolidJS—feels liberating without the class bloat.
>>
>>107262701
Fuck off LLMfag
>>107262633
Fuck off tranime whore poster
>>
>>107262724
Based. You tell them.
>inb4 Fuck off ass kisser
>>
>>107262701
Every programming paradigm has state. The fact that GUIs are compositional would imply OOP is a poor choice since it expresses and handles composition rather poorly. None of your examples are really foundationally different from any each other.



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.