Hacker News Reader

Comment by haecceity | Hacker News Reader

How do you know those language bindings wouldn't exist if GTK+ used C++?

because none of them exist for qt, or fltk

This is arguably false; for instance, Qt has official first-party bindings for Python. It's just that the tools Qt has make them not that necessary. Qt has not one but 2 fully functional IDEs (QtCreator and KDevelop) and good designer tools that lower a lot the complexity of writing a GUI. QtQuick is also very nice.

Gnome has what? Anjuta? Glade was nice but it didn't avoid you the hassle of using GObject. I think Vala is a clear proof of what I'm trying to say. They knew the shortcomings of their system, and how difficult it was to use, so they basically wrote a language that hid the complexity of GObject under a thick layer of nicer syntax. It was also a way to discourage people from using C# and Gtk#...

sure, there are a lot of good qt tools, but they by and large tether you to c++. people would love to have good qt bindings for whatever language the rest of their project is in, but the fact that qt is implemented in c++ makes it hard.

No, it does not. The world is full of scriptable C++ programs and C++ libraries with dozens of language bindings. As I wrote before LLVM, perhaps the most important compiler toolkit out there, is completely written in C++ and almost every language out there has bindings to call into it.

If Qt is hard to interface with, it's not because of C++, it's because of Qt. Also, Gtk+ is quite hard to interface with to begin with, given how much it relies on GLib/GObject and how weird it is to use it. That's I think the #1 reason GTK has so many bindings, RAD would be simply not feasible otherwise.

Reply on news.ycombinator.com