[Geany-Devel] Let's use Vala

[Matthew Brush]

On 13-11-09 10:49 PM, Lex Trotman wrote:
> On 10 November 2013 15:44, Matthew Brush <mbrush at codebrainz.ca> wrote:
>
>> Hi all,
>>
>> In the spirit of the previous discussions about using C99 and C++ in Geany
>> code with similar subject lines, I'd like to take a poll/discussion for
>> allowing the use of Vala for new/re-written Geany code. The pros and cons
>> likely will be slightly biased since I would obviously like to use Vala in
>> Geany, but here they are anyway:
>>
>
> To help allay your concern about bias I have commented on a few below :)
>
>
>
>>
>> Pros:
>> -----
>>
>> * Power of high-level OOP language using existing GObject backend with no
>> C boilerplate required
>> * Uses same type-system as existing C code
>> * Automatic memory management
>>
>
> Reference counting, not memory management, ie non-cyclic structures only,
> fine for GTK GUI structures, but not any old structures.  And of course it
> only applies to structures that support reference counting, not simple
> types as used in most of Geany.
>

Reference counting is a valid memory management strategy used in many 
languages like C++ or Python. Vala handles this fine and provides ways 
to break cycles or such as expected, and more often than not it's not 
even a concern while programming in Vala itself.

>
>> * Clean expressive syntax (foreach, as, properties, signals, async, etc.)
>> * Exceptions (which uses C/GError-style exceptions in generated C code)
>>
>
> Existing Geany code is not exception safe so this can't be used until all
> existing code is changed, see the C++ discussion for details.
>

Vala exceptions, as mentioned used GError result/out parameters, so 
there's no change from existing code.

>
>> * No extra dependency for release users (generated C code can be shipped)
>>
>
> But is unusable since its machine generated, ie we can't tell how it will
> change from Vala version to version, leads to problems like the Glade
> commit noise if its in the repository, but maybe it could be in the
> tarballs.  But of course you can't fix anything without vala since you
> would need Geany from git.
>

It means users who are only compiling Geany don't have to install valac, 
even though it's quite widely available. As usual, if they want to hack 
on Geany they will need a full development environment including current 
sources from Git.

>
>> * Can generate Gobject-Introspection bindings automatically allowing use
>> from a bunch of cool languages like Python, JavaScript, etc (and as many
>> other languages as support Gobject-Introspection) for plugins.
>>
>
> But only for those parts of Geany that are gobjectified, which is almost
> none ATM, Geany object only IIUC.
>

Which is partially the point of this discussion, simple Gobjectification 
of Geany's code, without the crufty boilerplate of Gobject/C, moving 
forward.

>
>
>> * Easy to learn for anyone who's used C++, Java, C#, etc.
>>
>
> Its got {} so it *must* be the same (sorry :) in the end its just another
> object oriented language with its own quirks.
>

Yeah, but it's pretty "normal" if you've used any of the simiar-ish 
languages. It's nothing new or revolutationary (see Haskell) :)

>
>> * Uses all existing dependencies as its runtime library (ex. GLib/GIO).
>>
>
> Good point.
>
>
>> * Can generate C/H code that is usable from within existing C code, so no
>> requirement to completely re-write, can just add on modular code as needed.
>>
>
> But heavily restricted Vala code because it has to interact with existing C
> code, much care needed.
>

No, it just generates C/Gobject code like you'd do by hand, just without 
writing tons of boilerplate.

>
>> * Can be tuned to output optimized C code, or call optimized C code quite
>> easily
>> * Can sometimes generate clever and/or optimized code that would be
>> tedious to write in C.
>>
>
> *All* code is tedious in C/C++/Java/ etc :)
>

Meh, some higher level features are possible (closures, asynchronous 
methods, garbage collection, etc) in lanugages above C++. With Vala you 
pay the least amount of cost for it (given existing code), IMO.

>
>> * Has Autotools and Waf support already, and using from plain GNU Make is
>> trivial.
>>
>
> How well does the windows version work, is it up to date, since it includes
> Glib and GTK which versions are they, and do they match ours?  The binaries
> for windows vala available seem to be 0.12, even my LTS Linux has 0.14,
> 0.16 and 0.18 valac available, more version hell and windows issues :(
>

See current issues WRT Windows binaries, not much change with Vala, just 
one more binary application to track version of.

>
>> * Actively developed and supported, and having active mailing list and IRC
>> channels. (ex. it's easier to submit a patch to Vala language than ISO C).
>> * AFAIK it generates C89-compliant code :)
>>
>> Cons:
>> -----
>>
>> * A fairly new language (since 2006). It's hard to argue against this, but
>> also impossible to move forward without adopting new stuff at some point.
>>
>
> And not yet complete (by its own admission).
>

But completely usable.

>
>> * Some dark corners/bugs due to being such a new language (compared to
>> C/C++).
>> * Actively developed so sometimes we probably have to require specific
>> valac versions to support certain features (ie. nothing like c89, c99,
>> c++98, etc but not unlike supporting newer G* versions).
>>
>
> More version hell, just what we don't need.
>

Not much/any worse than current situation, just more of an excuse not to 
care about pre-historic, deprecated, unsupported versions of stuff we 
shouldn't be targetting for new code :)

>
>> * As with above, may require to use fairly modern/specific dependency
>> versions of the G* C libraries (ex. might not work on RHEL or some other
>> LTS distros).
>>
>
> So how do we handle windows?  Of course we could drop it :)
>

I've used it before on Windows, not much different than current situation.

>
>> * Extra dependency (valac) for maintainers/developers.
>>
>
> So long as its a version thats in LTS repos and has available binaries for
> windows that doesn't matter.
>

For developement version, IMO who the hell cares about old pre-historic 
LTS versions, we aren't coding for them, but for their newer 
counterparts. IME Windows support is not bad, at least no worse than 
existing G* stuff.

>
>> * Using non-GLib-based libraries requires to write boring but trivial
>> binding .vapi files (not huge deal for existing Geany code).
>>
>
> Well, you already have done that for the plugin API IIUC, but still would
> be needed for the rest of Geany.
>

No, the rest of Geany would (eventually) be (re)written in modern 
GObject-style (vala-style) C thus elimitating this problem altogether 
(as well as the need for hand-coded bindings like we have currently). In 
the meantime, it's no worse than currently.

>
>> * Can sometimes generate heap-heavy or non-optimized code.
>>
>
> So does some of our C code ;)  I doubt its a significant issue.
>

Indeed.

>
>> * Can sometimes generate C code that causes warnings with common compiler
>> warning flags, would require to disable some compiler warnings on generated
>> C code to have a completely clean build (ex. use -w on all .vala code)
>>
>
> Ok if autotools and waf do that for the vala C code, but the existing Geany
> C code still needs pedantic settings.
>

Trivial to adjust Vala-specific flags.

>
>> * The documentation isn't as great as an ISO language that existed since
>> forever. The official language specification isn't as complete or
>> fleshed-out (ex. has TODOs) as an ISO language. There is lots of
>> documentation out there, for example on the official Wiki, but it's still
>> no substitude for definitive language reference and decades of
>> books/literature on the subject.
>>
>
> The draft manual at https://wiki.gnome.org/Vala/Manual is a good deal
> better than the "official" version, it looks almost usable.
>

Yep, and it gets better all the time.

>
>> * More people know C than C++/C#/Java (ie. style of Vala). IMO, this one
>> is untrue since people who use C nowadays are either well-versed embedded
>> programmers who already know the higher-level stuff, C/Gobject/Gtk+
>> programmers who already know or can easily understand how the higher-level
>> stuff works (ex. by looking at generated C code), high-level-only
>> programmers who for the most part don't need to care about how the
>> underpinnings work and already would know Vala since it's basically
>> C#(/Java), or finally, and I believe the least likely; complete n00bs who
>> would be much safer writing garbage in any high-level language than
>> directly in something like C/C++ anyway.
>>
>
> I don't think it matters how many know it, how many are willing to
> contribute is the issue, and with a mixed language application it needs two
> languages.
>
> And that leads to what I consider is the biggest problem with the proposal,
> having a project with parts in one language and parts in another.
>   Maintaining assumptions between them, some made by the vala compiler, some
> made by C coders, is going to be hard and a source of extra problems and
> bugs.  That alone is enough reason to not just start piling vala onto the
> existing Geany.

But the languages are directly related and directly compatible. It's 
almost impossible to know one without the other and gradually our source 
could move towards the other. There's no way around this without just 
saying "no", no matter which language you choose (including proper 
GObject-style C code).

>
> If there is really enough reason to change to vala I would suggest that the
> right way to do it is to define interfaces between those parts of Geany
> that are going to stay C for the foreseeable future, eg Scintilla,
> tagmangler etc and create vapi definitions for them.  Then build the basic
> skeleton of the app in vala, calling the C parts as required.  Its not as
> immediate as allowing random parts to be written in vala but is likely to
> be much more effective in moving the project forward, and ATM thats what
> Geany really needs, a good spruce up so new things can be more easily added.
>

The beauty of Vala is that it does allow for this. You can integrate 
existing C libraries (ex. TM or Scintilla) with or without changing 
everything to Vala and even just to small parts of new code in Vala and 
have it be completely compatible and callable from existing C code that 
hasn't/isnt' to be changed yet. It's like the best of all worlds.

> Cheers
> Lex
>
> PS we discussed the inappropriateness of +-1 as a reply to something this
> complex on IRC, won't repeat here.
>

Just to keep down in-depth discussions before higher-level concensus is 
reached :)

Cheers,
Matthew Brush