OSNews

hope betamax will kill vhs

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.

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

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.

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.

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

"Vala seems a lot closer to C"

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

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?

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

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

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 ?