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.
  • I think it's worth pointing out that C++ can call the C libraries without any need to wrap the API in most cases. Vala just makes it easy to wrap the C API to fit into Vala's OOP style. Losinggeneration (talk) 10:01, 27 February 2009 (UTC)
• 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)

Sorry, but interested people can examine the output of valac themselves if they want to know what the output looks like. This is a general article, not a Vala development manual (where an analysis/overview of the outputted C-code could be relevant). - Simeon (talk) 14:59, 21 February 2009 (UTC)

I provided no analysis or overview of the generated code, just the code. Vala is a high level language, which gets transformed into C. If we provide an example of code in the high level language, it makes sense to provide an example of the result of applying the transformation of the AST built from the high level language into C. This is different from showing python to bytecode, or C# to CIL, &c, since Vala is transformed into another commonly used, human-readable, lower-level language. And that's the whole point of vala: to allow "developers to write complex object-oriented code rapidly while maintaining a standard C API and ABI...[producing] C source and header files from Vala source files as if you've written your library or application directly in C."[1] 24.243.3.27 (talk) 02:52, 22 February 2009 (UTC)

Yeah, but this article is not specifically for developers, it's for everyone who hears the word 'Vala' (in this context) and wonders what the language is about. I'm not saying the generated C code is not of interested, it's just not within the scope of this article (and Wikipedia articles in general). Anyone considering Vala for their project will go to other websites anyway. It's clear that some examples of Vala's syntax are encyclopedic but the generated C code, while human readable, is not, in my opinion. - Simeon (talk) 14:57, 23 February 2009 (UTC)

I understand your point, but I still disagree. If x86 assembly language were widely used and well-known, it still wouldn't be very helpful in an article on Haskell, for example, to show the generated assembler code, since the aim of Haskell is not to produce assembly, but to generate binaries (i.e., generating assembly is just an implementation detail, or at best, a debugging aid). But in this case, the vala compiler is not just a front-end to a compiler, that just happens to generate C as an intermediate step in the compile process. It is a pre-processor with the stated goal of "[producing] C source and header files from Vala source files as if you've written your library or application directly in C", and the generated C is meant to be distributed to systems that don't host a vala compiler. If a specific focus of the project is to generate C source and headers, it makes sense to provide an example of the generated code, imo. 24.243.3.27 (talk) 05:58, 27 February 2009 (UTC)

Reverting to include generated C code per reasons given above. 24.243.3.27 (talk) 09:43, 1 March 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)

I agree. According to the manual, "[GLib] works on many UNIX-like platforms, Windows, OS/2 and BeOS"[2]—while that covers a huge chunk of OS's ("UNIX-like" includes IRIX, Solaris, OSX, BSDs, GNU/Linux, &c), I'd bet there's a system somewhere in the world with a working ANSI C compiler that won't build GLib. I think the description should be something like "Every platform supported by GLib." 24.243.3.27 (talk) 03:08, 22 February 2009 (UTC)