Linked by Thom Holwerda on Tue 7th Aug 2007 17:31 UTC, submitted by GhePeU
Gnome "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.
Order by: Score:
vala language can kill mono
by pierino on Tue 7th Aug 2007 17:54 UTC
pierino
Member since:
2005-07-31

hope vala language kills mono one time for all ;)

Reply Score: 2

RE: vala language can kill mono
by dtiziani on Tue 7th Aug 2007 22:01 UTC in reply to "vala language can kill mono"
dtiziani Member since:
2005-07-13

hope betamax will kill vhs

Reply Score: 4

Nice Brief Overview
by Lokken on Tue 7th Aug 2007 18:22 UTC
Lokken
Member since:
2006-06-27

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.

Reply Score: 3

RE:The Future of GNOME
by TusharG on Tue 7th Aug 2007 18:29 UTC
TusharG
Member since:
2005-07-06

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.

Reply Score: 2

RE[2]:The Future of GNOME
by poundsmack on Tue 7th Aug 2007 18:50 UTC in reply to "RE:The Future of GNOME"
poundsmack Member since:
2005-07-13

I have had pretty good luck with evolution. as a mail client i like it. its very stable.

Reply Score: 4

RE[3]:The Future of GNOME
by de_wizze on Wed 8th Aug 2007 21:54 UTC in reply to "RE[2]:The Future of GNOME"
de_wizze Member since:
2005-10-31

how well did it perform in terms of speed and responsiveness ... I think that is the point of concern.

Reply Score: 1

RE[2]:The Future of GNOME
by abraxas on Wed 8th Aug 2007 02:50 UTC in reply to "RE:The Future of GNOME"
abraxas Member since:
2005-07-07

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.

Reply Score: 4

RE[3]:The Future of GNOME
by TusharG on Wed 8th Aug 2007 05:24 UTC in reply to "RE[2]:The Future of GNOME"
TusharG Member since:
2005-07-06

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...

Reply Score: 1

RE[4]:The Future of GNOME
by abraxas on Fri 10th Aug 2007 16:42 UTC in reply to "RE[3]:The Future of GNOME"
abraxas Member since:
2005-07-07

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.

Reply Score: 2

Well....
by diegocg on Tue 7th Aug 2007 18:59 UTC
diegocg
Member since:
2005-07-08

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

Reply Score: 7

RE: Well....
by anda_skoa on Tue 7th Aug 2007 19:05 UTC in reply to "Well...."
anda_skoa Member since:
2005-07-07

Some interesting answers to my comment


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.

Reply Score: 3

RE[2]: Well....
by renox on Wed 8th Aug 2007 08:18 UTC in reply to "RE: Well...."
renox Member since:
2005-07-06

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)..

Reply Score: 3

Gnome is excellent
by JeffS on Tue 7th Aug 2007 19:37 UTC
JeffS
Member since:
2005-07-12

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.

Reply Score: 16

RE: Gnome is excellent
by graigsmith on Wed 8th Aug 2007 08:31 UTC in reply to "Gnome is excellent"
graigsmith Member since:
2006-04-05

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.

Reply Score: 2

go vala!
by ideasman42 on Tue 7th Aug 2007 19:58 UTC
ideasman42
Member since:
2007-07-20

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.

Reply Score: 1

RE: go vala!
by butters on Tue 7th Aug 2007 21:13 UTC in reply to "go vala!"
butters Member since:
2005-07-08

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.

Reply Score: 7

RE[2]: go vala!
by pierino on Tue 7th Aug 2007 21:19 UTC in reply to "RE: go vala!"
pierino Member since:
2005-07-31

because vala is better of D and the syntax is similar to c# and the gtk-sharp library.

Reply Score: 1

RE[2]: go vala!
by ideasman42 on Tue 7th Aug 2007 21:29 UTC in reply to "RE: go vala!"
ideasman42 Member since:
2007-07-20

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.

Reply Score: 1

RE[3]: go vala!
by Richard Dale on Tue 7th Aug 2007 21:54 UTC in reply to "RE[2]: go vala!"
Richard Dale Member since:
2005-07-22

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.

Reply Score: 4

RE[4]: go vala!
by smitty on Tue 7th Aug 2007 22:31 UTC in reply to "RE[3]: go vala!"
smitty Member since:
2005-10-13

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.

Reply Score: 4

RE[5]: go vala!
by AlexandreAM on Tue 7th Aug 2007 23:25 UTC in reply to "RE[4]: go vala!"
AlexandreAM Member since:
2006-02-06

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.

Reply Score: 1

RE[2]: go vala!
by tristan on Tue 7th Aug 2007 21:42 UTC in reply to "RE: go vala!"
tristan Member since:
2006-02-01

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

Reply Score: 7

RE[3]: go vala!
by AlexandreAM on Tue 7th Aug 2007 23:31 UTC in reply to "RE[2]: go vala!"
AlexandreAM Member since:
2006-02-06

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 ?

Reply Score: 4

RE[3]: go vala!
by FooBarWidget on Wed 8th Aug 2007 16:03 UTC in reply to "RE[2]: go vala!"
FooBarWidget Member since:
2005-11-11

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.

Reply Score: 1

RE[2]: go vala!
by renox on Wed 8th Aug 2007 08:36 UTC in reply to "RE: go vala!"
renox Member since:
2005-07-06

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).

Reply Score: 2

RE[3]: go vala!
by ashigabou on Wed 8th Aug 2007 11:13 UTC in reply to "RE[2]: go vala!"
ashigabou Member since:
2005-11-11

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.

Reply Score: 1

RE[4]: go vala!
by renox on Wed 8th Aug 2007 11:50 UTC in reply to "RE[3]: go vala!"
renox Member since:
2005-07-06

>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).

Reply Score: 2

RE[5]: go vala!
by ashigabou on Wed 8th Aug 2007 13:47 UTC in reply to "RE[4]: go vala!"
ashigabou Member since:
2005-11-11


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..


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.


Only if you're satisfied with mono-threaded application like Firefox


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


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).


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.

Reply Score: 1

RE[6]: go vala!
by renox on Wed 8th Aug 2007 15:26 UTC in reply to "RE[5]: go vala!"
renox Member since:
2005-07-06

>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.

Reply Score: 4

RE[7]: go vala!
by ashigabou on Thu 9th Aug 2007 01:10 UTC in reply to "RE[6]: go vala!"
ashigabou Member since:
2005-11-11

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.


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.

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.


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

Reply Score: 1

RE: go vala!
by Beta on Tue 7th Aug 2007 21:41 UTC in reply to "go vala!"
Beta Member since:
2005-07-06

“Vala seems a lot closer to C”

Vala is C, as in, it compiles into C.

Reply Score: 2

Vala
by leos on Tue 7th Aug 2007 20:16 UTC
leos
Member since:
2005-09-21

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.

Reply Score: 7

RE: Vala
by ideasman42 on Tue 7th Aug 2007 20:49 UTC in reply to "Vala"
ideasman42 Member since:
2007-07-20

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

Reply Score: 1

RE[2]: Vala
by leos on Tue 7th Aug 2007 21:50 UTC in reply to "RE: Vala"
leos Member since:
2005-09-21

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.


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.

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.


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.

Could vala to gnome be like objective-c to macos?


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.

Reply Score: 4

RE[3]: Vala
by ideasman42 on Tue 7th Aug 2007 22:14 UTC in reply to "RE[2]: Vala"
ideasman42 Member since:
2007-07-20

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.


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.

Just because you don't care about how applicable your skills are doesn't mean no-one does.


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.

There are not that many developers willing to contribute their free time to open source projects to start with


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

Reply Score: 2

RE[3]: Vala
by FooBarWidget on Wed 8th Aug 2007 16:11 UTC in reply to "RE[2]: Vala"
FooBarWidget Member since:
2005-11-11

"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.

Reply Score: 2

RE: Vala
by Richard Dale on Tue 7th Aug 2007 21:01 UTC in reply to "Vala"
Richard Dale Member since:
2005-07-22

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.

Reply Score: 6

RE[2]: Vala
by leos on Tue 7th Aug 2007 22:17 UTC in reply to "RE: Vala"
leos Member since:
2005-09-21

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.


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.

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.


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++.

Well you obviously should write in assembler then for maximum 'elegance'.


No, but sometimes you want it a certain way for performance reasons.

Oh really - do you think we should be developing Free Software purely with an eye to what clueless recruitment consultants might think?


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.

Reply Score: 5

RE[3]: Vala
by Richard Dale on Tue 7th Aug 2007 23:08 UTC in reply to "RE[2]: Vala"
Richard Dale Member since:
2005-07-22

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.

Reply Score: 4

RE: Vala
by monodeldiablo on Tue 7th Aug 2007 22:29 UTC in reply to "Vala"
monodeldiablo Member since:
2005-07-06

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...

Reply Score: 5

RE[2]: Vala
by leos on Tue 7th Aug 2007 23:04 UTC in reply to "RE: Vala"
leos Member since:
2005-09-21

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.


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.

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.


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).

3a. Your conclusion that Vala has no use outside of GNOME is a product of your uninformed leap to conclusions, not reality.


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.

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...


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.

Reply Score: 7

RE[3]: Vala
by AlexandreAM on Tue 7th Aug 2007 23:45 UTC in reply to "RE[2]: Vala"
AlexandreAM Member since:
2006-02-06

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.

Reply Score: 4

RE[3]: Vala
by monodeldiablo on Wed 8th Aug 2007 02:44 UTC in reply to "RE[2]: Vala"
monodeldiablo Member since:
2005-07-06

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.


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).

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).


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.

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.


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.

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.


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.

Reply Score: 4

RE: Vala
by netdur on Wed 8th Aug 2007 13:15 UTC in reply to "Vala"
netdur Member since:
2005-07-07

> 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?

Reply Score: 1

vala
by pierino on Tue 7th Aug 2007 21:52 UTC
pierino
Member since:
2005-07-31

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

Reply Score: 5

Vala looks great
by JeffS on Tue 7th Aug 2007 22:26 UTC
JeffS
Member since:
2005-07-12

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.

Reply Score: 6

RE: Vala looks great
by smitty on Tue 7th Aug 2007 22:39 UTC in reply to "Vala looks great"
smitty Member since:
2005-10-13

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

Reply Score: 5

RE[2]: Vala looks great
by ideasman42 on Tue 7th Aug 2007 23:12 UTC in reply to "RE: Vala looks great"
ideasman42 Member since:
2007-07-20

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/

Reply Score: 1

RE[3]: Vala looks great
by smitty on Wed 8th Aug 2007 00:00 UTC in reply to "RE[2]: Vala looks great"
smitty Member since:
2005-10-13

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

Reply Score: 2

RE[4]: Vala looks great
by ideasman42 on Wed 8th Aug 2007 00:33 UTC in reply to "RE[3]: Vala looks great"
ideasman42 Member since:
2007-07-20

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

Reply Score: 2

RE[5]: Vala looks great
by smitty on Wed 8th Aug 2007 02:48 UTC in reply to "RE[4]: Vala looks great"
smitty Member since:
2005-10-13

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.

Reply Score: 3

RE[6]: Vala looks great
by ideasman42 on Wed 8th Aug 2007 03:16 UTC in reply to "RE[5]: Vala looks great"
ideasman42 Member since:
2007-07-20

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.

Reply Score: 2

RE[7]: Vala looks great
by ashigabou on Wed 8th Aug 2007 03:25 UTC in reply to "RE[6]: Vala looks great"
ashigabou Member since:
2005-11-11

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...

Reply Score: 2

RE[5]: Vala looks great
by renox on Wed 8th Aug 2007 12:41 UTC in reply to "RE[4]: Vala looks great"
renox Member since:
2005-07-06

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..

Reply Score: 2

RE[2]: Vala looks great
by AlexandreAM on Tue 7th Aug 2007 23:49 UTC in reply to "RE: Vala looks great"
AlexandreAM Member since:
2006-02-06

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

Reply Score: 3

Non-dev end-user
by WereCatf on Wed 8th Aug 2007 08:49 UTC
WereCatf
Member since:
2006-02-15

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 :/

Reply Score: 1

Vala - pfff
by superstoned on Wed 8th Aug 2007 09:13 UTC
superstoned
Member since:
2005-07-07

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.

Reply Score: 2

A bunch of whiners
by roddog on Wed 8th Aug 2007 13:48 UTC
roddog
Member since:
2006-03-24

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:"?

Reply Score: 3

RE: A bunch of whiners
by ashigabou on Wed 8th Aug 2007 14:40 UTC in reply to "A bunch of whiners"
ashigabou Member since:
2005-11-11

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 ?

Reply Score: 2

Wishful Thinking
by segedunum on Thu 9th Aug 2007 14:29 UTC
segedunum
Member since:
2005-07-06

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.

Reply Score: 2