5 ms·

C++ (and even Rust) is not the best language to build UIs. Even if your app heavily uses C/C++ to do heavy computations, "scripting" language will be preferable

by ungzd 7y ago

C++ (and even Rust) is not the best language to build UIs. Even if your app heavily uses C/C++ to do heavy computations, "scripting" language will be preferable for "glue code". QML is not a crazy new idea, for example Tk used Tcl. And due to C++ API, Qt has poor language bindings, compared to GTK and many others with C API.

qekbg 7y ago
>C++ (and even Rust) is not the best language to build UIs. Why? And why are scripting languages better?
- ygra 7y ago
  Developer productivity when building or redesigning a UI is often far more important than raw performance. There's usually no noticeable difference for a user whether the dialog they opened via a button click is built in highly optimized C++ or from an XML resource stream that is read, parsed, and the UI constructed on the fly by effectively interpreting the UI description. It's okay to have expensive abstractions where a few milliseconds simply don't matter, but tasks can be done in minutes instead of hours. Declarative UI descriptions also have the benefit of being friendly to visual designer applications, so you need fewer build/run/test cycles (which are far from quick with C++).
  - qekbg 7y ago
    >There's usually no noticeable difference for a user whether the dialog they opened via a button click is built in highly optimized C++ or from an XML resource stream that is read, parsed, and the UI constructed on the fly by effectively interpreting the UI description. I dare you to compare the speed of UIs of Windows XP and Windows 10, even when using the hardware that was current when those OSes were released.
    - hedora 7y ago
      Someone did a detailed study of UI responsiveness vs year. Responsiveness peaked in the 80’s, in the dumb terminal + regional mainframe era. :-(
      - badsectoracula 7y ago
        Do you have a link? If it is the one i remember it was about keyboard-to-output responsiveness (and the winner was something like a C64 or Apple 2 or something like that), not overall UI (and i'm a bit skeptical about the dumb terminal part considering the communication latencies involved, especially in the 80s).
  - blub 7y ago
    This "productivity is more important than raw performance" meme again... Your first paragraph claims the opposite of what's happening reality: there is a noticeable difference between clicking that highly optimized C++ button and going through XML, as seen in Mozilla's XUL or typical web apps. I can't even imagine why you'd think that reading and parsing XML and constructing a UI would be cheaper than any other way of building UIs.
    - coldtea 7y ago
      >there is a noticeable difference between clicking that highly optimized C++ button and going through XML, as seen in Mozilla's XUL or typical web apps. Really, did you measure it? Since we are, scientists and everything? Where are the numbers? And how do any differences you've found compare (timing wise) with human initiated action and perception latencies -- like those required to click an on-screen button and see it being depressed? >as seen in Mozilla's XUL or typical web apps You see button being pressed time/action as a problem in "XUL or typical web apps"? (Memory consumption when the drawing is done with DOM, or slow rendering of large scene graphs, I'd buy -- but this is not the model we're talking here, where JS calls a native control directly, and doesn't render through DOM/web rendering). >I can't even imagine why you'd think that reading and parsing XML and constructing a UI would be cheaper than any other way of building UIs. Actually that's the way tons of native apps work, from games, to Gnome, to Windows and so on. Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it...
      - rat9988 7y ago
        >Really, did you measure it? Since we are, scientists and everything? Where are the numbers? This remark should (also) have been directed at his parent comment, who made the contrary claim without any measurement either. > Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it... The numbers?
- oblio 7y ago
  Memory management.
- codr7 7y ago
  The user interface tends to be a relatively dynamic part of the application. Most of this is no longer as relevant in C++, can't speak for Rust. Programming languages have been converging for quite some time, C++ of today is more dynamic and convenient than any version that came before. That being said, you can't beat dynamic languages for some tasks. Runtime code generation/eval being the most obvious I can think of. Any kind of extension/plugin architecture has everything to win from going all in with a full scripting language from my experience.
blub 7y ago
I believe you're incorrect, C++ is a good language for building UIs, as proven by the plethora of UI libraries and frameworks built in C++ for pretty much all platforms. This is visible when comparing PyQt and C++: yes, PyQt is easier to get into, has nicer syntax, but C++ offers more power. Even hot-loading UIs, a typical scripting language advantage is supported. Declarative UI languages do have some advantages compared to regular programming languages, but that's unrelated to the claim you made. Bindings are not C++'s problem, they're the problem of the other languages which try to use UI frameworks written in C++, like Rust, which still doesn't have any decent UI library.
- protomyth 7y ago
  I keep coming back to the differences between OPENSTEP and Taligent and believe C++ isn't the best choice.
  - ptx 7y ago
    What were some of the differences? (Other than Taligent dying and OPENSTEP surviving via Mac OS X, which is all I know about the topic.)
    - infinite8s 7y ago
      There's a reason Qt had to invent the MOC.
    - protomyth 7y ago
      https://books.google.com/books?id=e35JCAAAQBAJ&pg=PT139&lpg=PT139&dq=taligent+Aaron+Hillegass,&source=bl&ots=VGTriuTmE4&sig=ACfU3U0BS9ypil2LRv-OULhT63NBUpAh5Q&hl=en&sa=X&ved=2ahUKEwjshOuS9fPjAhUYWs0KHUP2CnAQ6AEwA3oECAMQAQ#v=onepage&q=taligent%20Aaron%20Hillegass%2C&f=false https://books.google.com/books?id=e35JCAAAQBAJ&pg=PT139&lpg=... Gives the basics of the difference
- jlarocco 7y ago
  > This is visible when comparing PyQt and C++: yes, PyQt is easier to get into, has nicer syntax, but C++ offers more power. That may be true for Python, but the Common Lisp bindings for Qt4 were equally as "powerful" as the C++ bindings. It had higher level abstractions that generally made it easier to read and write, as well. > Bindings are not C++'s problem Actually, bindings are a problem with C++. Some features (like templates) and implementation details (like name mangling) make it very difficult to create bindings to C++.

by ungzd 7y ago

qekbg 7y ago

>C++ (and even Rust) is not the best language to build UIs. Why? And why are scripting languages better?

ygra 7y ago
Developer productivity when building or redesigning a UI is often far more important than raw performance. There's usually no noticeable difference for a user whether the dialog they opened via a button click is built in highly optimized C++ or from an XML resource stream that is read, parsed, and the UI constructed on the fly by effectively interpreting the UI description. It's okay to have expensive abstractions where a few milliseconds simply don't matter, but tasks can be done in minutes instead of hours. Declarative UI descriptions also have the benefit of being friendly to visual designer applications, so you need fewer build/run/test cycles (which are far from quick with C++).
- qekbg 7y ago
  >There's usually no noticeable difference for a user whether the dialog they opened via a button click is built in highly optimized C++ or from an XML resource stream that is read, parsed, and the UI constructed on the fly by effectively interpreting the UI description. I dare you to compare the speed of UIs of Windows XP and Windows 10, even when using the hardware that was current when those OSes were released.
  - hedora 7y ago
    Someone did a detailed study of UI responsiveness vs year. Responsiveness peaked in the 80’s, in the dumb terminal + regional mainframe era. :-(
    - badsectoracula 7y ago
      Do you have a link? If it is the one i remember it was about keyboard-to-output responsiveness (and the winner was something like a C64 or Apple 2 or something like that), not overall UI (and i'm a bit skeptical about the dumb terminal part considering the communication latencies involved, especially in the 80s).
- blub 7y ago
  This "productivity is more important than raw performance" meme again... Your first paragraph claims the opposite of what's happening reality: there is a noticeable difference between clicking that highly optimized C++ button and going through XML, as seen in Mozilla's XUL or typical web apps. I can't even imagine why you'd think that reading and parsing XML and constructing a UI would be cheaper than any other way of building UIs.
  - coldtea 7y ago
    >there is a noticeable difference between clicking that highly optimized C++ button and going through XML, as seen in Mozilla's XUL or typical web apps. Really, did you measure it? Since we are, scientists and everything? Where are the numbers? And how do any differences you've found compare (timing wise) with human initiated action and perception latencies -- like those required to click an on-screen button and see it being depressed? >as seen in Mozilla's XUL or typical web apps You see button being pressed time/action as a problem in "XUL or typical web apps"? (Memory consumption when the drawing is done with DOM, or slow rendering of large scene graphs, I'd buy -- but this is not the model we're talking here, where JS calls a native control directly, and doesn't render through DOM/web rendering). >I can't even imagine why you'd think that reading and parsing XML and constructing a UI would be cheaper than any other way of building UIs. Actually that's the way tons of native apps work, from games, to Gnome, to Windows and so on. Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it...
    - rat9988 7y ago
      >Really, did you measure it? Since we are, scientists and everything? Where are the numbers? This remark should (also) have been directed at his parent comment, who made the contrary claim without any measurement either. > Second, if you think the "parsing a XML UI declaration" is in any meaningful way more expensive that imperatively calling a bunch of UI functions directly, you have a distorted idea of what makes a UI slow, or of the time needed to parse an XML file and initialized controls based on it... The numbers?
oblio 7y ago
Memory management.
codr7 7y ago
The user interface tends to be a relatively dynamic part of the application. Most of this is no longer as relevant in C++, can't speak for Rust. Programming languages have been converging for quite some time, C++ of today is more dynamic and convenient than any version that came before. That being said, you can't beat dynamic languages for some tasks. Runtime code generation/eval being the most obvious I can think of. Any kind of extension/plugin architecture has everything to win from going all in with a full scripting language from my experience.

blub 7y ago

I believe you're incorrect, C++ is a good language for building UIs, as proven by the plethora of UI libraries and frameworks built in C++ for pretty much all platforms. This is visible when comparing PyQt and C++: yes, PyQt is easier to get into, has nicer syntax, but C++ offers more power. Even hot-loading UIs, a typical scripting language advantage is supported. Declarative UI languages do have some advantages compared to regular programming languages, but that's unrelated to the claim you made. Bindings are not C++'s problem, they're the problem of the other languages which try to use UI frameworks written in C++, like Rust, which still doesn't have any decent UI library.

protomyth 7y ago
I keep coming back to the differences between OPENSTEP and Taligent and believe C++ isn't the best choice.
- ptx 7y ago
  What were some of the differences? (Other than Taligent dying and OPENSTEP surviving via Mac OS X, which is all I know about the topic.)
  - infinite8s 7y ago
    There's a reason Qt had to invent the MOC.
  - protomyth 7y ago
    https://books.google.com/books?id=e35JCAAAQBAJ&pg=PT139&lpg=PT139&dq=taligent+Aaron+Hillegass,&source=bl&ots=VGTriuTmE4&sig=ACfU3U0BS9ypil2LRv-OULhT63NBUpAh5Q&hl=en&sa=X&ved=2ahUKEwjshOuS9fPjAhUYWs0KHUP2CnAQ6AEwA3oECAMQAQ#v=onepage&q=taligent%20Aaron%20Hillegass%2C&f=false https://books.google.com/books?id=e35JCAAAQBAJ&pg=PT139&lpg=... Gives the basics of the difference
jlarocco 7y ago
> This is visible when comparing PyQt and C++: yes, PyQt is easier to get into, has nicer syntax, but C++ offers more power. That may be true for Python, but the Common Lisp bindings for Qt4 were equally as "powerful" as the C++ bindings. It had higher level abstractions that generally made it easier to read and write, as well. > Bindings are not C++'s problem Actually, bindings are a problem with C++. Some features (like templates) and implementation details (like name mangling) make it very difficult to create bindings to C++.