Je suis l'auteur original du binding Lua-SDL2, je l'ai commencé globalement quand Lua 5.2 est sorti et donc j'ai rajouté de la compatibilité pour Lua 5.1 et pour Lua 5.3 et pour Lua 5.4.
Les 3 développeurs (parce que Lua n'accepte pas les patchs ni les contributeurs externes) cassent l'API C et l'API Lua à chaque version sans aucun guide précis de migration et comme il n'y a pas de SCM public, vous perdez un temps fou à la sortie d'une nouvelle version pour mettre à jour vos modules et rajouter une trentaine de #ifdef de compatibilité. D'ailleurs, c'est bien pour ça que même les modules connus comme LuaSocket étaient pendant très longtemps en retard sur les nouvelles versions et de manière générale c'est souvent le cas pour les autres modules. Malgré cela beaucoup continuent d'utiliser ce langage est finissent emprisonnés par ce problème. La solution la plus adéquate : embarquer une version du langage dans votre logiciel puis fournir la documentation de cette version précise et espérer que personne ne s'en plaigne. Exemple : löve est toujours basé sur du Lua 5.1 (parce que LuaJIT est encore sur du 5.1)
J'ai beaucoup aimé Lua au début mais avec l'émergence d'ECMAScript 6 et versions ultérieures qui font Javascript un bien meilleur langage qu'auparavant; je ne comprends pas l'intérêt de continuer un langage qui n'offre plus grand chose à part des inconvénients majeurs.
À part ça, il y a beaucoup de choses qui sont bizarres et sont choisies arbitrairement :
La syntaxe du non-égal est ~=, dans la plupart des cas on considère ça comme « approximativement égal ».
Les développeurs sont fortement contre l'ajout du mot clé continue, alors ils ont rajouté le terrible goto. Par contre break existe.
Les tableaux commencent à 1. Oui il est possible d'utiliser un tableau avec un indice de 0, voire -1 mais l'API Lua ne fonctionnera pas avec.
Mélanger les structures clé-valeur avec les tableau dans la même syntaxe est une bonne chose sur le papier, mais dans la réalité c'est plutôt merdique (voir # et tableaux à trous).
Pas d'expression régulière, mais un format maison bien plus limité.
Pas de fonctionnalité modernes comme le pattern matching ni de switch case amélioré.
Les chaînes sont des « objets », mais pas les tableaux.
Je ne peux que conseiller de bien réfléchir avant d'utiliser Lua, à moins que perdre votre temps ou utiliser 3 versions de retard ne vous rebute pas.
git is great because linus did it, mercurial is better because he didn't
Un truc qui m'a toujours semblé un peu une mauvaise idée (d'un point de vue maintenance) dans lua et que tu ne mentionnes pas, c'est le fait que les variables sont globales par défaut et qu'il faut utiliser local, plutôt que le comportement inverse (un global à la Tcl ou Python).
Les développeurs sont fortement contre l'ajout du mot clé continue, alors ils ont rajouté le terrible goto. Par contre break existe.
Le goto est une version très restreinte (un peu comme en Go, c'est un goto sans vraiment l'être), donc qui évite les cas vraiment problématiques qui lui valent une mauvaise réputation, non ?
Pas d'expression régulière, mais un format maison bien plus limité.
Pour le coup, ça c'est assez compréhensible pour un langage qui se veut petit et d'extension : un moteur d'expression régulières un peu moderne représenterait probablement autant de code que le reste de l'interpréteur, et un moteur trop simpliste donnerait de mauvaises performances.
Ça a aussi l'avantage d'être plus facile à apprendre que les regexps, plus clair dans les cas simples. Un des objectifs de lua est d'être facilement modifiable par des personnes avec peu d'expérience en programmation.
Un truc qui m'a toujours semblé un peu une mauvaise idée (d'un point de vue maintenance) dans lua et que tu ne mentionnes pas, c'est le fait que les variables sont globales par défaut et qu'il faut utiliser local, plutôt que le comportement inverse (un global à la Tcl ou Python).
Oui c'est vrai je l'avais oublié. Pour ma part j'ai rarement été affecté par ce choix de décision donc je dois avouer que ça ne m'a pas dérangé tant que ça mais je peux le comprendre.
Le goto est une version très restreinte (un peu comme en Go, c'est un goto sans vraiment l'être), donc qui évite les cas vraiment problématiques qui lui valent une mauvaise réputation, non ?
C'est le même qu'en C, il permet de faire un saut local. Il n'est pas possible de faire un « long » saut de fonction à fonction comme setjmp et il n'est pas possible de stocker des labels de goto non plus. Je pense que ça aurait pu avoir un quelconque intérêt de rajouter les goto si les labels étaient des objets de première classe.
Pour le coup, ça c'est assez compréhensible pour un langage qui se veut petit et d'extension : un moteur d'expression régulières un peu moderne représenterait probablement autant de code que le reste de l'interpréteur, et un moteur trop simpliste donnerait de mauvaises performances.
Oui c'est ce qu'ils ont indiqué dans leur livre. Mais utiliser un format spécial plutôt que rester proche des vrai regex fait qu'on doive apprendre une nouvelle syntaxe quand même. Bon l'avantage est qu'il n'y pas besoin de faire des échappement du style \d -> \\d comme en C.
git is great because linus did it, mercurial is better because he didn't
C'est le même qu'en C, il permet de faire un saut local. Il n'est pas possible de faire un « long » saut de fonction à fonction comme setjmp et il n'est pas possible de stocker des labels de goto non plus.
Et il n'est pas possible de faire un jump qui fait rentrer dans la portée lexicale d'une variable locale, ce qui enlève quand même une source majeure de mauvaises surprises.
# Mes frères
Posté par antistress (site web personnel) . Évalué à 10.
Allez Lua !
# Pas vraiment
Posté par David Demelier (site web personnel) . Évalué à 10. Dernière modification le 14 février 2021 à 09:25.
Je suis l'auteur original du binding Lua-SDL2, je l'ai commencé globalement quand Lua 5.2 est sorti et donc j'ai rajouté de la compatibilité pour Lua 5.1 et pour Lua 5.3 et pour Lua 5.4.
Les 3 développeurs (parce que Lua n'accepte pas les patchs ni les contributeurs externes) cassent l'API C et l'API Lua à chaque version sans aucun guide précis de migration et comme il n'y a pas de SCM public, vous perdez un temps fou à la sortie d'une nouvelle version pour mettre à jour vos modules et rajouter une trentaine de
#ifdef
de compatibilité. D'ailleurs, c'est bien pour ça que même les modules connus comme LuaSocket étaient pendant très longtemps en retard sur les nouvelles versions et de manière générale c'est souvent le cas pour les autres modules. Malgré cela beaucoup continuent d'utiliser ce langage est finissent emprisonnés par ce problème. La solution la plus adéquate : embarquer une version du langage dans votre logiciel puis fournir la documentation de cette version précise et espérer que personne ne s'en plaigne. Exemple : löve est toujours basé sur du Lua 5.1 (parce que LuaJIT est encore sur du 5.1)J'ai beaucoup aimé Lua au début mais avec l'émergence d'ECMAScript 6 et versions ultérieures qui font Javascript un bien meilleur langage qu'auparavant; je ne comprends pas l'intérêt de continuer un langage qui n'offre plus grand chose à part des inconvénients majeurs.
À part ça, il y a beaucoup de choses qui sont bizarres et sont choisies arbitrairement :
continue
, alors ils ont rajouté le terriblegoto
. Par contrebreak
existe.#
et tableaux à trous).Je ne peux que conseiller de bien réfléchir avant d'utiliser Lua, à moins que perdre votre temps ou utiliser 3 versions de retard ne vous rebute pas.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas vraiment
Posté par anaseto . Évalué à 4.
Un truc qui m'a toujours semblé un peu une mauvaise idée (d'un point de vue maintenance) dans lua et que tu ne mentionnes pas, c'est le fait que les variables sont globales par défaut et qu'il faut utiliser
local
, plutôt que le comportement inverse (unglobal
à la Tcl ou Python).Le
goto
est une version très restreinte (un peu comme en Go, c'est un goto sans vraiment l'être), donc qui évite les cas vraiment problématiques qui lui valent une mauvaise réputation, non ?Pour le coup, ça c'est assez compréhensible pour un langage qui se veut petit et d'extension : un moteur d'expression régulières un peu moderne représenterait probablement autant de code que le reste de l'interpréteur, et un moteur trop simpliste donnerait de mauvaises performances.
Ça a aussi l'avantage d'être plus facile à apprendre que les regexps, plus clair dans les cas simples. Un des objectifs de lua est d'être facilement modifiable par des personnes avec peu d'expérience en programmation.
[^] # Re: Pas vraiment
Posté par David Demelier (site web personnel) . Évalué à 3.
Oui c'est vrai je l'avais oublié. Pour ma part j'ai rarement été affecté par ce choix de décision donc je dois avouer que ça ne m'a pas dérangé tant que ça mais je peux le comprendre.
C'est le même qu'en C, il permet de faire un saut local. Il n'est pas possible de faire un « long » saut de fonction à fonction comme
setjmp
et il n'est pas possible de stocker des labels de goto non plus. Je pense que ça aurait pu avoir un quelconque intérêt de rajouter les goto si les labels étaient des objets de première classe.Oui c'est ce qu'ils ont indiqué dans leur livre. Mais utiliser un format spécial plutôt que rester proche des vrai regex fait qu'on doive apprendre une nouvelle syntaxe quand même. Bon l'avantage est qu'il n'y pas besoin de faire des échappement du style
\d
->\\d
comme en C.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Pas vraiment
Posté par anaseto . Évalué à 3.
Et il n'est pas possible de faire un jump qui fait rentrer dans la portée lexicale d'une variable locale, ce qui enlève quand même une source majeure de mauvaises surprises.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.