| |||||||||||||
Mark Shuttleworth on the future of UbuntuMark Shuttleworth on the future of UbuntuPosted Jun 4, 2008 21:27 UTC (Wed) by and (subscriber, #2883)In reply to: Mark Shuttleworth on the future of Ubuntu by kripkenstein Parent article: Mark Shuttleworth on the future of Ubuntu
This is somewhat off topic, but somehow I don't see the point in Vala. The code sample I've seen on wikipedia looks a lot like Qt, but the approach has the disadvantage that if the generated C code is incorrect you're in deep trouble. Given the fact that Qt recently acquired the ability to use the native GTK style engines and glib's mainloop, why is Gnome not simply starting to adopt Qt apps where it makes sense? IMHO the philosophic differences between Qt and Gnome are much smaller than those between Mono and Gnome...
(Log in to post comments)
Mark Shuttleworth on the future of Ubuntu Posted Jun 5, 2008 5:34 UTC (Thu) by kripkenstein (subscriber, #43281) [Link] I'm not sure what you mean here, perhaps I don't understand your point. I don't see much similarity between Vala and Qt. Vala is C#, but tailored for the GObject system, while Qt is built on top of C++ and has nothing to do with GObject. That is, Vala is a new programming language, with syntax optimized for GObject. It includes things like automatic memory management, nice 'for' loops, and various other things from modern languages like Java/C#/etc. Also I'm not sure what you mean by "if the generated C code is incorrect you're in deep trouble." If the assembly code generated by GCC from your C source is incorrect you're also in deep trouble - don't we always have to trust our compilers?
Mark Shuttleworth on the future of Ubuntu Posted Jun 5, 2008 8:14 UTC (Thu) by and (subscriber, #2883) [Link] 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. My issues with C code generation are that (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 (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. (c) it takes away the strengths of C (i.e. ability for low level programming, bindings to just about any library imaginable) without adding much which C++ doesn't offer and finally (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 ;). 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 to me.
Mark Shuttleworth on the future of Ubuntu Posted Jun 5, 2008 8:52 UTC (Thu) by kripkenstein (subscriber, #43281) [Link] 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 necessaryNo, 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 to me.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.
Mark Shuttleworth on the future of Ubuntu Posted Jun 5, 2008 20:06 UTC (Thu) by and (subscriber, #2883) [Link] > 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. I always thought Gnome was started because Qt/Kde were not considered free enough. given the fact that Qt is GPL and you're can use basically any other FOSS license in conjunction with Qt as long as you keep providing the source, I don't get the point about licensing differences. I think a free desktop should be all about free software and shouldn't worry too much about how much proprietary developers have to pay for a development license. Maybe my original comment was also a bit ambiguous: I didn't argue in favour of Gnome dropping GTK or anything, I just wanted to point out that for Gnome there is not much difference from bundling C#/Mono apps from bundling Qt/C++ apps when it comes to technical considerations (basically both live within their own separate ecosystem).In my opinion gnome should come with a few Qt apps (also KDE should come with a few gtk apps, but that's a different story) if these applications blend sufficiently well into the 'alien' desktop environment...
Mark Shuttleworth on the future of Ubuntu Posted Jun 5, 2008 20:21 UTC (Thu) by kripkenstein (subscriber, #43281) [Link] I always thought Gnome was started because Qt/Kde were not considered free enoughYes, historically GTK was (at least in part) a response to licensing issues with Qt. Most (but not all) of those issues have meanwhile been resolved. given the fact that Qt is GPL and you're can use basically any other FOSS license in conjunction with Qt as long as you keep providing the source, I don't get the point about licensing differences.The problem is that you can't use all the FOSS licenses, you depend on Nokia agreeing to your using them. For example, last I heard the AGPL wasn't permissible (but perhaps this has changed?), and when the GPL4 comes out, there is no guarantee that Qt apps can be written using it. Should Nokia become less cooperative than Trolltech has historically been, this might be very problematic. It's hard to gauge how likely this danger is - probably not very much - but the risk is large enough to cause concern. GNOME/GTK avoid this sort of problem entirely, by licensing the GNOME libraries under the LGPL. I think a free desktop should be all about free software and shouldn't worry too much about how much proprietary developers have to pay for a development license.I tend to agree with this, for the most part, but as I argued above the issue that concerns me is that Qt's licensing has potential risks for FOSS developers. If Nokia legally committed itself to allowing Qt apps to be written in any OSI or FSF-approved license, I would be happy, but that is not the case. In my opinion gnome should come with a few Qt apps (also KDE should come with a few gtk apps, but that's a different story) if these applications blend sufficiently well into the 'alien' desktop environment...Well, I'm in agreement - we should all collaborate as much as possible, when it makes sense. The issue is that (sadly) generally the apps don't blend in seamlessly. But perhaps this will improve in time.
Mark Shuttleworth on the future of Ubuntu Posted Jun 5, 2008 22:48 UTC (Thu) by and (subscriber, #2883) [Link] > The problem is that you can't use all the FOSS licenses, you depend on Nokia agreeing to your using them. For example, last I heard the AGPL wasn't permissible Explicitly listing the AGPL is actually not necessary, since according to http://doc.trolltech.com/main-snapshot/license-gpl-except... Qt is also licensed under GPLv3. In section 13 the GPLv3 states that "you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License". > Should Nokia become less cooperative than Trolltech has historically been, this might be very problematic. this is true for any project which requires copyright assignments: OpenOffice and MySql come to mind. But they can't revoke the licensing of the current version including the GPL exception which means that they can't prevent forks. Also, there is still the QtFreeFoundation (or however it is was called again) which where is effectively controlled by the KDE community (KDE e.v ??) and has the right to release Qt under a BSD license if Trolltech "misbehaves". So, I really don't think there is any danger of losing the toolkit, not even for proprietary applications.
Mark Shuttleworth on the future of Ubuntu Posted Jun 6, 2008 4:57 UTC (Fri) by kripkenstein (subscriber, #43281) [Link] That's good to know about the AGPL, thanks for the information. I don't think copyright assignments is the issue.Should Nokia become less cooperative than Trolltech has historically been, this might be very problematic.this is true for any project which requires copyright assignments: OpenOffice and MySql come to mind. I'm not familiar with MySQL, but OpenOffice is LGPL, not GPL; furthermore, OpenOffice is an app, not a framework like Qt. For both of these reasons I see little or no cause for concern if Sun should change OpenOffice's license to some other FOSS license. That is, if I want to write a plugin for OpenOffice using the GPL4, I will have no problem. A more relevant comparison is GTK, which is a framework like Qt. GTK being LGPL, I have no worries about writing GTK apps in my FOSS license of choice in the future. But they can't revoke the licensing of the current version including the GPL exception which means that they can't prevent forks.The problem is that no fork can add additional licenses, so if e.g. Nokia decides not to allow Qt apps to be written in GPL4, then no forking can help with that. We will be stuck in perpetuity with the last list of licenses Nokia has allowed us to use. Also, there is still the QtFreeFoundation (or however it is was called again) which where is effectively controlled by the KDE community (KDE e.v ??) and has the right to release Qt under a BSD license if Trolltech "misbehaves".This does not solve the problems I've mentioned. Nokia can continue to release Qt regularly while not allowing the GPL4, and Qt will not revert to a BSD license. "Misbehaves", as defined in that agreement, doesn't cover the problems that concern me. (Also, it isn't Trolltech anymore, but Nokia ;) )
Mark Shuttleworth on the future of Ubuntu Posted Jun 6, 2008 15:13 UTC (Fri) by and (subscriber, #2883) [Link]
> I'm not familiar with MySQL, but OpenOffice is LGPL, not GPL;
furthermore, OpenOffice is an app, not a framework like Qt. For both of
these reasons I see little or no cause for concern if Sun should change
OpenOffice's license to some other FOSS license. That is, if I want to
write a plugin for OpenOffice using the GPL4, I will have no problem.
if you are really this much concerned about not being able to use
not-yet-existing OSS licenses and about being able to write proprietary
derivate works without a payment, you really should be using a BSD instead
of the linux kernel: Even if there was desire to switch to GPLv3, linux
is still stuck to the GPL v2 until _every_ contributor agreed on
relicensing or alternatively every single line of code from authors who
haven't agreed is removed.
on the other hand you will always be able to use/fork/remix all versions
of Qt with (A)GPLv(2|3) code and link it to any code which uses one of the
licenses mentioned in Qt's GPL exception. Also if you want to use your
code with a newer license you can still dual-license it.
Mark Shuttleworth on the future of Ubuntu Posted Jun 6, 2008 18:24 UTC (Fri) by kripkenstein (subscriber, #43281) [Link] Actually the Linux kernel is close enough to what I want: I can write userspace apps using any license and run them on the Linux kernel. It's like the LGPL in that respect. That is, only if I want to extend the kernel itself do I have license issues - which is the same situation with GTK+, which is LGPL. In other words, that the Linux kernel stays GPL2 doesn't matter to me, unless I want to extend the kernel itself. Same as with GTK (which is also GPL2 last I checked, and again, it doesn't matter unless I extend GTK itself). This is the reason I prefer GTK and the Linux kernel's approach to licensing over Qt's (for libraries/frameworks, at least. For normal apps, other licenses might be better).
Mark Shuttleworth on the future of Ubuntu Posted Jun 5, 2008 19:23 UTC (Thu) by oak (subscriber, #2786) [Link] Regarding C code generation, C++ compilers were for many years just C pre-processors like Vala is now. Vala is just younger (and prettier) language than C++, just give it time and it may grow into a real compiler like C++ compilers did. Whether we need yet another language is another matter... As to Gtk/Gobject and Qt, having programmed a little bit with both, there's much less difference between Gtk and Qt that with C and C++. If you know Gtk & C, Qt itself is not a problem, but C++[1] can be. Like Perl, it's a bit of a line noise compared to better designed languages (better designed meaning orthogonality etc, not performance & practicality). [1] and Qt's moc variant of C++ with its magic defines.
Mark Shuttleworth on the future of Ubuntu Posted Jun 5, 2008 19:55 UTC (Thu) by nix (subscriber, #2304) [Link] The only C++ compiler I've ever heard of that used a C compiler as its code generator was Cfront (and even that was quite unusual: it wasn't a preprocessor in any sense, in that it did full translation and just happened to emit C code: that C could would never contain e.g. any syntax errors unless Cfront was buggy).
Mark Shuttleworth on the future of Ubuntu Posted Jun 5, 2008 21:06 UTC (Thu) by oak (subscriber, #2786) [Link] > The only C++ compiler I've ever heard of that used a C compiler as its code generator was Cfront I have some faint recollections that some other C++ compilers were derived from that and then there was also Glockenspiel C++ and stuff using the EDG C++ frontend like Comeau C++. > (and even that was quite unusual: it wasn't a preprocessor in any sense, in that it did full translation and just happened to emit C code: Yes, sorry my terminology was bad. But isn't this also how Vala works?
Mark Shuttleworth on the future of Ubuntu Posted Jun 8, 2008 16:03 UTC (Sun) by salimma (subscriber, #34460) [Link] Regarding C code generation, C++ compilers were for many years just C pre-processors like Vala is now. Vala is just younger (and prettier) language than C++, just give it time and it may grow into a real compiler like C++ compilers did. Whether we need yet another language is another matter... There is a difference: Cfront *defines* its own object model, and because the C code it produces is not supposed to have a stable interface, it's easy to abandon C-code generation in favour of a full-blown compiler. Vala, by design, targets the GObject type system (letting users write GObject applications much more naturally than writing them in C). I don't think we'll ever get to a situation where valac's backend does not actually generate straight C code..
|
|||||||||||||