4 ms·

Using Qt bindings sucks big time though. That's effectively still writing C++ code. You might as well stop pretending and write actual C++ code so you can limit

Using Qt bindings sucks big time though. That's effectively still writing C++ code. You might as well stop pretending and write actual C++ code so you can limit yourself to having to deal with C++'s idiosyncrasies instead of those, plus the ones introduced by a second language, plus the ones introduced by a bindings layer. It's unfortunate that a UI layer ties you into a particular programming language. It feels like something that should be provided by the OS somehow.

OvbiousError 2y ago
Don't know about other languages but the python bindings are pretty ok to use imo. You can also stay in qml longer than you'd think, especially with all the tooling kde provides.
lolinder 2y ago
> It feels like something that should be provided by the OS somehow. The OS is also written in a language and its idiosyncrasies sometimes do show through in system calls. From what you're saying it sounds like the problem is less that Qt is not part of the OS than that the Qt API wasn't designed with interop at all in mind. A well-designed API can live outside of the OS and vice versa.
samatman 2y ago
The way forward for something like that is for operating systems to start defining their interface in terms of ABI. That would be a major shift in mentality, and there are reasons why this has become less common over time, rather than more so. But it seems to me that the balance has shifted, and this is becoming a better idea than it was. Specifically, Unix, and therefore Posix, benefited greatly from being implemented in a high-level language (meaning: not assembly). It was a time of many architectures, with more invented all the time, and someone could write a backend for cc and bootstrap a whole OS. But architectures are consolidating, and programming languages are proliferating. But the de-facto C ABI for any given platform remains the lingua franca, and it's a fairly impoverished way to communicate. It's an intriguing prospect to develop a more sophisticated common language for object code. Different languages have different needs, that won't change, but I see a lot of room to develop something more full-featured, that would allow an OS to provide a UI layer without tying itself up in the details of C++ or Objective C. Who knows, maybe Zig can lead the way on that, when the time's right.
- john01dav 2y ago
  What specific features would you like to see in such a lingua franca ABI replacement? I'm struggling to think of anything that's similiar enough across all languages to be relevant. Furthermore, many similiar concepts are implemented completely differently in different languages even if they look very similar to the programmer.
  - samatman 2y ago
    > Furthermore, many similar concepts are implemented completely differently in different languages even if they look very similar to the programmer. This is true to some degree, yes. But all those languages manage to speak C ABI through some sort of extern directive or other. I don't believe that's because the de-facto C ABI for any given platform is the optimal common language, but rather, it's the only thing we can rely upon. I'm not a compiler engineer, just an interested amateur, so any detailed proposal I could offer would be painfully naïve. Getting good results would involve attracting the interest and talent of skilled professionals. I'll start by noting that I'm not proposing a Common Object Model which all languages are expected to target. It's been tried, there's prior art, such a format might even be adequate, but: that's a lot of work, the result is sure to be unsatisfactory, and, most important, language core teams aren't going to do this. The idea here is a better interface, for code which is expected to speak to other code. It might be productive to think of it like protobufs for function calls. Libraries could compile in metadata in a binary format, defining the necessary structure of the stack, and the register discipline, for calling into a particular function. This would require some ability to talk about aggregates, to be able to cover constructs like vtables (where the function pointers themselves would define a binary prototype included with the library). This would include a plain-text intermediate format representing the same data, to make life easier on everyone, but it would nonetheless be possible to link against a version of a system library directly, by extracting this definition language from the object code. This reduces the problem space, from having to find a common object format acceptable to every language, to providing a more enriched surface area which languages could publish for the API of library code. A large part of what makes the de-facto C ABI so sticky is that object code is flying blind: I keep emphasizing de-facto because the ABI is a matter of convention, and there's no good way to vary that convention and also let a linker know that you have. I'm optimistic that something along these lines could be designed, such that systems languages could both produce and consume this format, with managed languages consuming it using the standard FFI adaptation technique. It's likely it would be an improvement on the status quo, where everyone just does what the nearest C compiler does, and hopes not to step on one another's toes in the process.
Someone 2y ago
> It's unfortunate that a UI layer ties you into a particular programming language I think it is unavoidable that it ties you to a programming language paradigm. For example, it may assume the existence of booleans, reference counting, garbage collection or of multiple inheritance. If your preferred language doesn’t support them, that will make the bindings look uglier than needed. Conversely, if your preferred language supports them, but the API of the UI layer doesn’t, the bindings will look cumbersome in places where using those features looks natural. So, what you end up with is either plain C (ugly for everybody, including C programmers, even they may not want to admit it), C++ or the JVM, or something like it that looks fine for C respectively C++ respectively Java programmers but feels strange in some degree to others, the more so the less their language ‘feels’ like C respectively C++ respectively Java, or COM/SOM/CORBA, which claim to be language agnostic, but don’t do that for the feel of an API.
tormeh 2y ago
What about QML?
pjmlp 2y ago
It is, but that is what many don't seem to want to learn nowadays and package Chrome instead. All desktop OS, and mobile OSes, designed top to bottom, not like a UNIX puzzle, do provide their UI frameworks in the box. Naturally, tied to the programming languages officially supported by the OS SDK.

OvbiousError 2y ago

Don't know about other languages but the python bindings are pretty ok to use imo. You can also stay in qml longer than you'd think, especially with all the tooling kde provides.

lolinder 2y ago

> It feels like something that should be provided by the OS somehow. The OS is also written in a language and its idiosyncrasies sometimes do show through in system calls. From what you're saying it sounds like the problem is less that Qt is not part of the OS than that the Qt API wasn't designed with interop at all in mind. A well-designed API can live outside of the OS and vice versa.

samatman 2y ago

The way forward for something like that is for operating systems to start defining their interface in terms of ABI. That would be a major shift in mentality, and there are reasons why this has become less common over time, rather than more so. But it seems to me that the balance has shifted, and this is becoming a better idea than it was. Specifically, Unix, and therefore Posix, benefited greatly from being implemented in a high-level language (meaning: not assembly). It was a time of many architectures, with more invented all the time, and someone could write a backend for cc and bootstrap a whole OS. But architectures are consolidating, and programming languages are proliferating. But the de-facto C ABI for any given platform remains the lingua franca, and it's a fairly impoverished way to communicate. It's an intriguing prospect to develop a more sophisticated common language for object code. Different languages have different needs, that won't change, but I see a lot of room to develop something more full-featured, that would allow an OS to provide a UI layer without tying itself up in the details of C++ or Objective C. Who knows, maybe Zig can lead the way on that, when the time's right.

john01dav 2y ago
What specific features would you like to see in such a lingua franca ABI replacement? I'm struggling to think of anything that's similiar enough across all languages to be relevant. Furthermore, many similiar concepts are implemented completely differently in different languages even if they look very similar to the programmer.
- samatman 2y ago
  > Furthermore, many similar concepts are implemented completely differently in different languages even if they look very similar to the programmer. This is true to some degree, yes. But all those languages manage to speak C ABI through some sort of extern directive or other. I don't believe that's because the de-facto C ABI for any given platform is the optimal common language, but rather, it's the only thing we can rely upon. I'm not a compiler engineer, just an interested amateur, so any detailed proposal I could offer would be painfully naïve. Getting good results would involve attracting the interest and talent of skilled professionals. I'll start by noting that I'm not proposing a Common Object Model which all languages are expected to target. It's been tried, there's prior art, such a format might even be adequate, but: that's a lot of work, the result is sure to be unsatisfactory, and, most important, language core teams aren't going to do this. The idea here is a better interface, for code which is expected to speak to other code. It might be productive to think of it like protobufs for function calls. Libraries could compile in metadata in a binary format, defining the necessary structure of the stack, and the register discipline, for calling into a particular function. This would require some ability to talk about aggregates, to be able to cover constructs like vtables (where the function pointers themselves would define a binary prototype included with the library). This would include a plain-text intermediate format representing the same data, to make life easier on everyone, but it would nonetheless be possible to link against a version of a system library directly, by extracting this definition language from the object code. This reduces the problem space, from having to find a common object format acceptable to every language, to providing a more enriched surface area which languages could publish for the API of library code. A large part of what makes the de-facto C ABI so sticky is that object code is flying blind: I keep emphasizing de-facto because the ABI is a matter of convention, and there's no good way to vary that convention and also let a linker know that you have. I'm optimistic that something along these lines could be designed, such that systems languages could both produce and consume this format, with managed languages consuming it using the standard FFI adaptation technique. It's likely it would be an improvement on the status quo, where everyone just does what the nearest C compiler does, and hopes not to step on one another's toes in the process.

Someone 2y ago

> It's unfortunate that a UI layer ties you into a particular programming language I think it is unavoidable that it ties you to a programming language paradigm. For example, it may assume the existence of booleans, reference counting, garbage collection or of multiple inheritance. If your preferred language doesn’t support them, that will make the bindings look uglier than needed. Conversely, if your preferred language supports them, but the API of the UI layer doesn’t, the bindings will look cumbersome in places where using those features looks natural. So, what you end up with is either plain C (ugly for everybody, including C programmers, even they may not want to admit it), C++ or the JVM, or something like it that looks fine for C respectively C++ respectively Java programmers but feels strange in some degree to others, the more so the less their language ‘feels’ like C respectively C++ respectively Java, or COM/SOM/CORBA, which claim to be language agnostic, but don’t do that for the feel of an API.

tormeh 2y ago

What about QML?

pjmlp 2y ago

It is, but that is what many don't seem to want to learn nowadays and package Chrome instead. All desktop OS, and mobile OSes, designed top to bottom, not like a UNIX puzzle, do provide their UI frameworks in the box. Naturally, tied to the programming languages officially supported by the OS SDK.