Why Vala?
When I told some people that I will write (which involves re-writing existing code first) the gupnp-media-server in Vala, their question was "Why Vala? Why not Python, Java or C#?". So here are the strong points of Vala, not all of which are found in these languages:
UPDATE:I am sorry if my ideas hurt someones's feelings attached to some particular language. If i have hurt your feelings, there is no need for insults, I didn't force you to read my blog. Just writing this after removing an insulting comment from an 'Anonymous' dude.
- Statically-typed
Back in the days, when I was hacking on Gazpacho I found the lack of types on variables and function/method parameters really annoying in Python. This can become quite a pain when you are reading other's code and that is exactly what I was doing most of the time. The fact that Johan and Kalle wrote very nice and readable code, helped a lot though. - No runtime dependency/overhead
This might seem like a small point to many developers but as an embedded-systems developer, this is a big plus for me and I am sure to many (if not most) of the embedded-systems developers out there. - Easy integration with C/GObject
A big plus for all the GObject/C developers out there. Besides, there are situations when writing code in any language other than C or C++ is not possible/viable and such easy integration would make life very easy. Recently a colleague of mine had to bind a gobject-based library for Python and it turned out to be a lot more pain than I imagined. This impression is based on the fact that so many of GNOME developers have taken python so serious and so many of the GNOME apps are being (re-)written in Python.
This point is very important when it comes to writing frameworks and libraries since if you write them in a language that doesn't qualify as a LCD, you are pushing your choice of language on the application developers you aim to attract. Since Vala translates to a language that does qualify as LCD, it in turn also qualifies as one.
An important bit here is that this integration is bi-directional, i-e one can use the classes written in Vala very easily from C. In fact this is much easier than doing it the other way around as you don't have to write any bindings.
UPDATE:I am sorry if my ideas hurt someones's feelings attached to some particular language. If i have hurt your feelings, there is no need for insults, I didn't force you to read my blog. Just writing this after removing an insulting comment from an 'Anonymous' dude.
Comments
real 0m15.836s
user 0m13.311s
sys 0m0.396s
(note -C switch). Now this is a slow computer I have here, so here's C++ for comparison.
/tmp JH$ time g++ helloworld.cc -O2
real 0m1.186s
user 0m0.733s
sys 0m0.252s
(note -O2 switch).
Secondly, would be nice to know what exactly you are comparing here. I mean are the two apps doing exactly the same using exactly the same code in different syntax?
You don't need to be constrained by the valac compiler optimization since you can ask it to generate you the c source files and you can then compile them using the gcc options you want.
Last but not the least, I can't possibly appreciate a language that allows multiple inheritance and doesn't have the concept of interfaces. FULL STOP. :)
(I didn't mean C++ was good/bad/better/worse/whatever, just ignore it completely. Though it's really strange to read what you write about interfaces, C++ supports them via multiple inheritance, and it can do *more*, via multiple inheritance. But it's really irrelevant)
I agree that 15 second is a lot but one must keep in mind that Vala is a relatively new language and so is valac and I am sure valac will be much faster after someone spares some time to optimize it. On my laptop which isn't very fast, it isn't significantly slow and therefore pretty usable for me and I am sure the same is true for many other GNOME developers.
>C++ supports them via >multiple inheritance, and >it can do *more*, via >multiple inheritance.
I have been told that several times by C++ admirers but as i tried to explain, supporting multiple inheritance is a BAD idea and C++ advertizes that as big feature. I truly admire James Gosling for deliberately leaving it out of Java.
One thing C#/Mono has over Vala is the IDE. Monodevelop is a fine piece of software with its project management, code completion, and the heavily integrated stetic UI builder. So maybe implementing vala into monodevelop as a first class citizen will help speed up adoption.
@ali: many people do. You think people are kidding when they say that no-compilation is a feature of python, or distcc and ccache are projects from the past?
* The cairo example takes less than 2 seconds on a recent system including C compilation and linking, few people use systems with an eight of that speed for software development.
* The expensive part is parsing the bindings and building the internal GObject representation of the GTK+ API, not the actual compilation of the small demo application. We're planning to switch to the binary metadata format of gobject-introspection, which will speed up things a lot, and there are also some performance improvements for the internal object structure planned.
* You only pay the price of the bindings once per application/library, so if you compile many Vala source files, it won't take much longer than the small demo application, so it's not like you have to wait much longer for large applications.
> bindings and didn't find the
> process any easier than with
> mono.
And I did not claim that it is. I only compared the process with writing python bindings.
> I have a look at making vala bindings and didn't
> find the process any easier than with mono.
In my experience, making Vala bindings is easier than mono bindings (and several orders of magnitude easier than PyGTK bindings - I look forward to the day when gobject-introspection is stable...but I digress). Tehk is currently working on mono bindings for libawn (applet library for Avant Window Navigator), and it's been a relatively slow process...whereas with vala, it was fairly easy to run the vala-gen-introspect and vapigen tools to get some working bindings. Granted, our bindings currently do not work with 0.3.x (we don't plan on updating until 0.3.4), but that's the price you pay for following a language that still maturing.
> in the sense that someone
> could think that C# and Java
> are dinamically typed, which
> is not true.
That might be because of my bad english. I tried my best not to give that impression and that is why i wrote:
"So here are the strong points of Vala, not all of which are found in these languages"
Please do let me know if there is a more clear way of expressing this.
iirc there is a google soc project to integrate vala into anjuta. Really looking forward to see how that works out.
I think some of your concerns are explained there.
I was learning Python but when I've found information about Vala I was very interested to learn Vala instead of Python. :) I think that Vala is the best alternative for now but I am not a professional. What do you think about it?
P.S. Interesting article :)
Not exactly! It's mostly about minimizing time and efforts involved in developing a particular piece of software. Most other choices you mentioned enable you to achieve that very nicely but they have serious side-affects and they are not always compatible with each other (at least out of the box).
So developers who don't want those side-affects are forced to keep coding everything in C. Vala on the other hand managed/chose to not impose those side-affects and therefore for me it's *the* way to go forward.
Having said that, this is my personal opinion and does not reflect the opinion of the majority of the GNOME developers.
i have to start off this comment by saying that was a very good and very informative blog. It is very well written and i am excited to read some more of your blogs. I completely agree with you when you said that "An important bit here is that this integration is bi-directional, i-e one can use the classes written in Vala very easily from C." I realized, partially thanks to this blog, that it is much much easier to use this integration bc you dont have to write any bindings which is too time consuming. Anyways i really enjoyed reading this blog. keep up the good work.
Thanks for your kind appreciation, this is what keeps me going.
bc you dont have to write any bindings which is too time consuming.
I am sorry if i gave such an impression since that is unfortunately not true. Vala bindings are still needed by the vala compiler. Although the binding generation will become much more centralized/easy once GObject Introspection (http://live.gnome.org/GObjectIntrospection) is really "there".
Having said that, it's not that difficult to wrap small parts of your C code for Vala:
http://github.com/zeenix/rygel/blob/262c77ecbc56c32fe700dd0f345776eadb44c705/src/rygel/cstuff.vapi