Re: [Vala] vala code generation too constrained?

[Jan Hudec <bulb ucw cz>]

On Mon, Jan 10, 2011 at 12:03:16 +0800, Nor Jaidi Tuah wrote:
> Some of the big gotchas in vala is due to the
> desire to produce a standardized C code that can
> interface nicely with non-vala module. I suspect
> this constrain also makes it difficult to implement
> some features.

Vala is interesting exactly because it generates standardized C code that can
be easily used from C therefore every other lanugage out there, because C as
the lowest common denominator can be interfaced with any language. Otherwise
there are heaps of languages that are more powerful and far less quirky than
vala -- just they basically can't be interfaced with each other.

> Old timers familiar with C will find the gotchas
> natural and can live with it. But I wonder what
> the java-educated mass will think when they encounter
> vala idiosyncrasies.
>
> Since not all vala code are intended for libraries
> accessible from non-vala, I suggest that the compiler
> should be given more freedom with the name mangling
> and so on, so that its behaviour is gotcha-free.

This is not going to work. The same vala code has to always produce the same
C code independently of what other modules get compiled together with it. You
know, because somebody might compile them separately and link them together
afterwards.

> A compiler flag can be added to revert back to the
> human-friendly C generation.
>
> Vala is great already. But I wish it to be even
> greater.

Just use D, or C#, or Java, or Haskell, or OCaml, or Go, or ...
In fact for things that are not library, just use Python, Perl, Ruby or
anything dynamic. They are faster to write in and the performance hit just
does not matter for end applications. But for the platform components the
human-friendly C generation is needed and that's where vala stands out.

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>