Talk:Vala (programming language)

run()

Why create a new instance of itself with a "run" function instead of typing stdout.printf from the static main? —Preceding unsigned comment added by 88.218.24.29 (talk) 17:45, 18 December 2007 (UTC)

Just to show off a bit more of the language? It's not supposed to be something useful anyway.195.110.28.107 (talk) —Preceding comment was added at 10:31, 1 February 2008 (UTC)

Hello-world programs are supposed to be simple, not to show any advanced feature beyond string output. Engelec (talk) 16:41, 27 February 2008 (UTC)

If it should be as simple as possible, we should use something like this:

using GLib;

void main () {
    print ("Hello World\n");
}

However, it would be useful to have a second example, then, that shows a bit more of the syntax. Juergbi (talk) 14:14, 22 June 2008 (UTC)

If it were to be as simple as possible you could drop the glib import and just have the one-liner:

void main() { print("Hello World\n"); }

24.243.3.27 (talk) 09:53, 19 October 2008 (UTC)

In the "object oriented" example, why is the static main function placed within the object? The static main may as just as well be placed in the global scope, which I think maps closer to how the OS launches the program. Pmg (talk) 06:28, 3 September 2008 (UTC)

One reason (not applicable to this example), would be so that main can access private/protected class members and methods. 24.243.3.27 (talk) 07:12, 22 September 2008 (UTC)

C++

Can somebody highlight the pros of using Vala, compared to using C++/gtkmm? —Preceding unsigned comment added by 82.238.35.175 (talk) 10:10, 10 February 2008 (UTC)

Depends largely on your preferences and aims.

Pros:

• Vala generates C code that relies on GLib/GObject for it's object system. Benchmarks show that generated Vala code is generally as fast or faster than hand-coded C++ (see link at bottom of article).
• Vala also makes it extremely easy to use external C libraries: you just have to wrap the header in a Vala API file (called a VAPI), and declare what functions you'll be using. There are already a bunch of VAPIs for GNOME related stuff like libglade and gstreamer.
• Vala also makes it easy to write C libraries -- you can use Vala to write libraries, compile them to C files, then distribute the C files. Vala can even generate a VAPI for the library along with the C files, so that you can use the compiled library from Vala -- i.e., you can use Vala to write a C library that can be used from any application with a C ABI and natively from Vala itself (the tutorial shows an example of this near the bottom).
• Since it is so tightly coupled with Glib/Gobject it obviously make it easier working with libraries that also use GLib/GObject.
• It's syntax is almost identical with C# (even has delegates and signals [think events]). I like this syntax *much* better than C++, personally, but that's subjective.

Cons:

• Vala is relatively young and doesn't have the huge use base and community support that C++ does.
• Vala has very sparse documentation in many places (just the method names with no description, no descriptions of the parameters except their names, &c).
• There is alot of existing C++ code that can be reused, not so much with Vala (although they have a pretty good sized list of examples on the front page).
• The VAPIs are a work in progress (e.g., glib-2.0.vapi doesn't wrap g_chdir [but see below]).

That's basically it, I think.

Ps. As an example of how easy it is to wrap C libraries, one can copy the default glib-2.0.vapi somewhere and edit it to wrap g_chdir by putting the following code under the DirUtils namespace, then compiling with the switch --vapidir=/path/to/modified/vapi:

                [CCode (cname = "g_chdir")]
                public static int chdir (string pathname);

Which then be used from Vala code:

                DirUtils.chdir( "/foo/bar" );

24.243.3.27 (talk) 08:00, 22 September 2008 (UTC)

This is outdated now: use Environment.set_current_directory () instead. 24.243.3.27 (talk) 08:15, 6 December 2008 (UTC)

Generated code?

It appears to me that the section with the generated code does not fit the philosophy of wikipedia. Including more features of the language seems to me to be much more suitable. Any one minds me erasing that section? --Pmg (talk) 08:17, 17 June 2008 (UTC)

Erase! The idea of displaying generated code is in discord with the inherent philosophy of presenting a programming language: a programming language should relieve the programmer from viewing any generated code. If it instead be a preprocessor, then generated code should instead be very sparse. The explaining texts should in both cases contain information on what the system provides to the user, not how it works inside, except very superficially. Said: Rursus ☻ 08:29, 30 June 2008 (UTC)

Vala (object oriented) can generate C (procedural) code so there are no exta compile-time dependencies compared to plain C. If I read this article, I'd want to know what that looks like. 83.86.153.204 (talk) 14:55, 2 December 2008 (UTC)

I agree. I've added a (brief) subsection showing the generated C code from the second example. 24.243.3.27 (talk) 04:23, 21 February 2009 (UTC)

Mem mgmt?

How is it memory managed if not garbage collected? Does the clause "The primary advantage of Vala over C++/gtkmm is that Vala is memory-managed (not using garbage collection)." mean that it is reference counted, which is sometimes explained as garbage collection, sometimes not. C++ is not garbage collected, and memory management is crude, but then is Vala better?

I should say that one possible advantage of Vala could be that it is not C, nor C++. C++ has deep trouble in the specification, giving the significant deficiencies:

• templates are essentially failed, it is not possible to write templates that works on all compilers, and it is not possible to write templates that can generate types from both inbuilt types and user defined types,
• the objects are so badly specified, that object initialization is not possible in systems with pthreads (parallell threads), and objects cannot be shared over shared memory either,

C has much much less deficiencies, most of which are impractical inconveniences:

• the inbuilt types doesn't define anything, you cannot be garanteed more than one bit of information, it's in theory fairly impossible to write working programs, but in practice there is some kind of de-facto standard of type sizes which the C standard doesn't care about (!!),
• the type control of C is weak - sometimes held forth as a blessing, but as any real programmer know, there are situations when you wish to override types, and other situations when you wish a really tough type control;

Said: Rursus ☻ 08:47, 30 June 2008 (UTC)

Answering myslef: reference counting it is. I'll update accordingly. Said: Rursus ☻ 09:25, 30 June 2008 (UTC)

Done. Feel free to fix spelin erors and formulation fawltzz. Said: Rursus ☻ 09:31, 30 June 2008 (UTC)

Supported OS?

The current OS support reads as "Every platform with an ANSI C compiler, Vala generates C code" This seems a bit misleading since GObject isn't ported to every OS. It seems it should read something more like "Every platform with an ANSI C compiler that GObject supports. Vala generates C code that depends on GObject." Or since GObject is usually dependent on GLib, perhaps it should read GLib instead of GObject... Any comments on this? —Preceding unsigned comment added by 206.127.184.24 (talk) 08:02, 19 February 2009 (UTC)