Hacker News Reader

Comment by guhcampos | Hacker News Reader

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.

View on HN

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.)

I agree with you. I can't think of a better language for writing GUI then Javascript right now, in particular because it has so many great toolkits and widget libraries.

But what makes those apps resource hungry and sluggish is usually not the UI: it's the whole lot of applicationg logic that's buried into their cores using Javascript code for stuff the language was not designed for.

I'm primarly a Python developer too, and on that respect I like Python's approach to C extensions. It's easy enough to rewrite your application logic into C when performance is important, and in general I think experienced Python programmers will do just that. The problem with Electron is both the lack of support for doing this, and the lack of experienced developers willing to do it.

Yes - and even when I was working on the Qt apps, I really wanted a shared non-Qt and preferably non-C++ library for application logic that was nicely portable between Qt on desktop, Python for the spots where we needed it, and Android (Java) and iOS (Objective-C).

I am reasonably excited about WebAssembly as a solution for this for web apps. (Although web apps also have a natural front-end/back-end separation, and people consider JS as just one of many potential options for a back-end language, which helps a lot here.) It does surprise me that there isn't good support for doing this with actual native code on Electron.

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?

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.

> 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.

#2 and #4 are not simultaneous. Writing that really clever function that's difficult to read has happened to us all, in fact in ops there is the notion of "write-only scripts", such as intricate one liners or regex's.

We should write code that's idiomatic and clear if we want easy debugging.

Your other point about "wetware is more expensive" is a statement about how much you're scaling. Another 100ms on facebooks home page load is an aggregate of at least a dozen hours a day taken from users, so if it costs a developer a dozen hours to remove that performance hit then it's absolutely worth it.

Performance should be the default, not the edge case.

> The point is that we unnecessarily focus on developer comfort in writing software, but software needs to be optimised first and foremost for runtime.

My argument is about runtime, not about developer comfort - if you have race conditions between threads, or deadlocks, or blocking I/O on the UI thread, that's a runtime problem, not a developer comfort problem.

(I do also disagree with your priorities, in part because if you get #4 right you avoid a lot of #2, but I wanted to be clear about what my argument is.)

finally someone who understands JS while most other devs trying JS dont know events, have a hard time understanding async and complain about lack of threads - in JS you can spawn worker process's but that wont help if you dont understand events/async. everything in JS is event based eg button.onclick and while it might feel old you can never abstract that away as the cpu uses interups that is basically events. that is how computers and the real word works. for example if a coworker comes into your office thats an interupt. you have a routine/function for it and tells him to fuck off. but at the same time your manager comes in. that is the nature of async. and you might have an edge case you did not think about.

> 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

I've experimented around with Quamash[1] a bit with Asyncio and it seems to work nicely! Looking at CI it seems to have some rough edges (at least on Windows) though.

https://github.com/harvimt/quamash

You don’t have to use Qt’s event loop: you can just call app.processEvents() when it suits you.

Sure, but if you don't have events of your own to process, either you're constantly calling processEvents() and spinning the CPU, or you're in a loop that does so every second, which is both high-latency and inefficient (and bad for battery life). You generally want to process an event when it suits the event, not when it suits you :-)

It looks like this is done by subclassing QAbstractEventDispatcher and filling out virtual functions registerSocketNotifier(), registerTimer(), etc. I suppose you could do this for asyncio/Twisted, but I'd prefer to import something where someone has done this for me and is accepting bug reports from the community, because this is the sort of thing that's made of edge cases that are hard to notice in testing.

I've used variations of qt4reactor (https://pypi.python.org/pypi/qt4reactor/1.6) to integrate Twisted with PyQt apps. It usually works pretty well for desktop apps (I used it to create an ssh tunnel using twisted conch for a desktop database visualization too).

That would be Visual Basic, Delphi, Smalltalk, Hypercard.

> 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).

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.

Well, we have Vala. It compiles to C just like Nim and it's used for GUIs, although it's Gtk specific and some would argue it's not a programing language:

https://blogs.gnome.org/despinosa/2017/02/14/vala-is-not-a-p...

Nim[0]? Ante[1]? Perhaps even D, although that's pushing it.

0: https://nim-lang.org/

1: https://github.com/jfecher/ante

Lua?

Its fairly fast, easy to link out to C if you need to. There are versions of the VM that are blisteringly fast, like Luajit, and others that are tiny like eLua.

Its syntax is incredibly easy, as is most of the language to understand.

It can be event and callback oriented.

And though dynamic, most gotchas about JS don't apply, as it isn't overly eager to typecast everything.

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.

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.

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.

I'm guessing its this:

https://github.com/rust-lang/rust-wiki-backup/blob/master/Si... ->

> (eg &'a T)

If you look at the popular web development languages, they don't really have sigils. Javascript/Flow/Typescript/Coffeescript (front end). Java, C#, Python, PHP (ok, I'll grant you $). Ruby is a bit of an oddball and I guess it's part of the reason Python is overtaking it.

Basically, unless you've been working in C/C++, you've never really used funky symbols to denote "modifiers".

Say what you will, but

> public static void main

is easier to Google and even to parse for most people.

Keep in mind that the vaaaaaast majority of devs today have never worked professionally in C/C++. I'd imagine some of them have never even touched it, even as a hobby.

The comment I was responding to was explicitly comparing it to C++, which is what confused me.

Oh, right.

You should probably try D then. It's easy to pick up and very powerful once you learn most of the language features.

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

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.

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

SQL comes to mind here.

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.

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.

Reply on news.ycombinator.com