[Geany-Devel] Let's use Vala

[Pavel Roschin]

Maybe, rewriting some parts of boating complicated leaky code (e.g. build.c:)
isn't bad idea and suitable in this situation. You don't need much bindings for
editor and Vala shouldn't be a pain. But AFAIK Geany don't use GObject and
writing on Vala may cause deep refactoring that will take your time. Many things
in Geany could be rewritten, simplified and improved and it's definitely going
to be refactoring while using Vala.

To improve maintainability pure C code could be pre-generated before release
for faster and easier build without vala.

From the other side you could scare good C programmers...

About RHEL: defenitely can say that Vala 0.20 works. And some things could be
easily compiled.



> 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:
> 
> 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
> * Clean expressive syntax (foreach, as, properties, signals, async, etc.)
> * Exceptions (which uses C/GError-style exceptions in generated C code)
> * No extra dependency for release users (generated C code can be shipped)
> * 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.
> * Easy to learn for anyone who's used C++, Java, C#, etc.
> * Uses all existing dependencies as its runtime library (ex. GLib/GIO).
> * 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.
> * 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.
> * Has Autotools and Waf support already, and using from plain GNU Make 
> is trivial.
> * 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.
> * 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).
> * 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).
> * Extra dependency (valac) for maintainers/developers.
> * Using non-GLib-based libraries requires to write boring but trivial 
> binding .vapi files (not huge deal for existing Geany code).
> * Can sometimes generate heap-heavy or non-optimized code.
> * 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)
> * 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.
> * 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.
> 
> For more information about Vala, this a good starting point:
> 
>      https://wiki.gnome.org/Vala/Documentation
> 
> If we can cleanly get more +1's than -1's (in principle, and especially 
> from the core developers and active contributors), without wandering off 
> into nitty-gritty details, version-specific bugs encountered that 
> don't/won't specifically apply to Geany, stuff I have specifically 
> accounted for in the pros/cons list, and minutia like we (especially ME) 
> always do, then we can move forward with this and hammer-out those 
> details later during integration, rather than stifflying the idea here 
> in this thread as we (including ME) often do. If one or more of the 
> things you like or dislike is already mentioned, there's no point in 
> specifically responding to it unless you think it's unclear or 
> inaccurate, just give your +1/-1 and see where it goes.
> 
> Basically what I'm saying is that if we can keep this discussion on 
> track and people show enthusiasm (or at least not strong distain, in 
> principle) then I will personally volunteer my time to make it happen. 
> If it turns into a zillion message thread about off-topic, or 
> nitty-gritty stuff (which should occur later on, in a different thread) 
> or hate from people who have never tried the language in earnest but 
> still have a strong anti-opinion (especially based on old or presumed 
> information, or general hate for the G* toolkit we already use), then I 
> probably will just forget it, and probably no one else will move this 
> forward.
> 
> P.S. Sorry for stupid-sounding discussion rules, it's just an attempt to 
> move something useful forward, productively, with consensus, without 
> wasting our voluntary time discussing deep details too early-on, and 
> based on past similar discussions on this list and knowledge I have 
> about some poeple's existing opinions. Please don't take offense or rant 
> about the stupid "rules", just believe I'm sincere in that I'm trying to 
> organize the discussion more productively than usual (even if failing) :)
> 
> Cheers,
> Matthew Brush
> _______________________________________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel




--
Best regards,
Pavel Roschin aka RPG