undefined | Better HN

0 pointssparkie13y ago0 comments

Probably worth adding that Qt being C++ is itself a problem - as it makes it inaccessible to the majority of programmers, due to the lack of ABI compatibility with C++ and any other languages. Gtk+ on the other hand, is almost universally accessible, because any language worth using can bind C APIs.

Of course, the downside here is that all the Gtk+ bindings to other languages are based on the Gtk+2 API. Gtk+3 hasn't gained much popular support.

0 comments

exDM6913y ago

> Probably worth adding that Qt being C++ is itself a problem

Yep. C++ is what I call a "dead end" language. If you write your code in C++, it will be only usable from C++. If you want to use it from Python, Ruby or whatever, you'll need a C shim in between. If it were written in C, you could use ctypes and other similar means to do FFI quickly.

Unfortunately, most languages other than C are more or less a dead end.

maigret13y ago

> Unfortunately, most languages other than C are more or less a dead end.

Except for Java, where you can reuse code directly with JVM-compiling stacks like Clojure.

exDM6913y ago

Well that is arguable. If you stay within JVM, you can use your Java code from other languages like Clojure and Scala. To some extent you can use Scala and Clojure code from Java. But you can't really use Java code from Python or Ruby unless you work with Jython or JRuby.

So, I'd put Java in the "dead end language" bin. You can use C code from Java (via JNI) but it's not practical to do it the other way.

UK-AL13y ago

Not always. See boost python.

exDM6913y ago

I'm aware of that. But it's essentially a shim layer, albeit one that is semi-automatically generated. The preferred way of doing Python FFI is to use ctypes inside Python, not write (or generate) C or C++ code that works as the shim.

That's the way many languages prefer to do their FFI, write "foreign" declarations in the language itself, not in C++ land. E.g. in Haskell, you can call C with very little effort. When dealing with C++ you have to get along with ABI issues and things get a lot harder.

rdale13y ago

If writing language bindings for Qt based C++ apis is harder than writing language bindings for GTK C based apis, how come there are at least as many high quality language bindings for Qt as there are for GTK?

Just because an api is C based doesn't make language bindings 'happen automagically', otherwise Gnome wouldn't need the GObject Introspection project. KDE has a similar project called 'Smoke' and some language bindings based on that.

There are different technical challenges to writing bindings for a C++ based api as opposed to a C based api, but it is just not true to say that one is better than another in my opinion. This is based on my experience doing a lot of work on Qt C++ language bindings, and a project using GObject Introspection.

j / k navigate · click thread line to collapse

0 comments

exDM6913y ago

> Probably worth adding that Qt being C++ is itself a problem

Unfortunately, most languages other than C are more or less a dead end.

maigret13y ago

> Unfortunately, most languages other than C are more or less a dead end.

Except for Java, where you can reuse code directly with JVM-compiling stacks like Clojure.

exDM6913y ago

So, I'd put Java in the "dead end language" bin. You can use C code from Java (via JNI) but it's not practical to do it the other way.

UK-AL13y ago

Not always. See boost python.

exDM6913y ago

rdale13y ago

j / k navigate · click thread line to collapse