5 ms·

So that's a good point, but I'm not quite sure OO is the issue. Also - as you hint it's entirely unnecessary, I do actually believe OO is a natural match for U

So that's a good point, but I'm not quite sure OO is the issue. Also - as you hint it's entirely unnecessary, I do actually believe OO is a natural match for UI because of the overlap between components. I think it's the fact in UI you have a big chunk of state, with references all over, and sometimes doing sort of 'circular references' ... Rust code starts to have a lot of the various Vec Rc Cell Box all over the place, and then honestly 'what's the point of rust'? And doing 'observers and events' feels unnatural, as well as the rest of the threading/stateful issues related to GUI. UI is also about a lot of small details and so the typing->compile->quick check is something that happens possibly more in UI - you have to often 'see' the results you can't just run the test. I like Rust, but it is a bit of 'Chinese Finger Trap' for smart people, and applying it to UI I think is basically upside down. I mean - fun to reason about and experiment with - but basically just wrong. I wonder if someone will come up with a language that is the UI version of Rust, with sufficient checking etc.. That would be cool, though I can't even fathom what that might be.

origin_path 4y ago
Isn't it done already? Kotlin plus a simpler OOP toolkit like javafx avoids all those problems. You have a GC to handle circular references, you have a decently strong type system, coroutines etc.
- kaba0 4y ago
  I don’t see why kotlin would be necessary. Javafx is good as is.
anon291 4y ago
> though I can't even fathom what that might be. One of the reasons why is that the notion of a GUI is ill-specified. Most ui frameworks, including the excellent ones, like QT, have corner cases where they fail. It's just that we've gotten to the point where coders kind have it in their bag of tricks to avoid these situations by defensive programming. Until we have a proper model of graphical UI, it'll be hard to make any such language. Think about the last time you had a weird UI bug (screen not redrawing, unexpected behavior, not able to see something that should be in scroll view, not able to scroll to something that is out of bounds, etc). Now think of the last time this happened in a terminal or REPL. We have no model of user interface that adequately covers the corner cases. We do have a model for CLIs. That's why guis tend not to work.
- jollybean 4y ago
  Yes that's a good point, but I'm not sure if the bugs in QT etc. are inherent, i.e. we probably can fix 'all of them'. You're right to point out 'a' model should be a reference though. Honesty though I fear in attempt to 'find' a model, we get forced upon us this FRP stuff for academic reasons of architectural purity. Despite QT's bugs, it mostly works just fine.
- Const-me 4y ago
  We do not have such a flawless model for CLIs. Command-line apps have their corner cases as well, and they fail too. Many CLI programs were designed in the assumption the display size never changes, like 80x25 characters. That's not true anymore, users resize their windows, the text in the terminal may or may not stay good after that. Terminals have a GUI state: cursor position, and current text attributes. That state may cause issues, especially when a program quits suddenly, like a crash.
  - anon291 4y ago
    > Terminals have a GUI state: cursor position, and current text attributes. That state may cause issues, especially when a program quits suddenly, like a crash. I have never in my life witness a terminal crash so hard that I couldn't fix it and get back all my other state. In 100% of cases, just typing Ctrl+C, Ctrl+Z, etc, followed by 'r', 'e', 's', 'e', 't', enter seems to have always done the trick.
    - Const-me 4y ago
      > In 100% of cases, just typing Ctrl+C, Ctrl+Z, etc, followed by 'r', 'e', 's', 'e', 't', enter seems to have always done the trick. Can confirm, these things helped me as well. Still, just because there's an easy workaround doesn't cancel the fact the observed behavior is a weird UI bug. Otherwise, one could argue web apps don't have weird bugs because there's F5=Refresh key which fixes 99% of them.
kaba0 4y ago
> Rust code starts to have a lot of the various Vec Rc Cell Box all over the place Well, C and C++ also has all of these, with the former having it in a convention-only manner, where you have to learn what the author intended for every project. These are generic paradigms that are useful and often needed for low-level programs, and Rust makes their usage safe. What I do find problematic regarding rust is that people want to apply it to everything, when it is a low level language, no matter how convenient it can look on the surface. Managed languages are more than fine for the vast majority of problems, they should not be replaced.
- pjmlp 4y ago
  Additionally, those with support for value types can take advantage of optimizations without switching languages.

origin_path 4y ago

Isn't it done already? Kotlin plus a simpler OOP toolkit like javafx avoids all those problems. You have a GC to handle circular references, you have a decently strong type system, coroutines etc.

kaba0 4y ago
I don’t see why kotlin would be necessary. Javafx is good as is.

anon291 4y ago

> though I can't even fathom what that might be. One of the reasons why is that the notion of a GUI is ill-specified. Most ui frameworks, including the excellent ones, like QT, have corner cases where they fail. It's just that we've gotten to the point where coders kind have it in their bag of tricks to avoid these situations by defensive programming. Until we have a proper model of graphical UI, it'll be hard to make any such language. Think about the last time you had a weird UI bug (screen not redrawing, unexpected behavior, not able to see something that should be in scroll view, not able to scroll to something that is out of bounds, etc). Now think of the last time this happened in a terminal or REPL. We have no model of user interface that adequately covers the corner cases. We do have a model for CLIs. That's why guis tend not to work.

jollybean 4y ago
Yes that's a good point, but I'm not sure if the bugs in QT etc. are inherent, i.e. we probably can fix 'all of them'. You're right to point out 'a' model should be a reference though. Honesty though I fear in attempt to 'find' a model, we get forced upon us this FRP stuff for academic reasons of architectural purity. Despite QT's bugs, it mostly works just fine.
Const-me 4y ago
We do not have such a flawless model for CLIs. Command-line apps have their corner cases as well, and they fail too. Many CLI programs were designed in the assumption the display size never changes, like 80x25 characters. That's not true anymore, users resize their windows, the text in the terminal may or may not stay good after that. Terminals have a GUI state: cursor position, and current text attributes. That state may cause issues, especially when a program quits suddenly, like a crash.
- anon291 4y ago
  > Terminals have a GUI state: cursor position, and current text attributes. That state may cause issues, especially when a program quits suddenly, like a crash. I have never in my life witness a terminal crash so hard that I couldn't fix it and get back all my other state. In 100% of cases, just typing Ctrl+C, Ctrl+Z, etc, followed by 'r', 'e', 's', 'e', 't', enter seems to have always done the trick.
  - Const-me 4y ago
    > In 100% of cases, just typing Ctrl+C, Ctrl+Z, etc, followed by 'r', 'e', 's', 'e', 't', enter seems to have always done the trick. Can confirm, these things helped me as well. Still, just because there's an easy workaround doesn't cancel the fact the observed behavior is a weird UI bug. Otherwise, one could argue web apps don't have weird bugs because there's F5=Refresh key which fixes 99% of them.

kaba0 4y ago

> Rust code starts to have a lot of the various Vec Rc Cell Box all over the place Well, C and C++ also has all of these, with the former having it in a convention-only manner, where you have to learn what the author intended for every project. These are generic paradigms that are useful and often needed for low-level programs, and Rust makes their usage safe. What I do find problematic regarding rust is that people want to apply it to everything, when it is a low level language, no matter how convenient it can look on the surface. Managed languages are more than fine for the vast majority of problems, they should not be replaced.

pjmlp 4y ago
Additionally, those with support for value types can take advantage of optimizations without switching languages.