Mark Shuttleworth on the future of Ubuntu
Posted Jun 5, 2008 8:52 UTC (Thu) by kripkenstein
In reply to: Mark Shuttleworth on the future of Ubuntu
Parent article: Mark Shuttleworth on the future of Ubuntu
Actually my point was that the existence of Vala is an indication that
Gnome at least has deeper ties to Mono and C# than for example to Qt and
C++ for some non-technical reason which is not obvious to me.
Actually this implies the opposite to me. The only similarity between Vala and Mono/C# is some of the syntax, and that's it (and while C# is a main source of inspiration for the syntax, so is Java, etc.). Vala doesn't use the Mono VM (or any VM), it doesn't use the .Net class library, and it's syntax is first and foremost meant to implement GObject conveniently.
Also, if GNOME really liked Mono, it wouldn't bother with Vala. In fact Vala might seem at first antagonistic to Mono, which is why the Vala FAQ goes to great efforts to clarify that it's goal is not to duel with Mono.
(a) the generated code basically
becomes unreadable by mere mortals, so using vala parts in C projects (and
vince versa) is much harder than necessary
No, you should *never* need to look at the generated code (just as you don't look at generated assembler by GCC). When integrating Vala and C/GObject, you should have the files describing the API (.vapi, etc.), which describe the GObject overview, and are very clear and human-readable. You would use them. In fact one main goal of Vala, if not *the* goal, is to facilitate such convenient interoperability between Vala and C/GObject, e.g., writing libraries in Vala that are used by C/GObject, etc.
(b) what happens if the
underlying C libraries (gtk, say) change their interfaces or even just the
semantics? Then the vala to c translator always produces incorrect code
which you can only fix by hacking the translator. this problem won't occur
if the toolkit is used directly from within the language it is written in.
Well, if the interfaces change a little then the bindings for Vala need to change as well (the same goes for PyGTK). Note that you don't need to change the Vala compiler in this case, just the .vapi files that describe the language bindings. I guess in theory a more 'deep' change to GTK might necessitate changing the compiler - by a 'deep' change I mean one in which the semantics of GObject itself change - however, in that case you'd need to change C/GObject programs using GTK as well.
(d) to my knowledge it is very
difficult to use debuggers such as gdb using vala's aproach since you
would have to wade through the generated C code (on the other hand real
programmers don't need debuggers anyway ;).
I agree with you, this is a very valid concern, it's a disadvantage of the approach. Perhaps in theory you might insert debug information that makes it better, but it'll never be quite as smooth as it should be. (And even debugging in C is cumbersome compared to debugging a VM-ed language like Python or Java.)
On the Qt/C++ side of the fence there has been (semi) automatic memory
management by means of the Q*Pointer and various Container classes for an
eternity (read: Qt 2.0), it has a nice foreach statement since 4.2 (IIRC),
always had a very nice event notification mechanism and so on. Also you
can use any C or C++ library out there without too much of a hassle. For
all these reasons vala seems to be redundant from a technology perspective
Ok, I am not up-to-date on the specifics of Qt, it seems. It sounds better than I thought. That said, it still isn't a good fit for GNOME, since it doesn't natively support the GObject system in its syntax, which is the whole purpose of Vala. Also, it's licensing is very different from the GNOME approach.
to post comments)