Flutter desktop shells

It is evidentially true. Thousands of successful applications and a billions of lines of UI code have been written in object oriented languages. It does work and it can't be that bad if that's continuing to happen even after the emergence of other alternatives.

Whether there are better ways is a good question, but I think it's pretty clear that you can ship good apps using OOP for your UI.

> React Hooks and immediate mode GUI in general demonstrate that it's not true.

I'm far enough into my career now — I've been doing UI programming of one form or another since the 90s — to have seen that pendulum swing several times. If there is a silver bullet, we haven't found it. It's probably not immediate mode GUIs because if it was, I wouldn't have seen game teams tear them out to replace them with something more retained several times in the 2000s.

What I think actually happens is that we forget the problems lurking in the solution we are not currently using. The grass over there gets greener and greener until we hop the fence and the cycle starts over. Incremental progress does happen. (I am not keen to revisit MFC any time soon.) But if a given concept (1) has been around a long time (2) has not already supplanted the alternatives, it's pretty unlikely that it is now an amazing solution today. The only time when that isn't true is when the surrounding technology context has changed since then.

For example, neural nets weren't a good solution for AI problems in the 80s because compute was too expensive and we didn't have a lot of data. Now that CPUs are cheap and everyone puts their entire life on the Internet, machine learning is here.

I haven't seen anything around UIs that to me looks like a significantly changed context, so I think we're still orbiting around retained-mode and immediate-mode as both having their own trade-offs and neither being a slam dunk.

> I think that "zen koan" you mentioned earlier is being very generous to subclassing. You want ADTs most of the time!

I really don't think that's true. Just look out there in the world. More code is written in languages doing subclassing every day than in languages with sum types. Despite the fact that sum types have been around since the 70s. You have to have a very uncharitable opinion of all of your fellow programmers to believe they've all been getting this wrong for decades. Heck, the software you are using right now to read this comment is sitting on a stack of several layers of subclass-based architectures! You've got JS running on top of the DOM inside a browser written in C++.

Sum types are really nice. But open-ended subclassing is too.

Sure, but does it do what you want? :) If that map contains pointers or other types with "interesting" assignment semantics, then your idea of a deep copy and that author of that type's idea may not be the same. Cloning is a surprisingly hard problem.

The two languages you compare to don't have GCs and prefer value semantics. But in most GC languages, everything is by reference and "copying the bits" isn't as meaningful of an operation.

I looked up how to deep clone maps in some other GC languages:

https://stackoverflow.com/questions/4157399/how-do-i-copy-a-...

Ruby: Top suggestion is to marhsall/unmarshall it.

https://stackoverflow.com/questions/5105517/deep-copy-of-a-d...

Python: Import a separate "copy" module. May have to implement some custom methods if you use user-defined objects in the map. The module isn't thread-safe. A comment recommends converting to JSON and back.

https://stackoverflow.com/questions/28288546/how-to-copy-has...

Java: No built in solution. Have to traverse the map yourself and do element-wise copies.

Some issues (it's been some time so memory is a bit hazy):

- Lack of good documentation, both official and alternative (ultimately found a good reference book).

- Lack of customization on some widget, even compared to Swing (remember being really disappointed at how hard it was to modify the built-in tab-view).

- I really don't like the built not-quite CSS. Remember having trouble finding documentation for it. Also why a different language and not just code — like for the rest.

- Was really put off by some parts of the API design, even compared to Swing. Something that I remember is that there was a half-baked support for "theming" that isn't really usable nor used.

- This is much more debatable, and I won't wish ill on people who dismiss it, but it feels like it's completely out of the zeitgeist. I don't know if people doing unsexy jobs use JavaFX, but very people talk/write about it over the internet. Compared to Swing, the dearth of resources is staggering. It also created a lot of FUD that you can easily find if you google a bit. Don't use Swing cause it might be deprecated in favor of JavaFX (unlikely?). JavaFX hasn't really been updated nor hyped since Oracle took over, it's just rotting. IIRC it's not even bundled with the VM anymore, which is more headaches for distribution.

Only exception: https://tornadofx.io/ has some love in the Kotlin community.

- You have to link to different JavaFX jars for different platform, which makes any kind of Maven (etc) based dependency management a nightmare.