Un essai a déjà été fait chez NetBSD et ça mène à rien. Lua est un mauvais langage fait par trois développeurs qui s'intéressent qu'à eux faisant chaque version un cassage de l'API C et l'API Lua en plus d'avoir une dizaines de bizarreries.
Si vous voulez perdre du temps, foncez.
git is great because linus did it, mercurial is better because he didn't
Un essai a déjà été fait chez NetBSD et ça mène à rien.
Ici c'est pas un projet officiel, et ça a l'air d'avoir été fait principalement pour le fun.
Lua est un mauvais langage […]
Opinion totalement subjectif.
[…] fait par trois développeurs qui s'intéressent qu'à eux […]
C'est pas parce que le développement se fait de manière privée, sans accepter de contributions, que les devs ne s'intéressent qu'à eux même.
Et quand bien même, cela n'a aucun rapport avec la qualité du dit projet.
faisant chaque version un cassage de l'API C et l'API Lua
Entre chaque version majeure oui (si on oubli le 5. devant). Effectivement 5.4 a des incompatibilités avec 5.3, 5.3 avec 5.2, etc… Elles sont toutes documentées. Mais entre 5.4.0 et 5.4.1, jusque 5.4.6, pas de changement cassant.
C'est tout comme en Semantic Versionning, changement cassant -> nouvelle version majeure. Ce sont des choses qui arrivent dans absolument tout les projets.
Si vous voulez perdre du temps, foncez.
Personne n'a dit "allez utiliser ça en prod", surtout quand le cas d'usage est bien mieux répondu par eBPF.
C'est tout comme en Semantic Versionning, changement cassant -> nouvelle version majeure. Ce sont des choses qui arrivent dans absolument tout les projets.
Lua ne suit pas le semantic versioning et les versions sortent à dates aléatoires puis la dernière version rend la précédente obsolète. C'est précisément ce choix arbitraire qui fait la fragmentation et une tonne de modules qui sont compatible qu'avec une version très précise de Lua.
Ce n'est pas pour rien que plus personne se risque d'écrire des modules Lua, personne n'a envie de prendre le risque de se retrouver au pied du mur. C'était notamment le cas de LuaSocket qui a mis du temps à être disponible sur les nouvelles versions car pour le développeur ça nécessite de rajouter une quantité phénoménale de #ifdef/#endif dans son module natif et des if au runtime pour un module Lua.
C'est un langage destiné à être embarqué dans un processus hôte mais même comme ça c'est une plaie pour le développeur. Love est toujours basé sur Lua 5.1 avec des petits backports par là des versions plus récentes, par conséquent on est obligé de fournir la documentation pour une version précédente et la documenter soi même en cas de modifications.
Bref, un langage destiné à faire perdre du temps avec une syntaxe et des concepts farfelus, je déconseille à tout sain d'esprit.
git is great because linus did it, mercurial is better because he didn't
Rien de choquant la dedans. En fait, très peu de logiciels ont un rythme de sortie de version.
la dernière version rend la précédente obsolète.
Rien de choquant la dedans. Très peu de logiciels ont des "LTS" (long term support).
Bref, un langage destiné à faire perdre du temps avec une syntaxe et des concepts farfelus, je déconseille à tout sain d'esprit.
Oui, on a bien compris que tu n'aimes pas Lua et que tu le déconseille pour de la production. Mais ici, c'est un projet pour le fun, donc on s'en fou. Celui qui va partir en production avec ça mérites tout ce qui lui arrive.
Ça ne dit pas s'ils regrettent ou non. Au départ on pense que c'est une bonne idée parce que ça a été popularisé pendant les année 2010 et on se rend compte au fur et à mesure de tout ce qui est pénible. Julien Danjou en a déjà écrit des articles concernant Lua et pourquoi il regrette l'avoir mis dans awesome. Malheureusement il semble avoir supprimé son blog donc il faudrait chercher dans webarchive.
Lua est en déclin et ce n'est pas sans raison. Pour ceux qui downvotent, j'ai maintenu Lua pendant plusieurs années dans mon application ainsi que dans ma bibliothèque Lua-SDL2 (note : ce dépôt n'est plus à moi) et j'ai beaucoup aimé le langage au début. Il y a des concepts sympa, techniquement à l'époque c'était bien au dessus de Javascript puis quand j'en ai eu marre de maintenir des #ifdef de partout j'ai estimé que ça n'en valait pas la peine. À mon travail nous sommes entrain de le retirer pour les mêmes raisons (spoiler : l'idée ne vient pas de moi).
Maintenant nous avons des alternatives ayant des fonctionnalités plus modernes avec une garantie de rétro compatibilité (ECMAScript >= 7, le monumental quickjs en pur C et étant JIT pour ne citer que lui).
git is great because linus did it, mercurial is better because he didn't
Posté par jseb .
Évalué à 2.
Dernière modification le 24 avril 2024 à 11:55.
Ce qui a tué Lua, c'est LuaJit.
Ça a divisé la communauté comme jamais.
C'était le projet d'un seul homme (un peu comme quickjs).
Mike Pall a été embauché par Google et a officiellement arrêté (il continue à commiter pour le strict nécessaire de la maintenance, personne n'a pu/voulu reprendre le projet).
Même si Lua ne bouge plus trop non plus, ça a beaucoup divergé d'avec LuaJit qui est coincé entre 5.1 et 5.2.
Je le ressens comme ça. J'ai moi-même quelques libs perso en C , appellées depuis Lua, et je n'ai pas eu le « #ifdef » dont tu parles. J'ai dû changer quelques appels pour exposer la table de fonctions, mais c'est tout ce dont je me souvienne (il y a peut-être eu d'autres changements que j'ai oublié, j'ai plus ou moins arrêté ça vers la 5.3).
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
# Quelle idée
Posté par David Demelier (site web personnel) . Évalué à -1.
Un essai a déjà été fait chez NetBSD et ça mène à rien. Lua est un mauvais langage fait par trois développeurs qui s'intéressent qu'à eux faisant chaque version un cassage de l'API C et l'API Lua en plus d'avoir une dizaines de bizarreries.
Si vous voulez perdre du temps, foncez.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quelle idée
Posté par David Delassus (site web personnel) . Évalué à 2.
Ici c'est pas un projet officiel, et ça a l'air d'avoir été fait principalement pour le fun.
Opinion totalement subjectif.
C'est pas parce que le développement se fait de manière privée, sans accepter de contributions, que les devs ne s'intéressent qu'à eux même.
Et quand bien même, cela n'a aucun rapport avec la qualité du dit projet.
Entre chaque version majeure oui (si on oubli le
5.devant). Effectivement 5.4 a des incompatibilités avec 5.3, 5.3 avec 5.2, etc… Elles sont toutes documentées. Mais entre 5.4.0 et 5.4.1, jusque 5.4.6, pas de changement cassant.C'est tout comme en Semantic Versionning, changement cassant -> nouvelle version majeure. Ce sont des choses qui arrivent dans absolument tout les projets.
Personne n'a dit "allez utiliser ça en prod", surtout quand le cas d'usage est bien mieux répondu par eBPF.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Quelle idée
Posté par David Demelier (site web personnel) . Évalué à 1.
Lua ne suit pas le semantic versioning et les versions sortent à dates aléatoires puis la dernière version rend la précédente obsolète. C'est précisément ce choix arbitraire qui fait la fragmentation et une tonne de modules qui sont compatible qu'avec une version très précise de Lua.
Ce n'est pas pour rien que plus personne se risque d'écrire des modules Lua, personne n'a envie de prendre le risque de se retrouver au pied du mur. C'était notamment le cas de LuaSocket qui a mis du temps à être disponible sur les nouvelles versions car pour le développeur ça nécessite de rajouter une quantité phénoménale de
#ifdef/#endifdans son module natif et desifau runtime pour un module Lua.C'est un langage destiné à être embarqué dans un processus hôte mais même comme ça c'est une plaie pour le développeur. Love est toujours basé sur Lua 5.1 avec des petits backports par là des versions plus récentes, par conséquent on est obligé de fournir la documentation pour une version précédente et la documenter soi même en cas de modifications.
Bref, un langage destiné à faire perdre du temps avec une syntaxe et des concepts farfelus, je déconseille à tout sain d'esprit.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quelle idée
Posté par jseb . Évalué à 3.
Löve utilise préférentiellement Lua 5.1, car c'est la dernière version supportée par LuaJIT.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Quelle idée
Posté par David Delassus (site web personnel) . Évalué à 5. Dernière modification le 22 avril 2024 à 14:15.
Oui, c'est pour ça que j'ai dit "comme".
Rien de choquant la dedans. En fait, très peu de logiciels ont un rythme de sortie de version.
Rien de choquant la dedans. Très peu de logiciels ont des "LTS" (long term support).
Oui, on a bien compris que tu n'aimes pas Lua et que tu le déconseille pour de la production. Mais ici, c'est un projet pour le fun, donc on s'en fou. Celui qui va partir en production avec ça mérites tout ce qui lui arrive.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Quelle idée
Posté par steph1978 . Évalué à 2.
C'est vrai ça, quelle bande d'inconscients.
[^] # Re: Quelle idée
Posté par David Demelier (site web personnel) . Évalué à 3.
Ça ne dit pas s'ils regrettent ou non. Au départ on pense que c'est une bonne idée parce que ça a été popularisé pendant les année 2010 et on se rend compte au fur et à mesure de tout ce qui est pénible. Julien Danjou en a déjà écrit des articles concernant Lua et pourquoi il regrette l'avoir mis dans awesome. Malheureusement il semble avoir supprimé son blog donc il faudrait chercher dans webarchive.
Lua est en déclin et ce n'est pas sans raison. Pour ceux qui downvotent, j'ai maintenu Lua pendant plusieurs années dans mon application ainsi que dans ma bibliothèque Lua-SDL2 (note : ce dépôt n'est plus à moi) et j'ai beaucoup aimé le langage au début. Il y a des concepts sympa, techniquement à l'époque c'était bien au dessus de Javascript puis quand j'en ai eu marre de maintenir des
#ifdefde partout j'ai estimé que ça n'en valait pas la peine. À mon travail nous sommes entrain de le retirer pour les mêmes raisons (spoiler : l'idée ne vient pas de moi).Maintenant nous avons des alternatives ayant des fonctionnalités plus modernes avec une garantie de rétro compatibilité (ECMAScript >= 7, le monumental quickjs en pur C et étant JIT pour ne citer que lui).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Quelle idée
Posté par jseb . Évalué à 2. Dernière modification le 24 avril 2024 à 11:55.
Ce qui a tué Lua, c'est LuaJit.
Ça a divisé la communauté comme jamais.
C'était le projet d'un seul homme (un peu comme quickjs).
Mike Pall a été embauché par Google et a officiellement arrêté (il continue à commiter pour le strict nécessaire de la maintenance, personne n'a pu/voulu reprendre le projet).
Même si Lua ne bouge plus trop non plus, ça a beaucoup divergé d'avec LuaJit qui est coincé entre 5.1 et 5.2.
Je le ressens comme ça. J'ai moi-même quelques libs perso en C , appellées depuis Lua, et je n'ai pas eu le « #ifdef » dont tu parles. J'ai dû changer quelques appels pour exposer la table de fonctions, mais c'est tout ce dont je me souvienne (il y a peut-être eu d'autres changements que j'ai oublié, j'ai plus ou moins arrêté ça vers la 5.3).
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.