J'ai un projet côté serveur C ++ que j'ai besoin d'intégrer une sorte de script dans. Cela fait partie d'un type de serveur en ligne MMO. J'ai une expérience significative avec TCL, et cela ressemble à l'ajustement naturel. J'ai fait une quantité minimale de Lua dans mon jeu Dev jours et je me demande si cela pourrait être une meilleure langue pour les scripts intégrés. C'est aussi agréable d'apprendre une nouvelle langue. Quels sont les forces relatives et les faiblesses de TCL vs Lua? Merci!
6 Réponses :
Honnêtement, ils sont extrêmement bien adaptés à la tâche. Les deux sont faciles à intégrer dans une application et ont une syntaxe assez simple. Je sais pour un fait qu'il est extrêmement simple d'ajouter de nouvelles commandes (à interagir avec l'application) dans TCL, et je me suis dit que Lua est très bon à ce type de chose.
Ma recommandation serait de jouer avec Lua pendant un moment pour voir comment vous l'aimez (puisque vous savez déjà TCL) ... puis choisissez celui qui vous semble le plus confortable. Si vous écrivez une grande partie du code, vous vous enverrez beaucoup de travail avec elle, vous aurez donc besoin de quelque chose que vous pouvez utiliser. En fin de compte, les deux choix linguistiques doivent être assez faciles pour que vos utilisateurs finaux soient script.
Ma préférence personnelle est TCL, les deux parce que je n'aime pas la Lua (j'ai fait une quantité raisonnable de programmation de cela pour que Warcraft Addsons) et parce que j'aime TCL (j'ai fait beaucoup de programmation pour travail professionnel et privé).
Edit: Ajout de la note sur les deux faciles pour les utilisateurs finaux. A eu 2 votes en bas et ne pouvait penser à rien d'autre que cela pourrait être pour d'autres que de ne pas clarifier la raison de ma déclaration.
L'API Lua C est extrêmement facile à intégrer dans une application. De C, vous avez un accès complet à l'état Lua et à ses types de données natives. J'ai recommandé d'utiliser Lua juste pour obtenir la mise en œuvre de la table de hachage, même sans avoir besoin de script, par exemple.
Les fonctions Lua écrites en C peuvent être injectées en tant que noms globaux, collectées dans un tableau comme la plupart des fonctions de la bibliothèque standard, ou implémentées dans des DLL et de manière dynamique au moment de l'exécution. Cela permet à l'application de fournir une API stable, ainsi que de prendre en charge les plugins écrits dans LUA ou C.
Lua en tant que langue est étonnamment puissante, avec la prise en charge des styles de programmation fonctionnels et orientés objet. Il est également étonnamment léger: le kit source complet et la documentation complète convient parfaitement moins de 1 Mo, et l'ensemble des bibliothèques VM, compilateur et standard dans une DLL est à seulement 164 Ko sur Windows.
Je n'ai pas sérieusement examiné TCL depuis la version 2 ou donc ... je ne vais pas essayer de les comparer de manière concrète. Je crois qu'ils ont tous deux été inventés pour s'adapter à la même niche et à peu près au même moment. Ils sont certainement les deux langues mûres avec des communautés d'utilisateurs passionnaires.
Je soupçonne que TCL aura plus de bibliothèques que vous pourriez trouver nécessaires ou pratiques en cours de route.
Je suppose que je suis le contraire de rhseeeger là-bas. J'ai utilisé à la fois Lua et TCL intégré dans des jeux (jeux en ligne, accessoirement) et je ne toucherais pas de TCL avec un bargepole de 10 'si j'avais le choix. Mon opinion très subjective est que Lua est une langue sane et TCL n'est pas. Par rapport aux autres options pour les langages de script, la syntaxe TCL est très obscure à la plupart des gens, avec toutes les signes fixes et expr et dollar et beaucoup de crochets, etc. Le seul avantage objectif qu'il a fait la facilité d'intégration - mais Lua n'est pas une balle ce département non plus.
Si cette interface de script est purement pour vous, vous pouvez aussi bien aller avec TCL car Lua ne vous offrira rien de nouveau (sauf si l'orientation de l'objet n'est votre erreur). Dans les mains d'un utilisateur qualifié, TCL est un outil raisonnable. Si, toutefois, vous attendez des utilisateurs moins expérimentés à utiliser le système, utilisez-le avec LUA - la syntaxe plus simple les achètera beaucoup de productivité.
Je trouve cela amusant que nous puissions avoir des opinions aussi opposées. Tout ce que vous dites fait que Lua mieux que TCL est quelque chose que je dirais que TCL mieux que Lua. La syntaxe de TCL pour moi est considérablement plus propre et plus évidente que celle de Lua, etc.
Je suis d'accord avec RheEeeger sur le commentaire selon lequel "ce que tu dis à propos de Lua, je dirais à propos de TCL". Vous (Kylotan) dit que vous pensiez que Lua était meilleur pour les utilisateurs moins expérimentés, mais je pense aussi que c'est en arrière. Le principal problème avec TCL OMI est que les programmeurs expérimentés portent trop de bagages - attentes sur la manière dont une langue devrait fonctionner. TCL n'est pas conventionnel en raison de sa simplicité, mais cette simplicité est sa force. Tout ce que vous devez savoir sur TCL peut être exprimé sur une seule page Web.
C'est sur le point de se débarrasser de «guerres de langue». Je pense que c'est une question du bon outil pour le travail, et la syntaxe de côté, les deux outils dans ce cas sont presque également adaptés, mais à mon avis, TCL gagne en raison de sa maturité et de ses bibliothèques; En effet, Lua semble notoirement semaine dans ce département. En ce qui concerne la syntaxe, oui Lua's peut sembler plus familier, presque basique / python-esque, et cela pourrait en effet être une force. Mais pour ceux qui n'ont rayé que la surface de TCL, je vous exhorte: grattez plus profondément. Lorsque vous «l'obtenez», il est pratiquement au même niveau que «Obtenir» Lisp ou Haskell.
J'ai admis et déclarer que mon opinion était subjective et que TCL est parfaitement bon pour quelqu'un qui le sait. Cependant, dans le domaine des scripts de jeux, le type de personne qui le fera sera plus familier avec les simples langues impératives grand public telles que VBScript et JavaScript et seront loin des programmeurs avancés qui peuvent tirer le meilleur parti de Haskell ou Lisp. C'est juste ce que j'ai vu sur le terrain et est en grande partie sans rapport avec la puissance de TCL comme langue.
Oh, et sur le point de la bibliothèque - souvent pour les scripts de jeu, vous ne souhaitez pas explicitement exposer des bibliothèques externes au script, pour des raisons de performance, de maintenance ou de sécurité. Encore une fois, tout dépend de qui écrira les scripts et, espérons-le, c'est quelque chose que l'affiche originale examinera.
Du côté du client, non, vous ne voudriez pas beaucoup de support de bibliothèque, mais sur le serveur, où tous les codeurs / utilisateurs sont approuvés, il est au pire inoffensif et éventuellement très utile.
Même le côté serveur, il peut être risqué, car les utilisateurs ne sont pas nécessairement ingénieurs logiciels, mais souvent moins de concepteurs techniques. Ces utilisateurs ne peuvent pas toujours être conscients d'être conscients des conséquences complètes de certains appels de système, etc. Par conséquent, vous les avez souvent de fonctionner uniquement dans l'interface Sandboxed que vous les fournissez. Évidemment, la vérité de cela dans l'affaire de l'OP dépendra de sa situation particulière, mais de manière générale, une langue de script intégrée dans un jeu est là pour la syntaxe et non pour les bibliothèques.
@Kylotan Lua a si quelque chose de syntaxe plus complexe que TCL, cela semble être un malentendu courant de TCL, les gens en train de lire davantage que ce n'est vraiment là. Cela dit que vous avez toujours peut-être raison que Lua soit plus sympathique sympathique en tant que syntaxe simple TCLS semble être simple pour beaucoup pour vraiment grok
@JK: Je comprends certainement ce que vous voulez dire, dans cette TCL, un nombre élégamment petit de règles qui dictent comment elle fonctionne. Mais il repose sur la ponctuation et le formatage bien formés plutôt que sur des mots-clés en anglais qui seul le rend moins sympathique pour le débutant (langue anglaise!). A MON HUMBLE AVIS.
Comme d'autres ont déclaré, les deux langues fonctionnaient très bien. Une troisième option qui fonctionnerait probablement probablement à peu près aussi est JavaScript, car elle s'adapte à peu près au même la même niche. Au lieu d'essayer de vous mener à l'un ou de l'autre (comme j'aime beaucoup les deux langues), je vais essayer de me concentrer sur certaines des différences objectives et soulignez-vous où je pense que l'une est en avance sur l'autre.
Le problème le plus important dans un serveur de jeu sera probablement performant. Les deux langues sont matures et bien optimisées, mais les deux reconnaissent également que certains problèmes sont mieux optimisés par le report du code compilé. Les deux langues utilisent fondamentalement le même mécanisme pour l'exécuter. Du point de vue des langues elles-mêmes, on dirait que Lua est un peu plus rapide. lien
du point de vue des bibliothèques, qui est le prochain facteur important, aucune autre langue ne nécessite que l'utilisation des bibliothèques ne soit utile; c'est-à-dire que les deux langues sont très compactes, par rapport aux langues telles que Java, qui nécessitent des grandes bibliothèques d'exécution pour être utiles; Encore une fois, il s'agit d'une conséquence de leurs exigences de conception originales. Les deux langues ont des bibliothèques complémentaires abondantes à choisir, mais c'est mon impression au moins que TCL a un peu plus de variété dans cette catégorie. TCL :( Archive d'extension TCL / Rételage TCL ) Lua: ( LuaForge )
Une autre différence est entre les langues principales elles-mêmes. La simplicité de la valeur des deux langues sur le style, mais c'est là que se termine la similitude. Lua utilise ce qui pourrait être une syntaxe familière à la plupart des programmeurs, avec une grammaire sans contexte très simple. La syntaxe TCL est également simple, mais n'a rien de commun avec d'autres langues existantes, bien qu'elle ait l'air superficiellement un peu comme la langue de la coquille Unix. TCL n'est probablement que plus facile sur les non-programmeurs car sa syntaxe de commande orientée de ligne est assez claire, mais les programmeurs expérimentés dans d'autres langues s'opposent généralement à sa syntaxe d'arcanes. Ni l'un ni l'autre n'utilisent terriblement pardonnant en termes de génération de code, mais les deux ont des installations de métaprogramming fortes (comparables, mais ne sont peut-être pas aussi robustes que CLISP Macros).
JavaScript pourrait avoir l'avantage de connaître des codeurs occasionnels, mais a définitivement l'inconvénient des bibliothèques d'exécution rares, au moins pour les implémentations C.
Lua a Luajit , qui est un compilateur JIT qui atteint des vitesses C sur des boucles serrées et est utilisé pour des projets comme SnaBB Interrupteur , où la performance est critique (SNABB peut gérer des gigabits par seconde, tous traités par Luajit). Luajit dispose également d'un FFI qui permet d'accéder aux fonctions C sans écrire C code de stub.
PUC-Lua (la mise en œuvre standard) prend en charge la récupération de l'exécution de la mémoire. Ni Luajit ni TCL ne le font.