6 ms·

Unfortunatelly PyQt does not solve the problem of Javascript engineers who are not willing to learn a new programming language. That's the whole reason for the

Unfortunatelly PyQt does not solve the problem of Javascript engineers who are not willing to learn a new programming language. That's the whole reason for the whole Javascript fadigue. Computer Science has had "had tools for the right jobs" for years, but now we have a large developer base that only knows Javascript and think it's some kind of holy grail of computing. Happened before with Java. Happened before with PHP. It will happen again. It even happened in Python, too. I personally attribute a whole generation of failure for the Linux Desktop to the "Python for Desktop" frenzy of the Gnome 2/KDE 4 times. I remember I had a dual-boot Pentium 4 box, and while Windows apps were always slick and responsive, Linux always felt sluggish and unresponsive, until I found C/C++ alternatives to all the apps I used.

loftyal 9y ago
Could you give me some examples of "Computer Science has had "had tools for the right jobs"". Thanks
- mattgreenrocks 9y ago
  SQL comes to mind here.
  - guhcampos 9y ago
    SQL is a good one. Fortran is another. ASIC's, GPU's. When generic is not good enough, we create specific solutions. Javascript is itself an example: it solves very well the problem of giving web pages interactivity. It was not designed to be a general purpose language though - it was, and is - being worked around into one.
geofft 9y ago
Speaking as a developer who primarily writes Python and secondarily C, Rust, C++, bash, and others as necessary, who has in fact worked on a large-scale C++ UI project in Qt on the Linux desktop running alongside PyGTK UIs, and who doesn't actively write JavaScript, I have to say that JavaScript is a really good choice of language, especially for UI, because it has a strong bias towards event-based programming and callbacks instead of blocking code and threads. If you're going to pick the right tool for the job of UI, I'd put JS a bit ahead of Rust (because of immaturity; that is likely to change real soon), which I'd put a lot ahead of C++ (because you're going to screw up threading) a little bit ahead of C and Python (because you're definitely going to screw up threading). If you're interested in rapid prototyping, I'd move Python up several notches - but not past JS, which is what I reach for these days for throwaway prototypes if I think I know enough JS to pull it off. (If someone has a high-quality way to use asyncio or Twisted with the Qt event loop, I'd probably bump Python a bit higher.)
- dijit 9y ago
  The point is that we unnecessarily focus on developer comfort in writing software, but software needs to be optimised first and foremost for runtime. In fact I'd put the priority as such: Priority #1: Runtime, your code will (hopefully) be run a lot more than it does anything else. Priority #2: Debug, your code will be debugged more than it is read Priority #3: Reading, you will probably read your code a significant amount more than you write code. Priority #4: Writing. A software should spend the least amount of time on a CPU being written. I'm not saying that you should only focus on making fast/slick runtimes that are easily debuggable above literally everything else; but you should absolutely have slanted priorities towards this goal. And in that respect, why wouldn't you learn the right tool for the job?
  - JoeAltmaier 9y ago
    Most code, #1 is irrelevant. Most code isn't in the inner loop of performance-limiting execution. Given that, what makes sense to optimize for? The slowest, most error-prone processor in the mix is, the wetware in your head. So, almost all of the time, put #1 at the bottom of the list. Put #3 next, because once it works, the slowest process is relearning why it works, necessary to debug or extend it. #2 and #4 are simultaneous. So, for most coding most of the time on most projects, write dead-obvious code using normal design patterns and simplest abstractions. Because time is money, and your wetware time is millions of times more expensive than cpu time.
    - flukus 9y ago
      > Most code, #1 is irrelevant. Most code isn't in the inner loop of performance-limiting execution. Just because your code isn't in a tight loop doesn't mean you shouldn't think about performance. If you waste CPU resources then the rest of the system that is in a tight loop will have more switches to do. If you waste memory then the code in the tight loop will have memory evicted from it's precious memory cache. Just because your process is not CPU bound does not mean you aren't having an impact on overall system performance. If you're running your own servers do whatever you want, but if you're making consumer software then don't pretend you're software is the only thing running.
cheez 9y ago
Why are JavaScript programmers even relevant? Do they, as a group, have some desirable skill other than "will code for food"? At least successful C++ programmers HAVE to be decent-ish. The language is unforgiving.
- chrisza4 9y ago
  They produce software. Some of those software are used. That is enough. Skill to surpass unforgiving territory is not as important as result.
- zepolen 9y ago
  Dynamic languages are way more unforgiving than static languages.
- geofft 9y ago
  You're of course welcome to your opinions, but I strongly suspect that you need more experience as a developer to understand the answer to your question, if you don't have a sense of what things are demanding in JS and if you think that being able to write C++ is clearing some sort of high bar.
  - cheez 9y ago
    I write code using JavaScript and C++ on a daily basis. I would hire a successful C++ dev over a successful JavaScript dev for cross-platform work. There are too many issues.
symlinkk 9y ago
People like you hate the idea of using JavaScript to write desktop apps because you feel like the end result is too slow and inefficient. Web developers hate the idea of using C++ to write desktop apps because the language is brittle, outdated, and overly complex. We need a middle ground: a language with the syntax of a scripting language, like Python or JavaScript, that compiles down to native code, like C++ or Rust. I am under the impression that Qt is attempting this with QML and JavaScript.
- earenndil 9y ago
  Nim[0]? Ante[1]? Perhaps even D, although that's pushing it. 0: https://nim-lang.org/ https://nim-lang.org/ 1: https://github.com/jfecher/ante https://github.com/jfecher/ante
- guhcampos 9y ago
  Rust might eventually get to that point, and C++ itself with QT is relatively easy if you stick to the basics. But in a way, anything trying to please both higher level and lower level developers is going to have to settle for some kind of middle ground. The best situation I can think right now, and the one I would adopt myself, is indeed PyQt. Mostly because Python makes it easy to drop the compute-heavy application code into C extensions, not because of the GUI toolkit itself.
  - notRUSTY 9y ago
    Rust has been harder for me to pickup than C++. I want to like it. The problem is that the one character symbolic syntax notation remain nonsensical and seem arbitrary to me.
    - yorwba 9y ago
      What exactly do you mean by "one character symbolic syntax notation"? I can't think of anything in Rust matching that description that doesn't exist in C++ as well.
      - 9y ago
pfranz 9y ago
Which is unfortunate, because most apps don't have a lot of business logic to them. Most time is spent learning the interface and libraries...it might as well be a different language or something better suited to task at hand. For a crud app I'd generally grab for Qt, for a multimedia app or game I'd grab for SDL. I guess with something like React there's even more overlap in UI and application flow, but you still have to learn interacting with the filesystem, dialogs, preferences, menus, menu icons and window settings, state between launches, and any other fiddly things that your app brushes up against. There's also building and packaging, bundling for the app store (if you're using one), and updating the app.
rtpg 9y ago
For GUIs in particular the problem is far from solved in the sense you've mentioned. If you write your program in C/C++ we're good, though now you're using a clunkly language. If you're using Java you have some decent GUI options, but it's a bit ugly. Still alright. In almost any other languages you're in deep trouble. The prototypical example: building out interfaces in Python. You have some GUI bindings to the cross platform libs, but many have really old and outdated docs. Or licensing issues. Or installation issues. It's super hard to ship a GUI for your Python app compared to anything else with the language Ultimately almost all other languages are used for server software. Packaging and GUIs are super low on the list of priorities. The only exception to this is JavaScript! JavaScript is so much about front-end stuff that legitimate effort is put into getting stuff working well and painlessly. Sure React didn't invent FRP, but the communities gone further with the concepts than any other community. Bar none. So many people refuse to admit it, but the JavaScript community is the state of the art in GUI development. The biggest crutch bring the weak native support of course.
fnl 9y ago
Those JS ninjas could just go with QML and JS. Shouldn't be any difficult for them. And much leaner and more efficient than an Electron app, too. http://doc.qt.io/qt-5/qtqml-javascript-expressions.html http://doc.qt.io/qt-5/qtqml-javascript-expressions.html
toyg 9y ago
> Python for Desktop frenzy Wat? The PyKDE binding were always an afterthought. The big KDE4 language bet was, guess what... javascript bindings, to build widgets. And then Ruby bindings, since Ruby had just exploded. Except web developers never cared for the Linux desktop, they are Mac users. If anything, python bindings allowed a generation of new distros like Mint to emerge, as “sysadmin types” could develop simple GUIs much faster and cheaper than if they had been forced to learn C/C++. The failure of established companies to capitalise on this is entirely their fault; for example Maemo/Meego refused to let Python apps on the Nokia store, and never even tried to push PyQt as their mobile story (which would have predated the Swift/Kotlin moves by almost a decade, giving them a fighting chance to get some developer mindshare).

loftyal 9y ago

Could you give me some examples of "Computer Science has had "had tools for the right jobs"". Thanks

mattgreenrocks 9y ago
SQL comes to mind here.
- guhcampos 9y ago
  SQL is a good one. Fortran is another. ASIC's, GPU's. When generic is not good enough, we create specific solutions. Javascript is itself an example: it solves very well the problem of giving web pages interactivity. It was not designed to be a general purpose language though - it was, and is - being worked around into one.

geofft 9y ago

Speaking as a developer who primarily writes Python and secondarily C, Rust, C++, bash, and others as necessary, who has in fact worked on a large-scale C++ UI project in Qt on the Linux desktop running alongside PyGTK UIs, and who doesn't actively write JavaScript, I have to say that JavaScript is a really good choice of language, especially for UI, because it has a strong bias towards event-based programming and callbacks instead of blocking code and threads. If you're going to pick the right tool for the job of UI, I'd put JS a bit ahead of Rust (because of immaturity; that is likely to change real soon), which I'd put a lot ahead of C++ (because you're going to screw up threading) a little bit ahead of C and Python (because you're definitely going to screw up threading). If you're interested in rapid prototyping, I'd move Python up several notches - but not past JS, which is what I reach for these days for throwaway prototypes if I think I know enough JS to pull it off. (If someone has a high-quality way to use asyncio or Twisted with the Qt event loop, I'd probably bump Python a bit higher.)

dijit 9y ago
The point is that we unnecessarily focus on developer comfort in writing software, but software needs to be optimised first and foremost for runtime. In fact I'd put the priority as such: Priority #1: Runtime, your code will (hopefully) be run a lot more than it does anything else. Priority #2: Debug, your code will be debugged more than it is read Priority #3: Reading, you will probably read your code a significant amount more than you write code. Priority #4: Writing. A software should spend the least amount of time on a CPU being written. I'm not saying that you should only focus on making fast/slick runtimes that are easily debuggable above literally everything else; but you should absolutely have slanted priorities towards this goal. And in that respect, why wouldn't you learn the right tool for the job?
- JoeAltmaier 9y ago
  Most code, #1 is irrelevant. Most code isn't in the inner loop of performance-limiting execution. Given that, what makes sense to optimize for? The slowest, most error-prone processor in the mix is, the wetware in your head. So, almost all of the time, put #1 at the bottom of the list. Put #3 next, because once it works, the slowest process is relearning why it works, necessary to debug or extend it. #2 and #4 are simultaneous. So, for most coding most of the time on most projects, write dead-obvious code using normal design patterns and simplest abstractions. Because time is money, and your wetware time is millions of times more expensive than cpu time.
  - flukus 9y ago
    > Most code, #1 is irrelevant. Most code isn't in the inner loop of performance-limiting execution. Just because your code isn't in a tight loop doesn't mean you shouldn't think about performance. If you waste CPU resources then the rest of the system that is in a tight loop will have more switches to do. If you waste memory then the code in the tight loop will have memory evicted from it's precious memory cache. Just because your process is not CPU bound does not mean you aren't having an impact on overall system performance. If you're running your own servers do whatever you want, but if you're making consumer software then don't pretend you're software is the only thing running.

cheez 9y ago

Why are JavaScript programmers even relevant? Do they, as a group, have some desirable skill other than "will code for food"? At least successful C++ programmers HAVE to be decent-ish. The language is unforgiving.

chrisza4 9y ago
They produce software. Some of those software are used. That is enough. Skill to surpass unforgiving territory is not as important as result.
zepolen 9y ago
Dynamic languages are way more unforgiving than static languages.
geofft 9y ago
You're of course welcome to your opinions, but I strongly suspect that you need more experience as a developer to understand the answer to your question, if you don't have a sense of what things are demanding in JS and if you think that being able to write C++ is clearing some sort of high bar.
- cheez 9y ago
  I write code using JavaScript and C++ on a daily basis. I would hire a successful C++ dev over a successful JavaScript dev for cross-platform work. There are too many issues.

symlinkk 9y ago

People like you hate the idea of using JavaScript to write desktop apps because you feel like the end result is too slow and inefficient. Web developers hate the idea of using C++ to write desktop apps because the language is brittle, outdated, and overly complex. We need a middle ground: a language with the syntax of a scripting language, like Python or JavaScript, that compiles down to native code, like C++ or Rust. I am under the impression that Qt is attempting this with QML and JavaScript.

earenndil 9y ago
Nim[0]? Ante[1]? Perhaps even D, although that's pushing it. 0: https://nim-lang.org/ https://nim-lang.org/ 1: https://github.com/jfecher/ante https://github.com/jfecher/ante
guhcampos 9y ago
Rust might eventually get to that point, and C++ itself with QT is relatively easy if you stick to the basics. But in a way, anything trying to please both higher level and lower level developers is going to have to settle for some kind of middle ground. The best situation I can think right now, and the one I would adopt myself, is indeed PyQt. Mostly because Python makes it easy to drop the compute-heavy application code into C extensions, not because of the GUI toolkit itself.
- notRUSTY 9y ago
  Rust has been harder for me to pickup than C++. I want to like it. The problem is that the one character symbolic syntax notation remain nonsensical and seem arbitrary to me.
  - yorwba 9y ago
    What exactly do you mean by "one character symbolic syntax notation"? I can't think of anything in Rust matching that description that doesn't exist in C++ as well.
    - 9y ago

pfranz 9y ago

Which is unfortunate, because most apps don't have a lot of business logic to them. Most time is spent learning the interface and libraries...it might as well be a different language or something better suited to task at hand. For a crud app I'd generally grab for Qt, for a multimedia app or game I'd grab for SDL. I guess with something like React there's even more overlap in UI and application flow, but you still have to learn interacting with the filesystem, dialogs, preferences, menus, menu icons and window settings, state between launches, and any other fiddly things that your app brushes up against. There's also building and packaging, bundling for the app store (if you're using one), and updating the app.

rtpg 9y ago

For GUIs in particular the problem is far from solved in the sense you've mentioned. If you write your program in C/C++ we're good, though now you're using a clunkly language. If you're using Java you have some decent GUI options, but it's a bit ugly. Still alright. In almost any other languages you're in deep trouble. The prototypical example: building out interfaces in Python. You have some GUI bindings to the cross platform libs, but many have really old and outdated docs. Or licensing issues. Or installation issues. It's super hard to ship a GUI for your Python app compared to anything else with the language Ultimately almost all other languages are used for server software. Packaging and GUIs are super low on the list of priorities. The only exception to this is JavaScript! JavaScript is so much about front-end stuff that legitimate effort is put into getting stuff working well and painlessly. Sure React didn't invent FRP, but the communities gone further with the concepts than any other community. Bar none. So many people refuse to admit it, but the JavaScript community is the state of the art in GUI development. The biggest crutch bring the weak native support of course.

fnl 9y ago

Those JS ninjas could just go with QML and JS. Shouldn't be any difficult for them. And much leaner and more efficient than an Electron app, too. http://doc.qt.io/qt-5/qtqml-javascript-expressions.html http://doc.qt.io/qt-5/qtqml-javascript-expressions.html

toyg 9y ago

> Python for Desktop frenzy Wat? The PyKDE binding were always an afterthought. The big KDE4 language bet was, guess what... javascript bindings, to build widgets. And then Ruby bindings, since Ruby had just exploded. Except web developers never cared for the Linux desktop, they are Mac users. If anything, python bindings allowed a generation of new distros like Mint to emerge, as “sysadmin types” could develop simple GUIs much faster and cheaper than if they had been forced to learn C/C++. The failure of established companies to capitalise on this is entirely their fault; for example Maemo/Meego refused to let Python apps on the Nokia store, and never even tried to push PyQt as their mobile story (which would have predated the Swift/Kotlin moves by almost a decade, giving them a fighting chance to get some developer mindshare).