1 files changed, 153 insertions, 0 deletions
diff --git a/content/Informatique/vala.rst b/content/Informatique/vala.rst
new file mode 100755
index 0000000..7ca8e8e
--- /dev/null
+++ b/content/Informatique/vala.rst
@@ -0,0 +1,153 @@
+.. -*- mode: rst -*-
+.. -*- coding: utf-8 -*-
+
+Présentation de Vala
+####################
+
+:date: 2010-06-11
+:tags: Libre, Programmation
+
+J'ai découvert une présentation du langage dans GLMF n°127 qui
+l'utilisait pour se brancher sur le pare-feu. Cela ayant aiguisé ma
+curiosité, j'ai cherché à en savoir davantage sur le langage. Le langage
+C m'a toujours paru difficile à aborder. Non pas au niveau de sa
+syntaxe, mais au sujet de l'accès à sa documentation et aux librairies
+disponibles. Pour moi qui suis habitué à Java ou à Python, j'ai regardé
+Vala comme un moyen de mettre un pied dans le C. Je vais essayé de
+présenter ma manière de le voir, après avoir fait une petite plongée
+dedans…
+
+Présentation
+~~~~~~~~~~~~
+
+Le langage Vala à été créé par les développeurs de Gnome pour qu'ils
+puissent disposer d'un langage de haut niveau. Gnome ayant eu pendant
+quelques temps un pied ( dansant ) dans mono, Vala en est très inspiré.
+( Je ne connais pas mono et ne peux donc pas lancer de comparatif, je
+vous renvoie donc à celui présenté par Gnome `par rapport à
+C# <http://live.gnome.org/Vala/QuickIntroForCSharpProgrammers>`_, et
+pour `Java <http://live.gnome.org/Vala/ValaForJavaProgrammers>`_ ). Le
+langage est ensuite compilé en C, et GCC est utilisé pour la compilation
+d'un exécutable. On est donc dans un langage intermédiaire, qui reste
+très proche du C comme nous allons le voir par la suite.
+
+Analyse
+~~~~~~~
+
+Langage objet haut niveau Vala est tout d'abord un langage haut niveau :
+on y retrouve des *interface* ( pour pouvoir moduler le code facilement
+), des *delegate* ( qui permettent de de définir un type de fonction
+pour un callback ), une gestion *événementielle* ( gérer le
+déclenchement de plusieurs méthodes dans le code par un appel unique ) …
+On dispose donc d'un langage objet assez riche pour éviter d'avoir
+passer du temps sur des détails et se concentrer sur le programme et son
+déroulement. Il est pensé objet et l'on retrouve vite ses marques, tout
+comme l'on sent qu'il est assez facile d'« abstraire » le code pour
+faire une application qui n'en reste pas un simple script… Je n'ai pas
+envie de détailler la syntaxe du langage et tout ce qu'il intègre car
+vous pourrez trouver tout cela en ligne. Je vous renvoie au
+`tutoriel <http://live.gnome.org/Vala/Tutorial>`_ qui explique la
+structure du langage en détail, qui présentent des exemples détaillés.
+La GLib Le langage est basé sur la GLib, la librairie standard utilisé
+dans les applications GTK. La plupart des types primitifs ( int… ) sont
+donc en réalités des types issus de cette librairie ( gint…). On accède
+ainsi à l'ensemble des méthodes de la GLib, diffusées sous formes de
+classes objets et bien documentées ( la
+`valadoc <http://valadoc.org/index.html>`_ ). Cela rejoint l'histoire de
+Vala puisque La GLib est tout utilisée par les développeurs Gnome ( on
+constate d'ailleurs que la plupart des composants Gnome ont une entrée
+dans cette Valadoc ). Il ne faut cependant pas croire que l'on dispose
+avec cette bibliothèque standard d'un ensemble de routines aussi riche
+que dans le package standard d'un Java ou d'un Python : la GLib est
+avant tout destinée à des développeurs C, et beaucoup des méthodes
+standard du C n'y sont pas disponibles. Pour parer cela, Vala propose
+une classe POSIX[LIEN] proposant les méthodes standard du C, mais
+celle-ci n'est pas exhaustive et il nous arrive souvent de tomber sur
+une fonction qui ne nous est pas accessible via le langage haut niveau
+qu'est Vala. Les Bindings Pour répondre à cela, propose la possibilité
+de mettre en place un binding vers une libraire C de manière native. (
+Normal me direz vous, le code en sortie de Vala est du C ! ) On peut
+donc très facilement utiliser n'importe quelle libraire existante. Vala
+étant un langage objet, il devient donc possible d'utiliser les
+librairies standard au sein d'un code objet de haut niveau. Cela ne
+demande que quelques lignes, demandant au minimum le fichier dans lequel
+se trouve la définition de la méthode, et sa signature. Exemple du
+binding définissant la méthode execl ( issue du fichier
+/usr/share/vala/vapi/posix.vapi ) :
+
+::
+
+    [CCode (cheader_filename = "unistd.h")]
+    public int execl (string path, params string[] arg);
+
+et voici la signature de la méthode C correspondante :
+
+::
+
+    extern int execl (__const char *__path, __const char *__arg, ...) __THROW __nonnull ((1));
+
+Les types primitifs de la GLib étant basés sur les types primitifs C
+correspondant, il n'y a pas de problème de cast dans la plupart de cas.
+Toutefois, Vala utilise des char\* pour définir ses string : il est
+parfois nécessaire de mettre en place faire un cast quand une méthode
+nous un char[] : même dans le code haut niveau, le C n'est jamais loin…
+C'est souvent frustrant de devoir mettre en place un binding pour une
+fonction disponible en standard dans la libc. Je pense qu'il manque la
+possibilité d'inclure directement du code C dans le code vala, tout
+comme il est possible directement de l'assembleur dans du C. Cela
+permettrait un confort dans l'utilisation qui n'est pas disponible
+actuellement. À noter qu'un outil permet de mettre en place ces bindings
+pour les composants basés sur GObjet ( Gnome toujours… ). De plus de
+nombreux bindings sont disponibles pour les composants Gnome. Attention,
+cela n'empêchera pas d'avoir à installer les headers C correspondants !
+Les profils Il est possible d'utiliser des profils de compilation. Cette
+option encore expérimentale a été mise en place pour répondre à des
+réclamations de la part des utilisateurs qui voulaient programmer en
+Vala sans avoir de dépendances envers la GLib. Ainsi, il est possible
+d'appeler le compilateur avec la syntaxe suivante :
+
+::
+
+    valac --profile posix
+
+ce qui a pour conséquence de réduire le jeu de bibliothèque par défaut à
+celles disponibles dans la classe POSIX. Cela permet de limiter les
+dépendances du programmes, mais beaucoup de types standard de Vala
+deviennent de ce fait indisponible; on sent bien que le langage n'a pas
+été pensé pour ça.
+
+Conclusion
+~~~~~~~~~~
+
+Pour résumer, je dirais que Vala correspond à ce qu'il annonce : un
+langage haut niveau pour faciliter la création d'applications Gnome. Dès
+que l'on cherche à sortir de ce cadre, on se retrouve confronté à des
+limitations ( qui ne sont bien sûr pas insurmontable ) :
+
+-  Pour ceux qui ne cherche pas à travailler sur du code Gnome,
+   embarquement de bibliothèques qui ne nous intéressent pas forcement.
+   ( Bien que sur ce point, la GLib est plutôt standard sur les PCs
+   ayant X d'installés )
+-  Pour ceux qui cherchent un langage de haut niveau, le C est encore
+   trop présent entre les lignes pour pouvoir l'oublier complètement.
+   D'un autre côté, l'intégration du code C n'est pas toujours évidente
+   puisqu'elle oblige à déclarer des bindings pour des fonctions
+   standards.
+-  Mais surtout, le fait que l'ensemble des fonctions de la libc ne
+   soient pas encore disponibles oblige à mettre le doigt dans les
+   bindings régulièrement.
+
+Le langage est bien sûr encore amené à évoluer, et les points que je
+cite ici ne sont pas pour autant rédhibitoires. D'un point de vue
+totalement subjectif Je trouve le langage simple mais sans trop de
+saveur. Ça reste un langage objet qui n'est bien sûr pas
+révolutionnaire; on sent qu'il ne fait que reprendre les concepts des
+langages qui l'ont inspiré, mais le produit est cohérent, et d'après les
+benchs génère un code plutôt optimisé ( en rapport avec le temps que
+l'on pourrait passer à produire le même code en C ). Après, je ne prend
+pas le même plaisir à programmer en Vala qu'en python ( j'avais bien dit
+que j'étais subjectif ^^ ). Cela dit, pour moi, qui ne suis pas un
+développeur Gnome, je suis plus intéressé par la possibilité d'avoir un
+langage haut niveau qui reste très proche du C, avec les performances
+qui vont avec; si le prix pour cela est une dépendance vers la GLib, ça
+reste un coût sommes toutes assez faible.