Muntyan! First off I wasn't addressing C++ since I don't concider that a high-level language and that is because it doesn't manage the memory for me.
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 thought it was well-known that C++ compilation is very slow! Sorry about that, I meant that Vala compiler (again, note -C switch, no optimizations from valac, nothing) is incredibly slow. g++ was only for comparison, ignore that. So, 15 seconds is a LOT. It's impossible to use a compiler which spends 15 seconds on compiling one file.
(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)
Oops! sorry Muntyan, I didn't read you comment carefully and hence the misunderstanding.
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.
I am admittedly a python fan and have no trouble with the way python is typed. Anyway I really like vala and I am planning on writing any future libraries in it. You LCD point is well made.
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.
May 24, 2008 at 3:18 PM
Anonymous said...
I have a look at making vala bindings and didn't find the process any easier than with mono.
@zeenix: how much time does Vala build take on your machine?
@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?
May 24, 2008 at 3:24 PM
Anonymous said...
Yevgen, slow compilation is a known issue, however, it's not as bad as it looks in your comment, a few things to note here: * 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.
(in reply to Anonymous #1) > 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.
May 24, 2008 at 5:21 PM
Comment deleted
This comment has been removed by a blog administrator.
> Your blog entry is ambiguous > 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.
May 25, 2008 at 10:43 AM
Anonymous said...
Vala might just be "it". For example, let's say I want to write a simple GTK app. What are my choices? I could go the native way, C (or C++), but I would feel like I'm doing work, not having fun, so those two are out. The next two popular choices would be Python or Mono-C#. Well, those two are "foreign" platforms with their own agendas (and runtime baggage), that I don't particularly care about. So, Vala makes perfect sense to me. Vala just needs tool support to be a complete solution, any plans for Anjuta/Monodevelop/... plugins? (language stuff, like completion etc.)
May 25, 2008 at 11:42 AM
Anonymous said...
@last anonymous
iirc there is a google soc project to integrate vala into anjuta. Really looking forward to see how that works out.
May 25, 2008 at 11:58 AM
Anonymous said...
Probably you would like to see/read the presentation "Dynamic Languages Strike Back" (from the googler Steve Yegge).
I think some of your concerns are explained there.
May 30, 2008 at 8:08 AM
Anonymous said...
Vala takes longer to compile but the finished binaries are very fast and good, at least compared to C#, Python or MRI Ruby.
If I am not mistaken the GNOME developers have to leave C and there are some ways for them to go. Python, C# or Vala. As a user of GNOME I don't want "exe" files in my system :) But what do you think about future of GNOME as a C/GTK+ based DE?
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?
If I am not mistaken the GNOME developers have to leave C and there are some ways for them to go
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.
February 1, 2009 at 6:12 AM
Anonymous said...
zeenix, 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.
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.
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:
Vala is very promising and basically agree with your reasons for using it( I started programming in 1983 ). Small, static executables that don't depend on extra libraries (except system ) is a very good thing! Because it translate into 'C' it is also cross-platform and fast.
June 25, 2010 at 1:03 PM
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:
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.
"Why Vala?"
24 Comments -
/tmp JH$ time valac cairo-demo.vala --pkg gtk+-2.0 --pkg cairo -C
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).
May 24, 2008 at 2:08 PM
Muntyan! First off I wasn't addressing C++ since I don't concider that a high-level language and that is because it doesn't manage the memory for me.
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. :)
May 24, 2008 at 2:26 PM
I thought it was well-known that C++ compilation is very slow! Sorry about that, I meant that Vala compiler (again, note -C switch, no optimizations from valac, nothing) is incredibly slow. g++ was only for comparison, ignore that. So, 15 seconds is a LOT. It's impossible to use a compiler which spends 15 seconds on compiling one file.
(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)
May 24, 2008 at 2:38 PM
Oops! sorry Muntyan, I didn't read you comment carefully and hence the misunderstanding.
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.
May 24, 2008 at 2:58 PM
It is really funny, people always find something to complain about. Seriously who cares about compilation speed ?
May 24, 2008 at 3:08 PM
I am admittedly a python fan and have no trouble with the way python is typed. Anyway I really like vala and I am planning on writing any future libraries in it. You LCD point is well made.
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.
May 24, 2008 at 3:18 PM
I have a look at making vala bindings and didn't find the process any easier than with mono.
May 24, 2008 at 3:24 PM
@zeenix: how much time does Vala build take on your machine?
@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?
May 24, 2008 at 3:24 PM
Yevgen, slow compilation is a known issue, however, it's not as bad as it looks in your comment, a few things to note here:
* 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.
May 24, 2008 at 3:26 PM
> I have a look at making vala
> 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.
May 24, 2008 at 3:27 PM
Ali: Anyone that works on a software of a significant size. Full rebuild of the c++ project I've been working on recently takes more than an hour :/
May 24, 2008 at 3:29 PM
(in reply to Anonymous #1)
> 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.
May 24, 2008 at 5:21 PM
This comment has been removed by a blog administrator.
May 25, 2008 at 12:05 AM
Your blog entry is ambiguous in the sense that someone could think that C# and Java are dinamically typed, which is not true.
May 25, 2008 at 10:02 AM
> Your blog entry is ambiguous
> 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.
May 25, 2008 at 10:43 AM
Vala might just be "it". For example, let's say I want to write a simple GTK app. What are my choices? I could go the native way, C (or C++), but I would feel like I'm doing work, not having fun, so those two are out. The next two popular choices would be Python or Mono-C#. Well, those two are "foreign" platforms with their own agendas (and runtime baggage), that I don't particularly care about. So, Vala makes perfect sense to me. Vala just needs tool support to be a complete solution, any plans for Anjuta/Monodevelop/... plugins? (language stuff, like completion etc.)
May 25, 2008 at 11:42 AM
@last anonymous
iirc there is a google soc project to integrate vala into anjuta. Really looking forward to see how that works out.
May 25, 2008 at 11:58 AM
Probably you would like to see/read the presentation "Dynamic Languages Strike Back" (from the googler Steve Yegge).
I think some of your concerns are explained there.
May 30, 2008 at 8:08 AM
Vala takes longer to compile but the finished binaries are very fast and good, at least compared to C#, Python or MRI Ruby.
January 17, 2009 at 6:33 AM
If I am not mistaken the GNOME developers have to leave C and there are some ways for them to go. Python, C# or Vala. As a user of GNOME I don't want "exe" files in my system :) But what do you think about future of GNOME as a C/GTK+ based DE?
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 :)
February 1, 2009 at 2:40 AM
If I am not mistaken the GNOME developers have to leave C and there are some ways for them to go
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.
February 1, 2009 at 6:12 AM
zeenix,
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.
February 5, 2009 at 5:39 PM
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.
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
February 5, 2009 at 11:41 PM
Vala is very promising and basically agree with your reasons for using it( I started programming in 1983 ). Small, static executables that don't depend on extra libraries (except system ) is a very good thing! Because it translate into 'C' it is also cross-platform and fast.
June 25, 2010 at 1:03 PM