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

""


 * 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)
 * You at least need to extern "C" {} the callee and include the C header. 24.243.3.27 (talk) 08:50, 24 March 2009 (UTC)
 * Still one of the big advantages of C++ is you can usuaully just include the C header in an extern "C" block (unless the C header trys to get really fancy). With most other languages you have to actually translate the imports (and home the library authors don't change them. Plugwash (talk) 19:46, 24 April 2009 (UTC)
 * How does C++ prevent upstream from changing the library API? Sure, you get the functions for free by including the header, but if upstream changes the API on you, you get something like "implicit redefinition of function foo: original definition was in foo.h". But I agree that C++ has the tightest binding to the C ABI. So while it is not a Con against C++, it is still a Pro for Vala that it has a nice FFI for C. 64.234.67.2 (talk) 05:09, 27 May 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:

""


 * Which then be used from Vala code:

""


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

I deleted the generated code. It's completely inappropriate for an encyclipedia article.--Fashionslide (talk) 21:51, 17 April 2009 (UTC)


 * I re-included the code. Without any reason given for removing it, and given that a stated goal of the vala project is generating portable C code, it seems senseless to remove the section showing the generated code--since that's the whole point of the project. 64.234.67.2 (talk) 11:20, 21 April 2009 (UTC)


 * Sufficient objections have also been raised: inappropriateness in encyclopedia, more suitable for elsewhere on the web, this is an *article*. Please don't include a large amount of code with little informative value for the majority of readers (aka not active Vala users). Thanks, Simeon (talk) 13:07, 21 April 2009 (UTC)


 * I won't edit-war over the issue, but I will note my dissenting view once again. Vala specifically states that one of it's main goals is to generate pure ANSI C code for platforms without a Vala compiler. Thus, I judge it a good and necessary aide to considering the meaning and purpose of Vala in an encyclopedia article, to include a small sample of the generate C code. If I had never used Vala, I would consider it highly relevant to see a small sample of the type of C code that Vala generates. 64.234.10.32 (talk) 07:18, 16 June 2009 (UTC)


 * I saw teeth and blood all over the floor!, please be more kind when discussing. When to include or not the target code, depends on how is it relevant to explain the semantics of the language. That should be the criterion to decide it's inclusion. I still not understand what is Vala, here says that it is a preprocessor, maybe something like the old ratfor (rational Fortran)?
 * That is not clear in the article, for that reason I think is better to write a new one as suggested below — Preceding unsigned comment added by 189.178.72.176 (talk) 04:48, 12 October 2015 (UTC)

On the one hand, most languages compile down to either physical or VM machine code and C++ itself used to be a front end that was was translated into C, yet not many pages (any?) on Wikipedia display this translated form. On the other, "not having to write in GLib C" is a feature of Vala, hence maybe it is useful to show an example of the C code. In the end however the latter can simply be stated, and for consistency with other languages pages on Wikipedia, removing the generated code example seems like a good idea. mjog (talk) 03:36, 21 October 2016 (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: C has much much less deficiencies, most of which are impractical inconveniences:  Said: Rursus   ☻   08:47, 30 June 2008 (UTC)
 * 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,
 * 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;


 * 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"—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)

Name?
What's the origin of the name "Vala"? I can think of several candidates... Arny (talk) 00:26, 2 April 2012 (UTC)

A new Vala article is needed!
I'm sorry for such drastic petition, but a programming language is characterized mainly by it's syntax and semantics.

Not by examples of how to code the classic Hello World! in different styles.

The object oriented example is very ill constructed,

the line:

means that, which is an instance of the streams class, which is capable to process the   message. It is too artificial to embed it in a class called sample, as was done in the article.

I came to this article trying to understand a free software source which includes modules with the .vala extension. But this article says no substantial thing about such language. What is it's advantage compared with plain C or C++, if I only see some complicated examples.

The article could start with an informal, or should I said semi-formal description of Vala syntax, maybe comparing it with C and C++. From which it seems to be inspired.

Then the formal syntax rules of the language (in BNF or similar) or at least a pointer to the official definition.

Then give some important semantic features, like differences in meaning of statements with the same syntax in C or C++ and Vala. I do not expect a formal (operational) semantics, for vala, as the vast of those new languages are not developed on such formal basis, but as variants or little improvements of other languages, like C/C++.

Neither I do expect from it to include all the semantics of the language in an encyclopedia article, but some important features at least. The present article mentions the capability to write anonymous functions, which seems interesting. I may be developed saying for example:

Why is important to have anonymous functions? How are they written? Are they really useful? I can define them, but can I generate them? In plain ANSI C one can use function pointers, but one can not create functions on the fly, (technically speaking: it is not a higher order language). There are some forms to overload functions, and that is why it is an interesting feature. Of course overloading methods is more natural in OO languages like C++. Can you say something like that in the Vala article?

How about recursion, iteration oriented languages, are not good to implement recursive functions, because as part of semantics, each time a function is called information to return is stored in a stack (see about the heap) which may be too small to be useful in practice. But self calling functions can be transformed in several ways to avoid such problem. Can you say something about this issue in Vala?

I hope that I have been clear with the idea of how an article like this about a programming language Vala, may be structured. — Preceding unsigned comment added by 189.178.72.176 (talk) 02:54, 12 October 2015 (UTC)

Please update the release version.
— wi24rd leave a comment 17:32, 13 February 2019 (UTC)


 * You can do this yourself by simply editing the page. --mjog (talk) 00:45, 18 February 2020 (UTC)

How should the infobox indicate there is a LTS version?
The current Vala versions are 0.46.9 (Stable) and 0.48.5 (LTS), both released on April 23, 2020. How can the infobox indicate there is a long-term support release? Kiamlaluno (talk) 11:57, 23 April 2020 (UTC)