Après quelques années d'utilisation de Vala, je conseillerais plutôt le C maintenant. Il y a des avantages à Vala, mais aussi des (gros) inconvénients.
Si on veut faire du GLib/GObject en C, c'est vrai qu'il y a pas mal de code de « remplissage ». En Vala, les spécificités de GObject (interfaces, classes, propriétés, signaux, etc) sont directement intégrés dans la syntaxe du langage.
Ce qui est pas mal aussi, c'est les closures, ou fonctions anonymes où on peut appeler des variables qui sont déclarées en-dehors du corps de la closure. C'est pratique pour attacher un callback à un signal : le code de la fonction est au même endroit. C'est à réserver que pour les petites fonctions, bien évidemment.
Autre point fort de Vala : la gestion automatique de la mémoire (qui se fait avec un compteur, quand il tombe à 0 la mémoire est libérée). Mais ça peut être vu aussi comme un point faible pour Vala, car le compilateur valac fait parfois des trucs vraiment pas optimisé, notamment quand des chaines de caractères sont manipulées.
Il y a d'autres (gros) désavantages à Vala. Déjà, valac est assez buggé (bon, avec le temps ça s'améliore, mais c'est pas encore ça). Donc quand on trouve un bug dans Vala, on perd énormément de temps rien que pour se rendre compte que ça vient de Vala, il faut analyser le code C généré (qui est assez immonde), rapporter/corriger le bug, trouver un contournement en attendant, etc.
Quand vous faites du C, vous regardez souvent le code assembleur que GCC génère, pcq GCC est buggé ? Non, évidemment pas.
Faire du Vala, c'est rajouter une couche de maintenance en plus. L'API en C peut changer, des trucs deviennent obsolètes (surtout pour GTK+ ces derniers temps). Mais la « couche » Vala peut changer aussi. Ça demande du travail de maintenance en plus, qu'on n'a pas quand on fait du C.
Bref, pour développer une application Gnome, je conseillerais plutôt le C. Quand on voit une classe GObject en C, on se demande d'abord qu'est-ce que c'est ce bazar, mais finalement on s'habitue, c'est pas si dérangeant que ça.
Ce qui est bien avec le C, aussi, c'est que le code est facilement « greppable » : on utilise le nom complet des fonctions. En Vala, on utilise objet.méthode(). Quand « méthode » est un nom très court qui revient pour beaucoup d'objets (get, set, …), c'est difficile de trouver tous les endroits dans le code où la méthode est appelée. Dans ce cas c'est plus facile de grepper dans le code C généré, puis d'essayer de retrouver l'endroit exact dans le code Vala, ce qui n'est pas très pratique.
[^] # Re: Pourquoi Vala?
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Val(a)IDE 0.7.2. Évalué à 4.
Après quelques années d'utilisation de Vala, je conseillerais plutôt le C maintenant. Il y a des avantages à Vala, mais aussi des (gros) inconvénients.
Si on veut faire du GLib/GObject en C, c'est vrai qu'il y a pas mal de code de « remplissage ». En Vala, les spécificités de GObject (interfaces, classes, propriétés, signaux, etc) sont directement intégrés dans la syntaxe du langage.
Ce qui est pas mal aussi, c'est les closures, ou fonctions anonymes où on peut appeler des variables qui sont déclarées en-dehors du corps de la closure. C'est pratique pour attacher un callback à un signal : le code de la fonction est au même endroit. C'est à réserver que pour les petites fonctions, bien évidemment.
Autre point fort de Vala : la gestion automatique de la mémoire (qui se fait avec un compteur, quand il tombe à 0 la mémoire est libérée). Mais ça peut être vu aussi comme un point faible pour Vala, car le compilateur valac fait parfois des trucs vraiment pas optimisé, notamment quand des chaines de caractères sont manipulées.
Il y a d'autres (gros) désavantages à Vala. Déjà, valac est assez buggé (bon, avec le temps ça s'améliore, mais c'est pas encore ça). Donc quand on trouve un bug dans Vala, on perd énormément de temps rien que pour se rendre compte que ça vient de Vala, il faut analyser le code C généré (qui est assez immonde), rapporter/corriger le bug, trouver un contournement en attendant, etc.
Quand vous faites du C, vous regardez souvent le code assembleur que GCC génère, pcq GCC est buggé ? Non, évidemment pas.
Faire du Vala, c'est rajouter une couche de maintenance en plus. L'API en C peut changer, des trucs deviennent obsolètes (surtout pour GTK+ ces derniers temps). Mais la « couche » Vala peut changer aussi. Ça demande du travail de maintenance en plus, qu'on n'a pas quand on fait du C.
Bref, pour développer une application Gnome, je conseillerais plutôt le C. Quand on voit une classe GObject en C, on se demande d'abord qu'est-ce que c'est ce bazar, mais finalement on s'habitue, c'est pas si dérangeant que ça.
Ce qui est bien avec le C, aussi, c'est que le code est facilement « greppable » : on utilise le nom complet des fonctions. En Vala, on utilise objet.méthode(). Quand « méthode » est un nom très court qui revient pour beaucoup d'objets (get, set, …), c'est difficile de trouver tous les endroits dans le code où la méthode est appelée. Dans ce cas c'est plus facile de grepper dans le code C généré, puis d'essayer de retrouver l'endroit exact dans le code Vala, ce qui n'est pas très pratique.