Journal De l'utilité d'un langage de script comme langage d'extension d'un logiciel.

Posté par  (site web personnel) .
Étiquettes : aucune
0
5
sept.
2007
Je me pose une question méta physique ce soir.

Quel est l'interet des langages de script intégré à certain logiciel ?

Je vois souvent lua qui est vanté pour sa simplicité d'intégration. TCL parfois pour le shell qu'il peut apporter. Je sais que Perl peut aussi être embarqué.

Je vois souvent que les comportements des objets dans des jeux video sont scriptés avec ces langages.

Je me demande quel est l'interet de tel extension. Quel avantage d'utiliser 2 langages au lieu d'utiliser le langage d'origine et de jouer avec des sortes de plugins ?

Un langage de script est un langage de plus à maitriser et de plus, il est souvent bien plus lent que le langage d'origine.

Bref, je demande à ceux qui ont déjà fait ce choix de me le commenter. Quelles sont les avantages, ils ont réellement vu ? quels inconveniants ? j'aimerais un peu de retour d'expérience.

  • # Python

    Posté par  (site web personnel) . Évalué à 6.

    Python aussi est pas mal utilisé, par exemple dans Civilization IV ou dans BF2 (Battle Field ?) et pas mal documenté :
    http://civilization4.net/files/modding/PythonAPI/

  • # recompilation...

    Posté par  (site web personnel) . Évalué à 10.

    Pour avoir participé à l'élaboration d'un soft comportant scripting _et_ plugins :
    Le script permet surtout de modifier le fonctionnement du programme
    - sans recompilation
    - à l'exécution

    Le premier point est celui auquel on pense le plus. Le deuxième peut être primordial dans certains cas où l'utilisateur doit faire lui-même ses scripts et dans ce cas la compilation est impossible puisqu'on veut pmême pouvoir changer à la volée, pendant l'exécution le fonctionnement initial

    Les plugins (qui peuvent aussi être des scripts...) sont la pour étendre le fonctionnement (rajouter des fonctionnalités bien déféinies)
    Le script est là pour agir sur les objets créés

    On utilisait aussi lua. Pourquoi ? Surtout car il est assez simple a intégrer dans un programme C++

    Pour moi l'inconvénient d'avoir plusieurs langages est assez faible. D'une part c'est parfois des personnes différentes qui travaillent sur les langages différents (sauf ceux qui font la glue au milieu...). D'autre part, il est pour moi important de justement découper en couches les différents éléments d'un soft et si on doit utiliser différents langages c'est encore mieux.
    Le cas classique est le noyau du programme écrit en c/c++ avec un accès à une base de donnée (sql) et dont la couche graphique est géré par un langage de script (ruby, python, lua, ...)
    Simplement car chaque langage a son domaine de prédiléction et qu'il est souvent une perte de temps importante de vouloir tout faire dans un seul langage

    • [^] # Re: recompilation...

      Posté par  (site web personnel) . Évalué à 2.

      Pourquoi une perte de temps ? Est-ce que avec autant de langage différent, cela ne tourne pas à l'usine à gaz ?

      Quel est l'avantage d'éviter la compilation, a part taper une commande de plus avant un lancement ?

      "La première sécurité est la liberté"

  • # Accès aux néophytes

    Posté par  (site web personnel) . Évalué à 4.

    Je programme en C/C++

    Pour un gars voulant m'aider un peu, qui n'y connais presque rien, ecrire un fichier texte avec un template et relancer le logiciel est bien plus simple que trouver un compilateur C++, compiler, tester, planter, recommencer.

    Moins puissant, mais ouverts aux néophytes.

  • # pour moi

    Posté par  . Évalué à 1.

    Je me suis récemment mis à utiliser python comme language de script.
    Pour moi le but est de réduire le temps de developpement de l'interface graphique de mes applications, le coeur de l'application restant en C/C++.
    Avantages :
    - répondre rapidement à des demandes de modification de l'interface graphique
    - faire plusieurs interface graphique differentes pour plusieurs produits differents utilisant le même coeur.
    - ne pas dépendre de l'os pour l'interface graphique. Le coeur étant construit de telle sorte à être portable.
    - modularisation de l'application.
    - garder les performances d'une application c++ alliée la rapidité de developpement de python.

    Inconvénients:
    - Maintenir la glue entre C++/Python (cependant automatisable après un certain travail en utilisant py++)

    Pourquoi pas de Plugins?
    Dans mon cas, un système de plugin ne correspond pas à mon besoin. Le but n'étant pas d'étendre les fonctionnalités.

  • # Exemple "à la con"

    Posté par  . Évalué à 4.

    Pourquoi Microsoft Office est scriptable en Visual Basic ?

    Voilà. Ca doit donner une idée de la réponse à la question initiale ;-)

    • [^] # Re: Exemple "à la con"

      Posté par  . Évalué à 9.

      Pour faire des virus plus rapidement, de façon plus ouverte aux néophytes, pour pouvoir vendre des antivirus.

  • # La solution

    Posté par  . Évalué à 1.

    Utiliser Qt4 parce que saibon mangez en, et utiliser QtScript. C'est un moteur d'ecmascript et c'est très bien fichu.

    (D'ailleurs je prévois de sortir une nouvelle version de mon générateur de papiers millimétré, qui a déjà été mentionné dans un journal, où la génération du papier en lui-même est faite par un script grâce à QtScript. Ca permet de développer en 5 minutes chrono un générateur de papier à musique par exemple.)

    • [^] # Re: La solution

      Posté par  (site web personnel) . Évalué à 2.

      J'imagine que tu utilises un tas d'objet Qt pour le faire. Pourquoi tu penses gagner du temps en évitant c++ ?

      "La première sécurité est la liberté"

      • [^] # Re: La solution

        Posté par  (site web personnel) . Évalué à 1.

        L'avantage, c'est pour moi, pas pour lui (en tout cas c'est moins évident).

        Si je veux faire un papier particulier, je n'ai pas besoin de:
        - savoir programmer en C++ (langage que je déteste)
        - avoir tout l'environnement de dev qui peut être très lourd (surtout qi je n'aime pas les autotools)
        - m'embêter à devoir débugger le truc avec gdb car j'ai un segfault obscur

        et sûrement d'autres raisons. Du coup je peux faire mon papier spéciel en 2 minutes.

  • # D'experience...

    Posté par  . Évalué à 8.

    Pour avoir implemente les 2 cotes de la chose (le langage de script et les softs l'utilisant), voila les points pratiques :

    a) Pas besoin de compiler le code, les gens peuvent tres rapidement et facilement editer un fichier, relancer et voir le resultat. Ca simplifie bcp compare au besoin d'avoir le compilo, les bons headers, un makefile, ...

    b) Tu peux limiter ce qui est faisable, typiquement dans mon cas j'ai en gros reimplemente un C-like en script, mais en virant tout ce qui est "dangereux"/inutile dans mon cas : additions de pointers, malloc, ... et j'ai ajoute des boundary checks automatiques, resultat un gars ne plantera jamais tout le soft en ecrivant un script pourri, alors qu'il le pourrait avec un plugin pourri.

    • [^] # Re: D'experience...

      Posté par  (site web personnel) . Évalué à 2.

      donc 1) tu te facilites la vie.

      2) Tu controles finement ce que peux faire tes utilisateurs.

      J'ai tout compris ?

      "La première sécurité est la liberté"

  • # exemple avec firefox/XUL

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Les langages de scripts sont souvent bien plus connu que les langages compilés. Prenons l'exemple de Javascript. Le moindre petit développeur web connait javascript (pas forcément bien mais bon...). Et bien le moindre petit développeur web peut par exemple se faire une petite extension XUL pour Firefox en 2-3 coups de cuillère à pot. Bon j'exagère un poil, mais c'est en tout cas extrêmement plus simple que si il fallait faire l'extension à coup de fonction C/classe C++ (avec tout ce que ça apporte comme lourdeur au dev : installation de X outils de dev, compilation etc.) On en a une preuve flagrante quand on compare IE et Firefox : regardez celui qui a le plus d'extensions disponibles. C'est celui qui peut être étendu avec un simple script.

    Et puis je plussois ce que dit pasBillpasGates : un langage de script permet de limiter les dégâts en terme de gestion de mémoire, de limiter l'accés à certaines API internes pour pas faire n'importe quoi, puisque c'est l'interpréteur qui gère ces problémes. Mais ça ne les éradique pas forcément, comme on peut le voir avec certaines extensions Firefox codées avec les pieds, et qui contiennent des leaks dans tous les sens.

    • [^] # Re: exemple avec firefox/XUL

      Posté par  . Évalué à 2.


      mais c'est en tout cas extrêmement plus simple que si il fallait faire l'extension à coup de fonction C/classe C++

      Tu voulais plaisanter là. Tu ne pouvais pas prendre pire exemple pour illustrer tes propos.
      Un plugin FF necessite de connaitre le XUL, le js , les CSS et de lier tout ça tant bien que mal sans savoir où on en est.

      Tu aurais pu citer n'imporrte quel wrapper de lib graphique (Qt, GTK, SWT, Fox) vers des langages de script et tu nous sors le langage le plus moisi et en plus à intégrer dans une architecture complexe pour soi-disant séparer la présentation du contenu. Je préfere encore du bon C/C++ d'autant que dès que tu veux faire un truc un peu chiadé tu ne coupes pas au XPCOM. PyQt te permet de créer des applis complètes sans pb sans recourir au c++ par ex.

      • [^] # Re: exemple avec firefox/XUL

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        >Tu voulais plaisanter là.

        Non. Mais tu ne sembles pas avoir lu ce que j'ai dis. Je parlais des développeurs web.

        >Un plugin FF necessite de connaitre le XUL, le js , les CSS et de lier tout ça tant bien que mal sans savoir où on en est.

        Ça tombe bien, un développeur web connait le js, le CSS et doit apprendre le XUL qui n'est franchement pas difficile ( pour un bouton, pour un item de menu, oua la vache, c'est compliqué !). Le seul truc sioux, c'est apprendre les API interne, mais heureusement, il y a de la doc.

        Maintenant va demander à un développeur web (qui n'a pas forcément voire rarement fait du C++), de faire une extension C++ pour IE par exemple...

        >PyQt te permet de créer des applis complètes sans pb sans recourir au c++ par ex.

        ouai ouai, c'est beau python. Pas sûr que les applis C++ qui embarquent python intègre PyQT (surtout si elle est pas faite en QT). Relis le sujet du journal, on parle de langage de script "embarqué".

        • [^] # Re: exemple avec firefox/XUL

          Posté par  . Évalué à 2.


          Pas sûr que les applis C++ qui embarquent python intègre PyQT (surtout si elle est pas faite en QT). Relis le sujet du journal, on parle de langage de script "embarqué".

          Il s'agit d'un exemple qui ciblait les applis Qt qui peuvent parfaitement embarquer un interpète python et qui me paraissait plus accessible. Je n'ai pas l'impression d'être hors-sujet mais je conviens qu'un developpeur Web n'étant pas un developpeur d'application native, ton exemple est valable. Simplement hormis FF dédié au Web la cible de javascript me parait limitée. D'ailleurs il etait question à un moment de pouvoir utiliser python pour étendre FF. C'est tombé aux oubliettes ?

          • [^] # Re: exemple avec firefox/XUL

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            >Simplement hormis FF dédié au Web la cible de javascript me parait limitée

            j'ai pris FF et javascript pour un exemple concret d'application qui peut être scriptable. Maintenant embarquer javascript ailleurs, ça te parait peut être limité, mais je ne suis pas de ton avis.

            J'ai l'impression que tu confond langage et API. Au niveau langage, javascript est plutôt complet (après on aime ou on aime pas l'objet basé prototype), surtout dans ses dernières versions qui ont des trucs syntaxiques à la python ;-).

            Au niveau de l'API, c'est aussi illimité, dans la mesure où, comme avec tout moteur de script embarquables (Python ou autre), tu peux déclarer auprès du moteur, des objets du langage qui seront mappés sur l'API C/c++ interne de ton application, et donc ces objets te paraitront natif du point de vu de ton script. En plus, tu as la liberté de "montrer" ce que tu veux de ton API, donc cela sécurise l'exécution des scripts.

            D'ailleurs, il faut faire ce mapping quand on embarque un moteur de script, pour que les scripts puissent interagir avec le logiciel, sinon embarquer un moteur de script n'aurait plus d'intérêt. C'est fait par exemple dans Firefox pour le DOM, l'objet window, xmlhttprequest etc..

            (et dans FF, il y a aussi XPCOM/XPConnect pour tout le reste de l'API : cela permet d'étendre l'API javascript très facilement sans toucher à spidermonkey et ce qui l'entoure).

            >D'ailleurs il etait question à un moment de pouvoir utiliser python pour étendre FF. C'est tombé aux oubliettes ?

            Tu peux faire des XPCOM en python, c'est toujours ça, mais il faut se compiler une version avec le flag qui va bien. Le support n'est pas inclus d'office. (L'IDE Komodo par exemple a toute son API dans des XPCom en Python).

            Pour ce qui est de l'utilisation directe de Python dans les pages XUL/HTML, il y avait un travail en cours, mais je crois que ce n'est pas terminé (pas sûr que ce soit très actif en ce moment d'ailleurs). Il me semble que c'est prévu toutefois dans Mozilla 2.

            • [^] # Re: exemple avec firefox/XUL

              Posté par  (site web personnel) . Évalué à 1.

              Pour ce qui est de l'utilisation directe de Python dans les pages XUL/HTML, il y avait un travail en cours, mais je crois que ce n'est pas terminé (pas sûr que ce soit très actif en ce moment d'ailleurs). Il me semble que c'est prévu toutefois dans Mozilla 2.


              Il faudrait d'about être capable de créer une sandbox en python ... d'ici que ma page web me fasse un open("/home/toto/document-important") ...

    • [^] # Re: exemple avec firefox/XUL

      Posté par  (site web personnel) . Évalué à 3.

      On peut également utiliser Js dans des softs comme photoshop (pour automatiser des tâches).
      Javascript est utilisé souvent par des devs/designers web et pour qui c'est donc plus interressant que d'apprendre C/C++ qui n'est pas vraiment relié à leur domaine.

  • # Pour les jeux

    Posté par  . Évalué à 3.

    Je me souviens de ce jeu magnifique qu'est Baldur's Gate (1 & 2), et qu'il incluait du LUA pour tout ses scripts. Résultat : des petits malins bidouilleurs ont pu coder leurs propres add-ons de façon assez pro. On trouvait aussi tout un tas de petits scripts pour ajouter des armes, des sorts, des persos... A noter aussi, l'existence d'une console LUA "in-game" qui était bien pratique (pour tricher, mais aussi surtout pour développer ces petits add-ons).

    Je me souviens aussi d'un vieux jeu qui pouvait se reprogrammer entièrement en Lisp, et qui existait sous Linux (je ne me souviens plus du titre, mais j'avais lu un article là dessus dans un Best Seller Games je crois).

    Et encore, je ne parle pas de tous les jeux qui offrent de bon gros éditeurs de niveaux avec langage de script intégré (Morrowind, Neverwinter Nights...).

  • # Retour

    Posté par  (site web personnel) . Évalué à 2.

    Pour xbindkeys, le fait d'avoir un langage de script (scheme/guile) m'a permit de laisser les utilisateurs faire ce qu'ils veulent du programme sans ce prendre la tête à modifier le programme en C directement ou à étendre le parser par défaut (qui est déjà suffisamment compliqué comme ça, même si la syntaxe est très simple) ou de me demander à chaque fois de rajouter la fonction dont ils ont besoins.

    Le programme en C est le squelette et le langage de script accède au fonctions de base par une API simplifiée (ajouter/enlever une touche, associer une touche à un programme externe ou une fonction en scheme).

    Ça m'a évité de rajouter des patchs en quantité pour faire telle ou telle chose. Et ce qui devait être fait à coup de scripts bash et de programmes externes est devenu beaucoup plus simple et plus puissant grâce à un langage complet (le scheme) avec lequel on peut définir de nouvelle fonctions/variables, avoir des tests, des boucles...

    Faire la même chose avec un système de plugins aurait été possible mais pas aussi simple : compilation du plugin vs écriture à chaud dans le fichier de conf (qui est relu automatiquement des qu'il est modifié -> tu sauvegarde le fichier de conf et les modifications sont prisent en compte instantanément).

    • [^] # Re: Retour

      Posté par  (site web personnel) . Évalué à 2.

      En gros, tu cherches la facilité d'extension en baissant la quantité de compétence nécessaire à la personne qui fait sa bidouille ?

      "La première sécurité est la liberté"

  • # Langages de scripts sont nécessaires ...

    Posté par  (site web personnel) . Évalué à 2.

    J'avais loupé ce thread mais puisque on en parle sur la ml Lisaac ...

    Pour moi les langages de scripts sont une absolue nécessité car ils permettent de limiter les droits associés à un script. Enfin, pas tous les langages de scripts. Certains comme python n'en sont pas capable (du moins si on ne modifie pas le langage) alors que c'est une des fonctionnalités clefs de lua.

    D'autre part, la recompilation en langage machine est nécessaire pour les plugins, alors que pour les langages de scripts n'en ont pas besoin.

    Les problèmes des plugins, c'est:
    - qu'il n'y a aucun moyen de limiter leurs droits au niveau utilisateur
    - pas d'universalité du plugin sur différentes architectures materielles.

    Donc par exemple, si je souhaite faire un logiciel qui chercheratout seul des plugins sur internet, c'est foutu si je n'utilise pas un langage de script. Car:
    - avec du code machinne le plugin peut faire n'importe quoi
    - à part qi j'embarque un compilateur, le plugin doit être un fichier objet ne fonctionnant que sur une architecture définie.

    La solution, c'est la machinne virtuelle, style java ou lua. Pour moi, peu importe si c'est compilé comme java ou moins compilé comme lua, cela rempli les mêmes rôles. Je préfère juste lua pour sa simplicité.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.