Submitted by “About half a year ago I was looking around me and seeing stagnation in the GNOME community. I was concerned that GNOME had lost its momentum and that we were just making boring incremental releases that added very little new functionality. I think I was very wrong. I’d like to take this time to list some things that are happening right now in the GNOME community that have me very excited. These are the projects that are actively improving the future of the GNOME desktop.” Let’s hope a punctuation checker will be part of GNOME too. One Aaron is enough.
hope vala language kills mono one time for all
hope betamax will kill vhs
It’s a nice brief overview. I like to bounce around to different window managers and desktop environments, so it’ll be interesting to see how future GNOME releases turn up.
I will say that it’s difficult to read paragraphs that contain only lowercase letters.
I cannot talk much about GNome but I sure know that “Evolution mail client/Calendar program” definitely needs replacement that GNome ships with it. Its a memory hogger, does not have “Summery page” it is not simple like “Thunderbird” and not elegant like “Sunbird” Surprisingly Sunbird which is in just 0.5 stage is far superior than Evolution.
Every time I install Ubuntu with GNome the first thing I do is to remove Evolution.
Rest the specified features in GNome looks interesting. I still feel that the icons in GNome needs lot of improvement. Also the most important area GNome guys needs to work is Fonts. They really need to provide crispy fonts like Apple Mac OS accross all the apps.
I have had pretty good luck with evolution. as a mail client i like it. its very stable.
how well did it perform in terms of speed and responsiveness … I think that is the point of concern.
I cannot talk much about GNome but I sure know that “Evolution mail client/Calendar program” definitely needs replacement that GNome ships with it. Its a memory hogger, does not have “Summery page” it is not simple like “Thunderbird” and not elegant like “Sunbird” Surprisingly Sunbird which is in just 0.5 stage is far superior than Evolution.
Sunbird is only a calender app. Evolution obviously does a lot more than that. I have used Evo for a long time now and haven’t experienced any real issues with for a couple of years now. In fact I don’t think there is a more complete and robust PIM out there.
Rest the specified features in GNome looks interesting. I still feel that the icons in GNome needs lot of improvement. Also the most important area GNome guys needs to work is Fonts. They really need to provide crispy fonts like Apple Mac OS accross all the apps.
Personally I like the icons and they are going to be tangoified soon anyway. As far as fonts go I don’t know why people still think this is an issue. My fonts across GNOME are more crisp and better looking than either OSX or Windows in my opinion.
You are right Evo has become a lot stable now but I’ve used evo in 2003-2004 when it had terrible issues.
The new interface is not that user friendly and it occupies lot of space on screen. Like I pointed out earlier it definitely needs summery page, which they used to ship in early evo version, i have no idea why it was removed. If you directly compare the evo with KOrganizer you will really feel the difference in user friendlyness and features.
As far as icons goes, like you pointed out, if GNOme is coming with new icons its a great news. Yes fonts only look good in some apps, the consistency accross the apps in GNome really needs to work. Ex: In ubuntu my fonts are superb but when I open some apps like Opera the font quality goes for toss…
The new interface is not that user friendly and it occupies lot of space on screen. Like I pointed out earlier it definitely needs summery page, which they used to ship in early evo version, i have no idea why it was removed. If you directly compare the evo with KOrganizer you will really feel the difference in user friendlyness and features.
I think the user interface is fine. Anyone who has ever used a mail client before will know exactly how to use Evo. As far as the summary page goes, I remember it but I don’t really miss it.
As far as icons goes, like you pointed out, if GNOme is coming with new icons its a great news. Yes fonts only look good in some apps, the consistency accross the apps in GNome really needs to work. Ex: In ubuntu my fonts are superb but when I open some apps like Opera the font quality goes for toss…
This has nothing to do with GNOME. GNOME’s fonts are fine. Other toolkits will require that you tweak the font settings separately. It’s like using Java on Windows. Even if your windows fonts are excellent Java fonts always look crappy.
This is the answer I posted in the comments before it hit osnews…
Wait, so the big news in Gnome are…
– a rewritten configuration system
– another html renderer that does the same than the previous except it’s different internally
– gfvs, a rewrite of gnome-vfs
– vala, a hack to fix the problems of chosing C as the base language for the platform (the description of vala pretty much tells this)
– tinymail, an implementation of email software
– rewrite of GDM to add funtionality that is not use by the vast majority of users
Except for telepathy, tracker and gbus, I’m not seeing any major improvement here…
(Some interesting answers to my comment: http://blogs.gnome.org/desrt/2007/08/07/im-excited-about-the-future… , http://blogs.gnome.org/desrt/2007/08/07/im-excited-about-the-future… )
Edited 2007-08-07 19:01
As a side note to the second comment you are linking to (about Webkit’s plugin handling)
A comment on one of Zack Rusin’s blog entries on the same matter indicates that at least some developers on the Gecko/Mozilla front are interested in moving to the out-of-process plugin handling as well.
Not only for the mentioned stability improvement, it also helps with plugin loaing time, especially if the plugin in question is the Java runtime starting for an applet. Currently Firfox is probably the only browser which freezes during startup of the JRE.
As you got me curious, maybe some other would like the URL:
http://zrusin.blogspot.com/2007/05/browser-plugins.html
And I agree that in-process plugin are evil: the browser is running someone else’s code inside its process and if it crash, it makes the browser look dumb (and it is for having such bad architecture)..
It just amuses me to think about Torvalds’ anti Gnome rants, and the ensuing DE war (among many over the years).
Since I first started using Linux in ’02, I regularly switched back and forth between KDE and Gnome. I always like different things about both, with both having their relative strengths and weaknesses.
But over the last year or so, I’ve been more and more into Gnome.
For me, Gnome just “feels right”. Everything in Gnome is just smooth, simple, clean, logical, attractive, and highly productive and enjoyable.
Not only has Gnome gotten better in the above attributes, but it has become more robust, faster, and more feature rich – without suffering from “feature bloat” – the Gnome devs have always shown good, wise restraint.
It’s gotten to the point that I not only like Gnome better than KDE, but pretty much any desktop environment, including OSX, Windows (XP and Vista), and the various other ‘nix DE’s.
Then when Gnome is deployed by advanced, easy Gnome oriented distros like Ubuntu or Fedora, it gets even better.
Thus, I appreciated the article listed here. It’s good to hear that Gnome remains active, innovative, and exciting.
i agree. i mean, sure gnome is developing slowly. But does it really matter when they are getting everything right? i would rather them take time, to make gnome perfect, rather than just start implementing things like crazy.
I really like the idea of vala, from reading up on it- mono is roughly equivilent to java JIT when it comes to speed.
Whereas Vala seems a lot closer to C – possibly more comparable to C++/D/Objective-C?
being able to use C ABI is really important also, so there isnt the overhead of having to write interfaces for every library.
All the best for vala.
As I’ve said before, D is a perfect fit for GNOME. It’s source and binary compatible with C and native C libraries, plus all of the nice stuff that Vala adds and more. Why they chose to reinvent the wheel with Vala is beyond me.
because vala is better of D and the syntax is similar to c# and the gtk-sharp library.
I only know about this from reading the web, so it would be nice to hear from sombody from the vala project.
but I think the reason is the integration of GObject into the language.
by the sounds of it, D could be used with gnome at the moment anyhow.
D doesn’t have any sort of runtime to speak of, and so for applications programming it is a giant step backwards. It is a full on systems programming language, and unless the Gnome or Qt/KDE libs were written in D (how likely is that?), the language is irrelevant to Free Desktops. There is nothing like GObject or Qt’s QMetaObjects in D, and neither does it have interesting static type inferencing like Haskell etc.
The integration of GObjects in Vala is very powerful. If you write a class in Vala, and as well as generating C from the code, it should make it possible to also generate Mono or Python bindings. The Gnome bindings projects currently have to annotate the original C api with a lot of lisp or xml metadata, and writing the classes in Vala would make that unnecessary. So a native Gnome Vala GObject api, rather than a C api, should allow language bindings to be autogenerated to a greater extent.
I thought the big benefit of using D was that it could load C libraries, giving you the entire C runtime without having to rewrite anything in D.
Vala is going in a different direction, though, with the integration of GObjects and since it is being created by GNOME it will obviously fit in better. I still think it is a little silly to invent your own language (NIH syndrome to the extreme), but GNOME needed to do something and no one could agree on which language to switch to.
Just to say that because I don’t want any of the projects to get a bad bad publicity out of misinformation.
Vala is not exactly being developed “by Gnome” it is simply hosted by gnome and doesn’t have the manpower gnome has behind it.
It is a very nice project which I watch closely, but it could really use more developer mind-share and ideas.
Unfortunately I’m not in a position to help them, but I sure would do if I could.
If anything, USE it, guys. It could really make a great project going faster.
As I’ve said before, D is a perfect fit for GNOME. It’s source and binary compatible with C and native C libraries, plus all of the nice stuff that Vala adds and more. Why they chose to reinvent the wheel with Vala is beyond me.
Regarding Vala…
I seem to remember reading a while ago about some Danish guy who added some object orientated stuff to C, and wrote a compiler that translated the new language back into C, in exactly the same way as Vala does. I think he called it “C with Classes” or something like that.
Anyone know what became of that project? If only it was still around and could already be used by GTK…
Edited 2007-08-07 21:44
Come on, this is not fair.
When Gtk+ was first started, they didn’t bet on C++ support, it wasn’t that standard at the time, had problems with ABI and all sorts of things.
So they tried to overcome that with C and they got it quite well.
Now we have a lot of stuff being worked on Gtk+ and GObject and Vala can take advantage of that all without writing complex wrappers around it… so… why not ?
Might you be talking about GObject Builder (GOB)? http://www.5z.com/jirka/gob.html
I used it. It’s very useful for building GObject classes, and even includes for defining assertions in the parameter specification. Unfortunately that is all it’s good for, it doesn’t support any other high-level language features.
I like the idea of Vala, a lot. I’ve thought about it in the past and wondered why nobody did this before.
I’m not sure that D’s implementations are ready for GNOME: their GC aren’t ‘real-time’ so it could create annoying pause for client applications, and I don’t think that it is SMP friendly either (not sure though) which is important as multicore computer becomes the default (sure you’re not obliged to use the GC but ..).
Plus they have currently two standard libraries: Phobos (which is the official one) which I like but which is quite limited and Tango which is more complete, but which I don’t like much (I dislike what I consider an abuse of object-orientedness, YMMV of course).
But yes, D is quite good (even if its syntax could be improved).
Why on earth would gnome need a real time GC ? Most dynamic allocation scheme are not suitable for real time anyway (this includes malloc). I don’t see either how a language would not be SMP friendly (less than say C, for example); is it the standard library ?
I would say that for desktop environment, using multi-core is more or less trivial since you have different independent applications that the OS can schedule as he wants.
I am sure D as its deficiencies: that’s exactly why it would seem more interesting to improve its implementation than reimplementing a language.
>Why on earth would gnome need a real time GC ?
Because with a non-‘real time’ GC, the garbage collection could induce a pause which can be annoying for the user: I’m thinking about music or video playing mostly..
>I don’t see either how a language would not be SMP friendly
The ‘basic’ GC are ‘stop the world’ kind: when they do a garbage collection, they freeze all the thread of an application on all the CPU, where as ‘SMP friendly’ GC do not do this (there is small performance price to pay).
>I would say that for desktop environment, using multi-core is more or less trivial since you have different independent applications that the OS can schedule as he wants.
Only if you’re satisfied with mono-threaded application like Firefox, me I loved the responsiveness that BeOS multi-threaded application had and I just switched from Firefox to Opera because I couldn’t stand Firefox non-responsiveness..
So yes, D-implementations could be improved for GNOME needs, but I’m willing to bet that Mono’s GC is no better (as it’s very hard to make a real-time, SMP friendly, VM-friendly GC).
Well, this is not more for GC than it is for dynamic allocation. To avoid pause, you should design your application for RT; this means no allocation, no paging out. Normal GC are not bounds ? Neither are normal malloc.
But frankly, that’s not really what is putting gnome way behind compared to kde at the API level.
I don’t know the design of firefox, but it is certainly not monothreaded (ps -e. Beos responsiveness has nothing to do with multi threading per se (BeOS handled threads rather poorly, by the way). JBQ had interesting comments on that (he was a developer at Be)
http://www.osnews.com/comment.php?news_id=66
But real time is really a niche for gnome development ! For audio applications, the common design is one thread which does the processing, without any system call to avoid any potential unbounded operations, without memory locked on buffers to avoid them to be paged out (since to page in a page on the disk is extremely costly, something like several order of magniture x more costly than reading from memory). No big data structure to handle generally, this can be do in C.
Optimize an dev environment for dekstop for real time does not seem really worthwile, frankly. Optimize it to avoid memory leaks, enable people to develop good applications thanks to a good API and documentations, that’s what is needed for gnome. I personnally cannot stand kde (3.* at least), I much prefer gnome, but there is no question which environment is much more powerful today. That needs to change, and I am not sure vala is the right step.
But I hope to be proved wrong.
>Normal GC are not bounds ? Neither are normal malloc.
Sigh, you know as well as me that the big difference is that a GC can run at any time but with malloc/free, there can be a delay only when you call malloc or free, so it’s easy to avoid pause in normal software: preallocate before the time sensitive part, with a GC either you have also to disable the GC collection or you use a real-time GC.
>ps -e. Beos responsiveness has nothing to do with multi threading per se
So how do you explain it?
The link you gave didn’t say that BeOS wasn’t threaded, just that it’s hard to do threaded programming (a well-known fact).
AFAIK all BeOS applications had at least two threads: one for the window, one for the application core and IMHO this had a lot of impact on the responsiveness felt.
The solution is not only to preallocate malloc, but to do all the computation in a separate thread, without any unbound operations: no malloc, no locking, etc… The thread can then be efficiently scheduled using SCHEDULE_FIFO, for example. If you do everything in a different thread, you can also disable the GC for this thread. But anyway, this is really not the problem that vala is trying to solve, so I don’t see how it is relevant.
JBQ explains exactly why on the contary, BeOS was not responsive because of the multi threaded API, but for other reasons. This is a really interesting thread
“Vala seems a lot closer to C”
Vala is C, as in, it compiles into C.
Looks good. Always nice to see that Gnome too is advancing, and in very different areas than KDE is, so the results will be useful to developers from both camps.
The one bad idea though is Vala. Sure it’s convenient to have a pseudo-language that is essentially optimized for Gnome development, but realistically it will never take off, for a few good reasons:
1. It’s completely specific to Gnome, no outsiders will know Vala. So on top of learning new libraries, you would be learning an entirely new language.
2. It’s just generating C code, and generated code will never be as clean or elegant as handwritten code (done by someone with experience). That’ll scare off the purists.
3. An extension of 1, it has basically zero use outside Gnome. Putting “Vala” on your resume won’t help you get any jobs.
Gnome would be better served by making sure the official bindings for other languages (C++, Java, and the scripting languages) are top notch and integrated into the development tools.
1, wrong. GObject is from glib and even KDE depends on glib *, glib is also available on many platforms so vala could run on those also.
* when I installed KDE from jhbuild I think it was, it installed its own glib.
2. This often happens when your converting say, from python to C, but this language is fairly close to C, so it dosnt have to make as many changes.
3. – The “because it wont look good on my resume” argument is stupid – Neither would telepathy, tomboy or mono, flex or boo. – This is new software, you dont try and impress the boss with it. Besides, we arnt all looking for work.
Even though I disagree with you, inventing a new language should be a last resort, but hey- if it dies, so be it. developers will carry on with their language of choice.
The reason I think this could work well is the overhead of maintaining this language is low, since it seems more like a translator then a new language (as far as the backend goes).
Could vala to gnome be like objective-c to macos?
Edited 2007-08-07 21:01
Ok, but why would you want to use Vala outside of Gnome? There are a lot of languages that are more widely supported by development tools and more mature.
Just because you don’t care about how applicable your skills are doesn’t mean no-one does. Sure, for some people it won’t matter that Vala is not going to help them get a job, but you’re putting another obstacle in the way of those who do. If I’m working on open source, I would rather work on something that will give me marketable skills. There are not that many developers willing to contribute their free time to open source projects to start with, and inventing new languages to add to the learning curve is not the way to encourage them.
Perhaps. And look how that turned out. Support for Objective C in tools outside of MacOS is practically nonexistant, even though MacOS is a bigger platform than Linux+Gnome.
because when you start a project you dont want to be locked into 1 platform – even if that project starts out being platform specific. – gimp/gaim etc.
If employed as a gnome developer, then the most important thing is that your skills are applicable to gnome. besides, Im sure what you learn in vala applies to other languages also.
Lots of developers contribute free time to opensource projects. of course we could always do with more.
http://www.ohloh.net/kudo_ranks
Edited 2007-08-07 22:17
“Ok, but why would you want to use Vala outside of Gnome? There are a lot of languages that are more widely supported by development tools and more mature. “
Who cares? That’s like asking why you would want to use Ruby on Rails outside of web development.
Look, people on Slashdot and OSNews are constantly complaining that Mono is evil and should die. Developers choose Mono/C# because it’s easier and faster (easier syntax, no manual memory management, etc) than C. Now, Vala can provide all those advantages without depending on Mono, and all people here can do is complaining?
Geez.
“Just because you don’t care about how applicable your skills are doesn’t mean no-one does. Sure, for some people it won’t matter that Vala is not going to help them get a job, but you’re putting another obstacle in the way of those who do.”
It might not help them get a job, but it can help them get a job done.
Sun didn’t develop Java to allow more people to be employed. Microsoft didn’t develop Windows to allow more people to be employed.
Just what is your problem? If you are only looking for skills to have a better chance of being employed, then by all means, don’t learn Vala! Nobody is forcing you to! But you have absolutely no right deny other people the right to develop and/or learn Vala.
“and inventing new languages to add to the learning curve is not the way to encourage them.”
Vala seems to be syntactically almost exactly the same as C#, which is already similar to Java. The “learning curve” you speak of is almost nonexistent. It even looks like learning Vala is a lot easier than learning C.
1. It’s completely specific to Gnome, no outsiders will know Vala. So on top of learning new libraries, you would be learning an entirely new language.
It looks very similar to C# to me. You might have to learn how to start method names in lower case though, if that’s the sort of thing you find difficult. As a KDE developer I’m quite envious of the language agnostic approach of the Gnome project. That might be a result of the fact that GUI programming in C is so painful, but KDE is still more C++ focused than Gnome is C focused.
Note that Objective-C has been pretty much specific to OpenStep/Cocoa for over 15 years (since Stepstone Objective-C died), and it doesn’t seem to have done that platform much harm.
It’s just generating C code, and generated code will never be as clean or elegant as handwritten code (done by someone with experience). That’ll scare off the purists.
Well you obviously should write in assembler then for maximum ‘elegance’.
An extension of 1, it has basically zero use outside Gnome. Putting “Vala” on your resume won’t help you get any jobs.
Oh really – do you think we should be developing Free Software purely with an eye to what clueless recruitment consultants might think?
Gnome would be better served by making sure the official bindings for other languages (C++, Java, and the scripting languages) are top notch and integrated into the development tools.
Yes, but that is happening anyway. Less work on the Vala project doesn’t automatically mean more work put into other projects.
It’s not that it’s particularly hard to learn, I’m sure most programmers won’t have any trouble learning it, but it’s just another thing to learn. Especially for novice programmers that may have learned some Java or C in college, the more new stuff you pile on, the less likely they are to contribute.
You know more about language bindings for KDE than I do though. Can you elaborate on why the situation there is worse than on Gnome? It seems to me that the bindings (Ruby, Python, etc) are in fairly good shape.
Well, that’s debatable. Openstep is certainly not very widely used on Linux, and MacOS is still more or less a niche platform as well. Also note that these technologies have stayed on the platforms they were written for. You don’t see anyone developing with ObjC on Windows for example, even though it is theoretically nicer than, say C++.
No, but sometimes you want it a certain way for performance reasons.
Of course not, but free software depends on developers willing to spend time on it, and if you offer the side benefit of gaining marketable skills, you might entice more people.
Anyway, I’m not advocating that Vala shouldn’t be developed, I’m just betting that it won’t take off for those reasons.
You know more about language bindings for KDE than I do though. Can you elaborate on why the situation there is worse than on Gnome? It seems to me that the bindings (Ruby, Python, etc) are in fairly good shape.
Yes, technically the Qt bindings for Java, Python, Ruby, C# are in excellent shape. But there are only bindings for Ruby, C# and Python in prospect for KDE4 (nobody is currently working on KDE4 java bindings).
Based on KDE3 usage (of Python and Ruby) there are about 10x as many users of the Qt only bindings as the KDE ones. But with the Sugar project, the Gnome project has built an entire environment around PyGtk and that is way ahead of anything the KDE project have done with bindings. That doesn’t mean PyGtk is technically better than PyKDE, just that nobody has done that much with PyKDE.
PyQt has certainly been used for a large number of serious projects, and it is the Qt/KDE binding that QtJambi, QtRuby or the C# Qyoto bindings need to measure up to.
I couldn’t disagree more.
1. If you know C#, you know Vala. There are minor exceptions, but you’ll spend far more time learning a library’s API than them. Besides, many of the exceptions (such as explicit memory management) are optional. It’s not a pseudo-language any more than C#, C++ or C. It just compiles to C, not bytecode or assembly.
2. You have so obviously missed the point that it’s almost embarrassing. By using Vala to generate the C code, you don’t have to maintain C code, any more than the author of a C program has to maintain assembly. Repeat after me: Vala is a compiler. Hacking its output renders it nearly useless.
3a. Your conclusion that Vala has no use outside of GNOME is a product of your uninformed leap to conclusions, not reality. Vala merely wraps GObject. Any task you can use GObject for (hint: this could be any project under the sun) is a perfect candidate for Vala. Vala limits you to GNOME about as much as Cairo does (i.e. not at all).
3b. Padding your resume should not be a deciding factor in whether something is a good idea. By that reasoning, Internet Explorer’s multitude of security and usability issues are good, seeing as how knowledge of them got my web designer friends jobs…
Of course it’s not hard, but it’s just another thing to learn. The more of these things there are, the bigger the barrier to entry, even if that barrier is mostly psychological.
Right, but then there’s a performance tradeoff. You can’t have modern language features with an automatic code translator while still retaining the same performance. The generated code will be bigger/slower than a hand coded C implementation.
I’m not saying this is a bad thing, but people are treating Vala like a huge breakthrough (features for free!) when it is really just another higher level language (with a few nice features for GObject integration).
I didn’t say it has no use, I just don’t see anyone wanting to use it, when it offers little or no benefit over the miriad of other, more mature, and more supported languages out there.
It’s not a deciding factor, but a contributing factor in recruiting new talent. If given the choice between contributing to a project that will allow you to learn C++ and one that uses Vala, I believe some people (especially young people looking to boost their development skills) will lean towards the project that uses the more established technology.
Hey there, leos.
I have to clarify a few things, but please note that I may be outdated, since I haven’t been playing with Vala for a few months now.
The generated code is, indeed, very very near what I would write by hand, and sometimes a little better.
Better in the sense that, since it doesn’t have to be readable, it can write a few optimizations on top of it.
Very few things generate more code than what is needed, except for the automatic memory management (which increases just a little bit of the generated code, and is completely optional) and perhaps the things regarding Exception handling, which is newer than the last time I tried.
It *IS* pretty much “features for free” because GObjects object model maps very closely to what Vala does (and what C# has) delegates and closures are almost directly mapped to signals and callbacks, properties as well, and the list goes on.
I keep saying, to all GObject developers out there, give Vala a try, check the generated code, try it in small projects. Be a tester and a supporter. It could be a great technology to our tool chain if only it was a bit more mature.
If I had a bit more time I’d be working on the compiler right now.
Regards.
BTW: Vala compiler is written in vala
not much of a feature… but it’s interesting.
That’s a terrible argument. Why innovate at all if it forces us to learn? Would you prefer it emulate a language you know better? Will you refuse to learn C#, then? Remember, it looks good on a resume (your words, not mine).
If you’re going to maintain that there’s a performance tradeoff, you have to substantiate that. You obviously don’t know much about compilers if you really believe the tripe you just typed.
GCC generates better machine code than I could, while freeing me to work at a higher level of abstraction. It optimizes the resulting code so that I don’t have to, leaving my code simple and easy to comprehend.
Vala’s compiler generates better C/GObject code than I would, while freeing me to work at a higher level of abstraction. It optimizes the resulting code so that I don’t have to, leaving my code simple and easy to comprehend.
There’s no difference between the two, except of course the level of abstraction at which you’re working.
The project is a few months old and you take its lack of uptake relative to larger, more established projects as a sign of inferiority? Obviously plenty of people want to use it. Read the comments. Scour Google Code/SourceForge/[insert free project site here] for Vala projects. They’re cropping up everywhere… and the language isn’t even stable yet!
The only reason you think it offers no benefit is because you refuse to acknowledge its strengths. To phrase that more succinctly: why should anyone use C over assembly? If you can answer that question intelligently, you’ve accidentally justified Vala’s existence.
Ah, so there’s your agenda.
Is C++ a language or a religion? Because, from where I’m sitting, the hot new “enterprisey” languages are C# and Java, both of which bear a striking resemblence to Vala’s syntax. C++ skills, while valuable, are no longer the recruitable commodity they once were. One could even venture to say that, since learning Vala is a great introduction to C# and Java, Vala skills offer far more value to a prospective employer than “just” C++. After all, anybody who can program with Vala can put C# on their resume with relative confidence.
> 1. It’s completely specific to Gnome, no outsiders will know Vala. So on top of learning new libraries, you would be learning an entirely new language.
Think about all devices that uses GTK+/GObject/Hildon, no market here, right?
the biggest feature of Vala is that you don’t need mono or thirdy party dependencies.
you can construct gtk-sharp like classes and then compile it in plain c.
live.gnome.org/Vala
Talking about having your cake and eating it, too!
The higher level language bindings to GTK+, GObject, etc are wonderful. They bring higher productivity and safer/easier memory management over just writing GTK/Gnome apps in straight C. The only drawback is that with those higher level language bindings comes the resource expensive runtimes/garbage collectors of those languages (Mono with C#, Python interpreter with Python, etc) at runtime, making the resulting app heavier and a bit slower.
With Vala, it looks like you get the higher level abstractions of C#, with object orientation, and memory dealt with automatically, but then it’s compiled to the corresponding C code (with memory allocation/deallocation done in the resulting C code), which in turn is natively compiled. And then you get the low overhead, fast execution speed of pure C compiled code.
Talking about the best of all worlds, if Vala can deliver on it’s promises.
I can’t wait to get my hands on it, to give it a whirl.
This is real innovation/improvement/added relevant feature in Gnome.
And then you get the low overhead, fast execution speed of pure C compiled code.
Vala translates to C code because it is an order of magnitude easier than going straight to assembly, just like Java and .NET go to their virtual assembly language that abstracts away the underlying hardware. It won’t be faster, though. If anything, the higher level of abstraction will slow things down more since the compiler will have less information when it is being compiled into assembly. (Of course, that assumes that GCC and mono have the same amount of optimizations in them, which is probably false, and you won’t have the startup penalty of a VM)
Still, sometimes perceptions are more important than actual performance, and people usually associate C code with speed.
Edited 2007-08-07 22:43
GCC and mono are different beasts. GCC compiles native code where as mono/java dont – Vala will be compiled C code with no odd runtime dependencies like java and mono.
Vala seems roughly comparable shedskin* or GCC’s java compiler – GCJ, which compiles binaries but youll find its not used by many projects compared to sun’s java.
* shedskin is python -> C++
http://sourceforge.net/projects/shedskin/
I know exactly what the differences are between GCC and mono. And mono does execute native code at the end, the VM has a backend that spits out native code to run on your machine, just like the Java vm does. The difference is that it is compiled at run time rather than ahead of time, which means that any optimizations made have to be done more quickly, but also allows for some new optimizations not available on statically compiled code. That’s also why it is compiled down to a psuedo-assembly language rather than plain C code, because the final compilation step is much faster.
Edited 2007-08-08 00:04
yep, Im familiar with JIT, however mono and java just dont run as fast as standard compiled code.
http://www.mobydisk.com/softdev/techinfo/speedtest/index.html
Edited 2007-08-08 00:34
however mono and java just dont run as fast as standard compiled code.
But it is still to be seen if it will run as fast as this generated C code, which was my point to begin with.
a fairly good demonstration would be to compare these 2 projects.
shedskin – translated python into c++
http://mark.dufour.googlepages.com/home
vs
iron-python – jit compiled python
http://lists.ironpython.com/pipermail/users-ironpython.com/2006-Mar…
shedskin is about 40x faster then CPython according to the webpage of the aythor (2-220 times faster then python),
ironpython, seems to be faster at some stuff, and worse in other areas.
http://lists.ironpython.com/pipermail/users-ironpython.com/2006-Jul…
The advantage Vala has is that it is designed to be translated (unlike python) – so aspects of the language would drastically reduce the speed of the resulting C code, it can be tweaked to work better.
Well, shedskin can only compile toy programs. Not to diminish the effort, I think it is an intereseting project, but to compare it to IronPython is not really pertinent; also, shedskin has limitations on the python code it can compile, which IronPython does not have.
For Vala, I still don’t understand the point compared to say D. Programming GUI in C is awful, but C++ has significant problems (lack of ABI standard on linux, for once, and extremely difficult to use from another language compared to C), I don’t argue with that. Programming large programs with rich GUI in python is not really practical (but that’s only from my limited experience). But what’s the point of vala compared to D ? I don’t see it. All points on vala webpage are key design features of D: OO syntax, optional memory management, C ABI, etc…
agree- you wouldnt want to base a larger project on shedskin, but as an example of the speed of a translated language. its not bad. – vala also dosnt have to worry about matching C# 100%.
the argument that a translated language would be slow is misinformed, because it depends on what your translating.
imagine you wanted to make C more like python. you could start by removing braces for implicit indented blocks, replace && with ‘and’, remove the ; at the end of each line, comments and so on… eventually youd need to deal with some tricky stuff like inline functions. but you could make C more python like with zero slowdown if you wanted.
Of course the changes would be superficial and if you wanted to implement exceptions or classes youd have to take a few weeks of work
– and it would not be that fast. but Vala uses C types so it dosnt have the same problem python does when being translated into a lower level language.
not a bad example of vala
http://aruiz.typepad.com/siliconisland/2007/08/the-first-vala-.html
Edited 2007-08-08 04:17
the argument that a translated language would be slow is misinformed, because it depends on what your translating.
Yes, I’m not saying it will definitely be slow, just that I wouldn’t count on it being fast without first seeing some benchmarks to back that up. I’m not very familiar with the Vala project, so I really can’t say much about it but the more you try to abstract the language the more general the generated code will likely be so I do think there is a trade off involved.
Well, there are also good example of languages based on VM. I understand the basic reasoning: C++ is awful to wrap in another languages, and for no good reasons (compare to let’s say java or C#, which are difficult to use from C for technical reasons), C is awful to write complex and rich GUI, and VM take quite of lot ram (the JIT seems to have a big cost in term of memory from my pure user experience). I personally hate C++ with a passion, and wished something like objective-C, D, or whatever “simple” language with C compatibility at binary and source level (both levels at which C++ fail nowadays) would be largely adopted. But why designing another language: this is what I don’t get. It is not like D or objective C have no open source compiler.
The thing is, while all this is possible to be done, D and Objective C has their own object model, while Vala creates a nice syntax around GObject’s object model.
D and ObjC are nice, but Vala is tailored to G-family applications. If Vala ever gets to the point of being as stable and ready as D and ObjC, it will be awesome
That’s the thing I don’t get: what special syntax is given outside signal ?
One thing I missed the first time I went to the webpage is the ability to be called from C, using a vala library. This is kinda cool.
Note that while this is true for ‘hot’ code (code that the VM has had the time to analyse, compile, optimise, ‘server’ code in fact), it’s less true for client application where there is a startup cost here for using a VM..
Just to mention that, while your comments about higher level means slower, Vala won’t probably be significantly slower than Gtk+ in C, just because the generated code is pretty much what you would have to write by hand anyways
Bah, nothing too interesting there for me..I’m not really a developer so I don’t get much out of that Vala or such things. I was just hoping there would be atleast something interesting for the non-dev GNOME user. I still wish I’d see the Mac style menu in the panel some day, but I have no idea if that’ll happen. Oh well :/
Lovely, Vala sounds cool.
But why not more comments on the other things they’re doing 😉
I read the blog a few days ago, and wasn’t too excited yet. Though fixing the Gnome infrastructure is a good thing, aside from tracker and telepathy, there isn’t much really new. I would’ve mentioned GOD, though it’s not clear what would come out of the whole online-desktop thing.
Even though the online-desktop stuff hasn’t lead to any new or cool technology and ideas yet, I expect it will in the future. Gnome has shown it can focus on something (usability) and if they don’t make the same mistakes they did back then (overdoing it, removing stuff before they had a replacement) I think this could lead to innovations and a headstart on the commercial competition. KDE won’t have a hard time folowing, though. As far as I can tell, it’s currently ahead on the online-desktop thing, at least it’s infrastructure is there. EG GHNS2 is pretty cool, and when they tried to work with the Gnome side on standardising it, there where no Gnome ppl working on it…
Though I’m not happy with all aspects of the Online Desktop, some great things might come out of it.
I cannot believe the amount of whining that is going on in this discussion. If you are a serious developer and not just a script kiddie then you should know several languages, at least a new one each year. This keeps you agile and provides you the resources to think of how to address certain projects with a broad tool box. All these comments like “I hate language X with a passion”, “Language Y is better for GUI development than X”, or (my personal favorite) “using X won’t look good on your resume” are a load of crap!
As a developer myself and one who hires real programmers, I only look for people that know several languages, can easily move back and forth between grammars, and are interested in applying the right tool to the job. Tool theory in mathematics tells us that the more generalized a tool gets the worse it does at any particular function. If you want to find interesting jobs using your programming skills, you need to know several languages. On the other hand, if you want to do one job the same way for the rest of your life then stick with your own personal favorite language. Personally, I would rather stop programming altogether than limit myself to only one language.
Looking at vala, it is so close to C# (and by extension java) that a real developer with any experience in either of these platforms should be able to pick up in an afternoon. If you want to criticize it you should first give it a try and collect data on its implementations. Alternatively, if you want to just throw around a bunch of uninformed opinions, then could you please preface the subject line with “Opinion:”?
Nobody ever claimed to use only one language, it is rather the contrary: why creating a new language which looks so similar to existing ones ?
I just found that post wishful thinking really, and apart from telepathy, tracker and gbus (IPC has been used in other desktop environments for years) then I’m not seeing an awful lot. Much of it just sounds like a response to stuff in KDE 4. There’s an awful lot of denial about the need for a Gnome 3, because unless the architecture of Gnome is radically altered, they can never have the exciting future they want.
The problem for developers in Gnome is that they don’t have a unified framework for doing things in a consistent way, such as with Qt in KDE, the Mono framework or Java classes, for example. Vala should be the start of pulling all that together, but it’s not quite the same thing.
Another thing is the architecture. KDE scores, in many ways people don’t realise, because it is built on a complete Qt, cross-platform toolkit. kdelibs is then built on top of Qt and the rest of KDE is built on that. This means that, strictly speaking, KDE does not directly depend on Qt. Qt remains cross-platform, and kdelibs might be by virtue of it being written with Qt, but it’s not guaranteed with things like Solid etc. This means that things that KDE needs today can feasibly be built into kdelibs today for the benefit of everyone (subject to KDE’s restrictions), in a solid, stable and officially released library, and if things get rolled into Qt in the future then they can be without breaking the API and ABI for KDE applications. It also means that KDE can depend on more than one library, apart from Qt, and present a unified API to developers through kdelibs that looks the same as everything else, that makes life easier.
The problem with Gnome’s underlying libraries is that:
a) There’s more than one, and it’s not just GTK.
b) It takes a long time to get any new features into GTK for the benefit of Gnome, simply because GTK is about more than just Gnome.
Point a) means that, from a developer’s point of view, there are different libraries to pull in, and they’re not all consistent in the way that code is written for them and how they are used. This hinders code reuse through the same library not being used by different applications.
Point b) is interesting in that a library like GTK is not independent from Gnome itself. GTK, by definition, is a cross-platform graphical toolkit, so stuff that people would want to see in GTK for Gnome’s benefit and to improve it can’t be unless it works or is handled cross-platform. This needs to be tested, bugs fixed, improved and then released. If there was a gnomelibs then all this could go in here in the meantime, but that’s not the way Gnome is structured. If there was a gnomelibs then much infrastructure could be coded in there, released officially and then rolled into lower libraries like GTK as required without impacting anything.
All this has increased the proliferation of libraries like libsexy and libegg, and sometimes straight code copying, and has impacted cohesion severely. It also decreases consistency and usability.
Personally, this is the biggest reason why I think there should be a Gnome 3, and the biggest hold-up in doing anything remotely exciting.