When I first heard of Vala I was not impressed. A domain specific language? That seems like a dead-end; how would we every attract developers to the GNOME platform?
After a while of thinking about it I realised that GNOME already was in this position. GObject+C already is a domain specific language. New developers already have to learn GObject and finding developers who both are proficient and willing to use C can be a struggle.
Recently I have been working on more and more with Vala and porting applications from PyGTK/C to it. Before Vala, PyGTK had a lot of advantaged over C; now the main differences are easy debugging and fast development (Python) vs fast performance and type checking for easier maintenance (Vala).
So, my recommendation is if you have a desktop application that uses GObject APIs* and you are happy with debugging tools like gdb and valgrind then consider using Vala!
* I was working on porting LightDM to Vala but old system APIs were causing difficulty. If you have this case consider wrapping them in C+Gobject first and then interfacing to that.
7 comments:
Yeah vala is awesome I gave up on thinking about the shortcomings because most of it is fantastic :)
I think you comparison Vala vs C/GObject is not fair. C is a well know language. To develop for GNOME/Gtk+ you just have to use the proper libs. Having to use desktop specific (or better environment specific) libs is not the same as using a complete desktop specific programming language like Vala.
Sure C can be a pain if you write GUI apps. But IMHO it's not a solution to develop a new programming language. We have enough nice programming language, just use them instead of plain C.
Recently I see a much deeper problem for the programming environment GNOME, especially for GNOME3. Gtk+ is no longer the only (main) toolkit which you use to build your app. Many apps using Clutter other apps using Gtk+ but draw their own widgets using Cairo. This is a lot of confusion. Now add platform specific programming languages like Vala and IMHO the mess is perfect.
Anonymous,
The great thing about Vala is that you can write software using those libraries an order of magnitude quicker than if you were using C, generally with less bugs. Basically, it is a "nice programming lanuage". However, unlike using Python, JavaScript, etc., code you write in Vala can be reused in pretty much any language, and you don't have another virtual machine sucking up resources.
As for the fact that you use other libraries than GTK+ to develop GNOME applications, I'm not sure I understand what the problem is. The important thing is that the functionality is there, not that it is all part of a some monolithic library... in fact, I would much rather have the functionality split up into small libraries so I don't have to use the whole stack.
Also, although it is probably fair to call Vala domain specific (it is pretty much specific to GObject, although there are profiles for posix and Dova in development), I don't think it is anywhere near fair to call Vala a "desktop specific programming language". I have several programs written in Vala running on embedded devices without a desktop environment, and one server side program. In fact, the vast majority of my Vala code has absolutely nothing to do with the desktop... I only have one "desktop" application (actually a UI for an appliance, so "desktop" isn't even the right word).
nemequ, Vala certainly is not desktop-specific! My experience (and talking to others) is that when you use non-GObject APIs then things get a lot more complicated. You have to manage memory/references yourself, some APIs are not provided in the standard install and writing .vapi files is difficult.
For these reasons I'm recommending desktop developers use Vala - I wouldn't expect them to have any difficulties and they will immediately be more productive. Desktop apps that are in C are currently a huge maintenance overhead, and writing them in Vala will greatly improve the desktop. This is not to say I wouldn't recommend Vala for other projects, but if you're going to access other APIs, then be prepared for a harder time.
Robert,
Yes, it was Anonymous who called Vala desktop specific, not you. I don't disagree with anything from your original post :)
It is true that a lot of non-GObject APIs are harder to use from Vala than GObject APIs... that said, a lot of non-GObject APIs are a lot harder to use in general than a lot of GObject APIs. For instance, using libxml2 from Vala is a huge PITA, but using it from C is also a PITA. It's not really any harder to use libxml2 from Vala than C, it just seems really hard because other libraries are so much easier. Cairo can also be a bit tricky to use from Vala, as can sqlite3 (I actually ended up writing a wrapper, SQLHeavy), but I'm quite happy with libftdi, libusb-1.0, Tokyo Cabinet and libdmtx, to name a few. I also make fairly heavy use of POSIX in one of my projects, and it has been okay.
I've found that, for the most part, well designed non-GObject C APIs will work well from Vala, but APIs which are hard to use from C tend to be hard to use from Vala.
nemequ, oh good. I was worried I'd made a typo in the post or given the wrong idea :)
I think you're mostly right about the APIs seeming more difficult because the GObject ones are much simpler. The biggest issue was debugging using bad APIs wrongly - a memory problem is one step more complex than in C.
The API I was having the most trouble working on LightDM was PAM and using it in asynchronous D-Bus calls...
First, DBus support should be a lot better now with the move to GDBus. FWIW I think the FSO guys are making pretty extensive use of asynchronous DBus from Vala.
I just took a look at the PAM API, and it doesn't look like it would be too difficult to use from Vala. I'm not sure where you had problems in the past, but if you're really interested I would be happy to help you get the bindings right (I'm in charge of maintaining the bindings that are distributed with Vala, and I've written quite a few for various projects, so I have a decent amount of experience in the area). Feel free to ping me in #vala on GIMPNet (my nick is nemequ).
Post a Comment