[exDM69]

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

[maigret]

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

[exDM69]

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-AL]

Not always. See boost python.

[exDM69]

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.