Résumé

Je viens de créer ma première application Web en lua.

Pour ceux qui ne savent pas ce que c’est : google est votre ami, mais pour résumer :

• Wikipedia : Lua est un langage de script libre, réflexif et impératif.
• Le site officiel est ici..

Je commence par les inconvénients parce qu’ils sont tellement particuliers qu’il faut les avoir en tête avant d’aller plus loin. Si jamais ça ne vous rebute pas trop, lisez les avantages et ce sera à vous de juger, si, en mettant le tout sur votre balance, ça penche plus vers le positif ou vers le négatif.

En résumé, tous les avantages qui suivent font que, même s’il faut pas mal se débrouiller au début parce qu’il manque beaucoup d’outils « déjà faits », au final le langage est tellement lisible qu’on arrive assez rapidement à se faire ses outils, et en allant un peu plus loin, la maintenance (qui est la chose la plus coûteuse sur les grosses applications) se retrouve améliorée au lieu d’être dégradée. Après, c’est un constat qui n’engage que moi, mais de très grosses applications, notamment nmap tournent d’ores et déjà avec une liste faramineuse de plugins, tous écrits en lua, et facilement compréhensibles.

Inconvénients

Voici les inconvénients de base, qui ne sont pas propres au langage :

• il faut tout faire soi-même :
  • aucune gestion avancée des fichiers (de base, sans aucun module complémentaire, il ne sait même pas dire si un fichier existe ou pas)
  • côté Web, aucune gestion des sessions
  • côté Web, rien de base en ce qui concerne le json (j’ai plus d’une demi journée à chercher une implémentation entièrement potable de json)

Voici les inconvénients du langage même :

• Il ne connait pas les classes d’origine, il faut faire un hack pour « simuler » des classes
• Par conséquence, il n’y a aucune notion d’héritage, à moins de hacker là aussi.
• Tous les entiers sont des flottants par défaut
• Aucune possibilité de trace simple. Si on veut remonter dans la pile d’appels, on ne peut sortir qu’une seule ligne (on précise le niveau de la pile)
• Toutes les variables sont globales par défaut, sauf si on précise systématiquement local
• La syntaxe permet des horreurs innommables : si jamais on ne passe qu’un seul paramètre, les parenthèses ne sont pas obligatoires, ce qui donne quelque chose de possible comme : mafonction{a=12,b=13}
• Les séparateurs ne sont pas clairement définis – et c’est volontaire pour permettre plus de liberté, donc on peut écrire ceci : local a = { b=15; c=23 } ou ceci : local a = { b=15, c=23 }. Imaginez le problème… On voit déjà qu’en Php, en laissant un peu de liberté, on arrive à un bazar gigantesque à l’échelle planétaire, je vous raconte même pas ce qu’il est possible de faire ici
• Les packages en tant que tel n’existent pas, et il faut là aussi faire des bidouilles pour « simuler » des packages
• Il y a ici aussi, comme en JavaScript, la notion de « closure » afin de pouvoir faire sortir des variables hors d’un contexte d’où elles ne sont pas censées sortir. Certains voient les closures comme un avantage, moi qui ait programmé en C – et un peu en C++ – je vois les closures comme une solution pour pallier à un défaut du langage, en bidouillant.
• Le signe différent n’existe pas sous la forme classique <> ou encore != mais il s’écrit ainsi : ~=
• Pour supprimer une variable (unset() en Php), il faut la mettre à nil. Bizarre. Supprimer l’indice 12 : a[12] = nil
• Attention tenez vous bien j’ai gardé le pire pour la fin : les indices des tableaux commencent à 1. Ce n’est pas une blague. En C, C++, Java, JavaScript, Python, bref, dans tous les langages que je connais, les indices de tableau commencent à 0, et là non, ils commencent à 1. C’est à la limite la seule et unique chose qui me rebute énormément tellement c’est problématique, car, de plus, une des grosses forces mises en avant du lua, c’est le fait qu’il gère extrêmement bien les tables. Oui, mais les indices des tableaux commencent à 1.

Avantages

Je ne sais pas pourquoi, mais lua me plaît. Et je pense que tous les développeurs qui aiment bien ce langage sont un peu comme moi. Il a énormément d’inconvénients, pourtant il des côtés tellement pratiques qu’au final, on l’aime bien. Un peu comme moi (…).

Parmi les avantages que j’apprécie particulièrement :

• Pas d’accolades ouvrantes / fermantes, mais juste le début d’une déclaration (function, if, ou for), et la fin avec un end. C’est juste plus lisible qu’ouvrir des accolades et fermer des accolades (et croyez moi, je m’y connais bien dans ce domaine !)
• Les assignations multiples : il est possible d’assigner plusieurs choses en une seule ligne, et ça reste lisible (j’insiste sur ce dernier point : ça reste lisible). Exemple concret : a, b = b, a;. Ce code va inverser les deux valeurs.
• Même chose que précédemment mais pour les fonctions : elles peuvent renvoyer plusieurs valeurs, et par là même, on peut faire plusieurs assignations et ça reste lisible. Exemple simple : x, y = getCoordonneesJoueur(); ou plus classique handle, error = ouvrirFichier(nomfichier). Avec ce dernier code, si handle vaut nil alors on affiche error qui est rempli.
• Machine virtuelle : il tourne systématiquement dans une machine virtuelle, ce qui implique par là même une impossibilité technique de défaillance, et c’est vous-même qui précisez, pour les modules qui tourneront, quelles sont les fonctions sont accessibles – ou pas. Si la NASA se sert activement de LUA ce n’est pas pour rien. Ce qui me permet d’enchaîner sur le point suivant.
• Un des gros intérêts est de pouvoir créer des plugins, les lire et les interpréter, un peu comme en Php, eval(). Comme ces plugins sont dans une machine virtuelle très stable et éprouvée, vous pouvez mettre en place un système de plugins très performant, efficace et stable. Rien que le fait de pouvoir faire cela peut être une motivation pour apprendre le lua, car il y a très peu de langages qui tournent de manière aussi sécurisée, et aussi rapidement que lua (voire aucun).