URL: https://linuxfr.org/users/swilmet/journaux/quelques-langages-de-programmation-pour-gnome Title: Quelques langages de programmation pour GNOME Authors: Sébastien Wilmet Date: 2013年12月14日T19:56:35+01:00 License: CC By-SA Tags: python, vala, c, gnome et langage_c Score: 28 C, Python, [Vala](https://wiki.gnome.org/Projects/Vala), C++, C#, JavaScript, Java, Perl, [GOB](http://www.jirka.org/gob.html), [Genie](https://wiki.gnome.org/Projects/Genie) et sûrement d'autres. Autant de langages possibles pour écrire une application pour GNOME. Voyons voir ce que le C, Python et Vala ont dans le ventre ! # Le langage C # Le langage C peut être vu comme un langage assez primitif. Mais c'est sans compter les nombreuses bibliothèques de GNOME : GObject, GLib, [GTK+](http://www.gtk.org/), et bien d'autres (écrites elles-mêmes en C). GObject, le cœur de GNOME, offre un système dynamique de types, permettant de faire de l'orienté objets avec de l'héritage, des interfaces, et tout ce qui s'en suit. La gestion de la mémoire se fait avec un compteur, quand celui-ci tombe à 0, l'objet est détruit. Un objet peut envoyer et recevoir différents signaux, permettant d'exécuter des fonctions _callback_ quand le signal est envoyé. Un objet peut avoir aussi des propriétés, qui sont comme des attributs, mais permettent en plus de recevoir un signal quand la valeur est modifiée. Ce système de signaux permet de faire de la programmation évènementielle, ce qui est indispensable pour une application avec interface graphique, pour réagir aux différentes actions de l'utilisateur. Une autre bibliothèque fondatrice de GNOME est la GLib. La GLib offre un système de _threads_ couplé à une _Main Event Loop_. Les évènements concernant une application sont ajoutés à la _Main Event Loop_, et leur traitement peuvent être lancés dans différents _threads_. Les _threads_ peuvent communiquer de manière asynchrone. Mais la GLib est bien plus que cela, c'est aussi une boite à outils pour les développeurs, offrant de nombreuses fonctionnalités de haut niveau, ainsi que la manipulation de structures de données de base telles que des listes chaînées, des arbres ou des tables de hachage. Bref, c'est du costaud. Petit bémol : pour utiliser GObject en C, il faut un peu de code de remplissage (_boilerplate_), notamment certaines macros. Il existe des outils pour générer ce code de remplissage, donc au final ce n'est pas si embêtant que cela. Mais ça peut [faire peur](https://git.gnome.org/browse/gtksourceview/tree/gtksourceview/gtksourcesearchcontext.h) quand on ne connait pas. L'idéal serait d'avoir un IDE gérant le _boilerplate_ facilement, notamment renommer une classe, tout en gardant une bonne indentation du code en suivant les conventions de GNOME ([certains outils](https://wiki.gnome.org/GnomeLove/Tools-C-language) existent, mais renommer une classe reste quand même fastidieux). Un autre désavantage du C en général : la gestion manuelle de la mémoire, bien sûr. Je vois par contre de nombreux avantages : * C'est un langage à typage statique, l'étape de compilation permet d'éviter plein d'erreurs triviales, qu'il serait parfois difficile de trouver à l'exécution (par exemple du code qui est exécuté quand le disque dur est plein). Pour la maintenabilité du code, c'est important. * C'est aussi un langage à typage explicite : le type est visible dans le code. Le type d'une variable est une forme d'auto-documentation. * Les nombreux outils pour le C : gdb, valgrind, éditeurs de texte, ... * Une bonne « greppabilité » du code. Par exemple `gtk_widget_show()` contient le _namespace_ (gtk), le nom de la classe (widget), et le nom de la méthode (show). Dans un langage orienté objets, c'est généralement `object.show()`. Si on recherche dans le code seulement « show », on se retrouvera surement avec de faux positifs. Avec grep, en C, on peut aussi se retrouver avec de faux positifs, mais tant qu'on ne crée pas de script automatisant une tâche, ça ne pose pas de problème. Sinon, un IDE peut utiliser la libclang pour avoir une connaissance parfaite du code. Pour C++, Java ou autre, il faut d'office passer par ce genre d'outil, grep ne suffit pas. D'autre part, le fait d'avoir le _namespace_ et le nom de la classe est aussi une forme d'auto-documentation. * Lorsqu'on développe une application, il arrive un jour qu'on ait envie de rendre notre code réutilisable. Si c'est du C, il est plus facile de créer une bibliothèque qui soit utilisable par plein d'autres langages (voir paragraphe suivant). # Python # Grâce à [GObject-introspection](https://wiki.gnome.org/Projects/GObjectIntrospection), les bibliothèques basées sur GObject sont disponibles pour d'autres langages tels que Python et JavaScript. Quand GObject-introspection n'existait pas, des _bindings_ devaient être créés et maintenus, comme par exemple PyGTK pour permettre d'utiliser GTK+ en Python. Maintenant, cela se fait de manière automatique. Par contre, il n'est pas possible d'écrire une bibliothèque en Python et de l'utiliser en C (avec GObject-introspection en tout cas). Si on me demandait mon avis (ça tombe bien, je suis en train d'écrire ce journal), je dirais que Python ne devrait être utilisé que pour des scripts, des _plugins_ ou petites applications, qui ne dépassent pas les 1000 lignes de code, disons. Pour un logiciel plus gros, il faut écrire plein de tests unitaires pour assurer une bonne maintenabilité. Les tests unitaires ne règlent néanmoins pas le problème de la moins bonne auto-documentation du code. Autre chose, en C, pour savoir si on utilise des fonctions obsolètes de GTK+ (exemple pris de manière tout à fait non-fortuite), une simple compilation suffit. En Python, c'est à l'exécution que les warnings apparaissent (un pythoneux peut peut-être éclairer ma lanterne ici, existe-t-il un outil pour avoir ce genre de warnings automatiquement ? Et pour faire un recherche intelligente dans le code, si on cherche les appels à une certaine fonction par exemple ?). # Vala # C'est un langage créé pour faciliter l'usage de GObject. Les spécificités de GObject sont intégrées directement dans la syntaxe du langage, qui est assez proche du C#. Le compilateur valac transforme le code [Vala](https://wiki.gnome.org/Projects/Vala) en langage C, pour être ensuite compilé avec GCC, Clang, ou autre. Vala est un bon langage pour débuter dans GNOME, je dirais. Pour les développeurs plus expérimentés, ça convient bien aussi pour une petite application. Mais quand on en fait une utilisation plus poussée, Vala montre ses limites : * quelques bugs du compilateur ; * pour débugger, le _print-debugging_ est plus pratique que de lancer un débuggeur sur le code C généré. Pour avoir une backtrace lors d'un crash, il faut donc faire la traduction inverse C -> Vala. La _toolchain_ n'est donc pas très bonne. Ceci dit, Vala a l'avantage de pouvoir créer une bibliothèque basée sur GObject-introspection, puisque le code est transformé en C. Il est donc tout à fait possible d'utiliser en C ou en Python du code qui est écrit en Vala. Mais l'utilisation d'une bibliothèque Vala en C n'est parfois pas très naturelle (par exemple la [libgee](https://wiki.gnome.org/Projects/Libgee)). Voilà les raisons pour lesquelles je préfère le C, actuellement. C'est un langage d'un peu plus bas niveaux, mais cela donne une impression de bien maitriser ce que l'on fait. Un peu comme un utilisateur de Gentoo, il a une impression de bien maitriser sa distrib, puisqu'il a une meilleure connaissance de ce qui est installé sur son système. Mais bon, c'est assez subjectif.

AltStyle によって変換されたページ (->オリジナル) /