Whippet : un langage de script sans prétentions

Posté par . Modéré par Xavier Teyssier.
Tags :
10
25
déc.
2010
Technologie
Après un an de développement en solo, un dépôt public git est disponible pour le projet whippet ainsi qu'une première version fonctionnelle.

Mais qu'est-ce que le projet whippet ? Whippet est un langage de script généraliste totalement écrit en C++. L'objectif de ce projet est de fournir un langage de script au code totalement portable (aucune ligne de code n'est spécifique à la plateforme d'exécution) et facilement extensible grâce à des interfaces prévues à cet effet.

On retrouve dans ce langage tous les aspects classiques d'un langage procédural "actuel" :
  • structures if-else-endif ;
  • Switch-case (l'élément suivant "case" peut être une variable...) ;
  • Boucles for, while et until ;
  • Ainsi que tout ce qui est indiqué sur la page du projet et qui n'a pas besoin d'être répété...


Le langage a prévu la possibilité de fonctionner dans la langue de l'utilisateur. Mais, chose particulière, la langue est fixée une bonne fois pour toutes à la compilation, évitant l'utilisation de variables d'environnement. En raison de la petite jeunesse du projet, seuls l'anglais et le français sont actuellement disponibles.

Afin de montrer les possibilités offertes par ce langage et, plus modestement, sa syntaxe, des scripts d'exemples sont fournis. Cependant, ces derniers ne sont pas encore exhaustifs et de plus amples démonstrations sont en préparations. Des pages de documentation devraient suivre. Le projet, publié en GPL version 3, compte sur des contributeurs du libre pour continuer à évoluer.
  • # On reste sur sa faim

    Posté par (page perso) . Évalué à 10.

    Ce serait bien qu'on sache le but de ce langage de script, ce qui le différencie d'autres comme python, ruby, perl ou lua.
    Est-ce que c'est un langage pour le plaisir d'écrire un interprète, d'éducation, ou destiné à faire des logiciels en production ?

    Un petit Hello World serait le bienvenue aussi, histoire d'avoir une idée de la syntaxe.
    • [^] # Re: On reste sur sa faim

      Posté par (page perso) . Évalué à 3.

      En cherchant un peu, j'ai fini par trouver des exemples dans http://www.gitorious.org/whippet/whippet/trees/master/tests dont un Hello world :


      methods_begin
      proc myproc (a)
      {
      printout $a
      }
      methods_end

      set string hello "Hello world!"
      myproc ( $hello )
      unset hello
      • [^] # Re: On reste sur sa faim

        Posté par (page perso) . Évalué à 3.

        ouch ...
        la syntaxe est ... particulière ...
        Déjà les commentaires derrière -- c'est pour le moins inhabituel

        Ensuite j'ai bien du mal avec beaucoup d'aspects (en tout cas à la lecture des exemples) :
        les mots clés 'methods_begin / methods_end'
        Les sorties (derrière printout) assez étrange genre :
        printout "compare: " $cmp \n
        genre le \n qui traine tout seul, comme ça ... on sait pas trop ce que ça fait là

        les assignations avec :=



        En gros, je trouve le tout très (beaucoup trop en fait) inutilement verbeux, étrange, avec des mélanges de syntaxes inhabituels voir anciens.
        Ce qui me donnerait envie de l'utiliser serait par exemple une syntaxe sympa, un petit plus quoi. Là ... ben j'ai pas trouvé.

        Maintenant, il manque peut-être quelques informations genre pourquoi, dans quel but, comment, etc.
        • [^] # Re: On reste sur sa faim

          Posté par . Évalué à 4.


          la syntaxe est ... particulière ...
          Déjà les commentaires derrière -- c'est pour le moins inhabituel
          (...)
          les assignations avec :=


          Ces deux aspects là sont très habituels dans les langages SQL et dérivés (PL/pgSQL ; Transac-SQL ...).
        • [^] # Re: On reste sur sa faim

          Posté par (page perso) . Évalué à 5.

          >> Déjà les commentaires derrière -- c'est pour le moins inhabituel
          Comme en Ada et VHDL.

          >> les assignations avec :=
          Comme en Pascal.
          • [^] # Re: On reste sur sa faim

            Posté par (page perso) . Évalué à 4.

            Comme le commentaire plus haut, je pensais bien à du SQL.
            Mais reste que je trouve ça des plus étranges comme choix.

            Et oui ça reste plutôt marginal lorsqu'on voit le nombre de langages utilisant // ou /**/ ou # (qui sont quand même les trois cas les plus courant) idem pour l'assignation en := surtout que les tests sont écrits en ==

            En gros j'arrive pas du tout à comprendre cet ensemble de choix très étrange.
            Mais oui, par certains côtés ça me ferait plus penser à du sql version script ...
            • [^] # Re: On reste sur sa faim

              Posté par . Évalué à -2.

              À quoi ça servirait d'écrire un langage en reprenant tout ce qui a déjà été fait ? Tenter des choix différents c'est une bonne chose, on peut ainsi découvrir ou se rendre compte que finalement tel ou tel partie de la syntaxe est pratique/agréable.

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

          • [^] # Re: On reste sur sa faim

            Posté par . Évalué à 2.

            Note que vu le nombre d'utilisateurs d'Ada/VHDL et Pascal par rapport au C/C++/Java, le qualificatif "inhabituel" est mérité.

            Pas que ce soit une critique d'ailleurs: je pense que je préfère Ada au C++..
  • # Pourquoi devrais-apprendre ce langage ?

    Posté par . Évalué à 6.

    Quel avantage a ce langage particulier, pourquoi devrais-je faire l'effort d'en apprendre un de plus ?

    > un langage de script sans prétentions
    Ce titre ne rassure pas. Cela veut dire que les concepteurs vont se limiter à un langage jouet ? je vais arriver à faire un petit programme, puis le jour où j'aurai besoin de le complexifier, je vais devoir faire faire des contournements douloureux des limitations, ou tout porter dans un autre langage ? Ça me rappelle le célèbre échange de messages entre RMS et le reste du monde à propos de Tcl : « a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that! » — RMS, 23 septembre 1994 – http://www.vanderburg.org/OldPages/Tcl/war/0000.html
    • [^] # Re: Pourquoi devrais-apprendre ce langage ?

      Posté par (page perso) . Évalué à 1.

      >>> pourquoi devrais-je faire l'effort d'en apprendre un de plus ?

      Pour le fun ? parce que ca fait rigolo sur un CV ?
      • [^] # Re: Pourquoi devrais-apprendre ce langage ?

        Posté par (page perso) . Évalué à 5.

        Si sur mon CV je devais mettre tous les langages inconnus développés par une personne seule dans son coin pendant un an, je suis pas sûr que je trouverai plus de travail.

        Quand au fun, ça reste à voir. Si le langage n'apporte rien, il n'y a pas de fun.
        Quels sont les algos qui s'expriment « mieux » dans son langage que dans un autre ? Quel est le charme de son langage ?
  • # Objectif

    Posté par . Évalué à 5.

    Contrairement à ce qui est dis plus haut je trouve que l'objectif est clairement annoncé :

    « L'objectif de ce projet est de fournir un langage de script au code totalement portable (aucune ligne de code n'est spécifique à la plateforme d'exécution) et facilement extensible grâce à des interfaces prévues à cet effet. »

    Par contre je me pose la question du positionnement de ce projet face à lua qui, il me semble, a un objectif analogue.

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Objectif

      Posté par . Évalué à 7.

      En pratique, tu peux me citer des langages de script pas portables ?
      • [^] # Re: Objectif

        Posté par . Évalué à 2.

        Tout dépend de ce que tu entends par portable, si tu peut te contenter de POSIX alors le bourne shell est portable, dans les fait une énorme majorité des ordinateurs personnels ne sont pas POSIX.

        Ensuite je n'ai pas vu le langage mais s'il propose certaines abstractions comme pour les chemins alors il offre en standard des choses que tu ne trouve pas en lua ou perl (je crois).

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: Objectif

          Posté par . Évalué à 1.

          Je sais pas en Lua, mais Perl traduit automatiquement la forme "Unix" du chemin vers la forme native (par exemple open '/foo/bar' va faire open '\\foo\\bar' sous Windows) (man perlwin ;))
          • [^] # Re: Objectif

            Posté par (page perso) . Évalué à 5.

            En fait cela fait belle lurette que la libc de Windows considère le slash comme un séparateur de chemin, même si ce n'est pas le cas de certaines applications telles que cmd.exe.
      • [^] # Re: Objectif

        Posté par (page perso) . Évalué à 5.

        En pratique, tu peux me citer des langages de script pas portables ?
        Par exemple PowerShell. En pratique, ce langage n'est porté nulle part. Pour plusieurs raisons dont l'une est la volonté de l'éditeur de ne pas le porter.
        • [^] # Re: Objectif

          Posté par . Évalué à 1.

          De plus, par portable on entendait ici certes la disponibilité pour toutes les plateformes, mais surtout, un code source unique sans directive de précompilatio, fichiers séparés ou autres pour compiler sur une plateforme.

          1/ code source en c++ strict
          2/ pas de dépendances qui pourraient être absentes sur une plateforme

          Voici le sens que le mot portable prenait ici
      • [^] # Re: Objectif

        Posté par . Évalué à 1.

        La portabilité dont il s'agit ici est celle de l'interpréteur, pas celles des scripts. Même si la formulation ici prête à confusion, le site du projet est clair :

        «Whippet is a general purpose script engine written in pure C++. The code is portable and has no external dependencies.»
  • # explications...

    Posté par . Évalué à 3.

    Le premier objectif de ce projet était un amusement de geek un peu polémique...
    Concernant les choix techniques, quelques explications:

    1/ Les commentaires: le principal développeur est un très grand admirateur du VHDL, et en a assez des langages de scripts utilisant le # ou une inspiration C...

    2/ Les assignations en := comme en camL ou Pascal: pourquoi pas...

    3/ Les boucles un peu bizarres: pour changer un peu...

    4/ methods_begin/methods_end: c'est assez bof

    5/ le \n qui traine... les caractères d'échappement n'ont pas besoin d'être entre guillemets.

    6/ printout et printerr: comprendre cerr et cout... De plus, la concaténation est implicite, pas besoin de points, de +... (mettre des guillemets quand même pour les espaces)

    Voilà, les questions et remarques sont les bienvenues,
    • [^] # Re: explications...

      Posté par . Évalué à 7.

      > et en a assez des langages de scripts utilisant le # ou une inspiration C...
      > pourquoi pas...
      > pour changer un peu...
      Excuse-moi, mais ça fait un peu « changer pour changer », sans aucun réel argument derrière. Pour moi, un nouveau langage se doit d’apporter — relativement à l’existant — une amélioration sur au moins un de ces axes : expressivité, sécurité, performances — sinon c’est poubelle direct : si c’est pour juste changer = par :=, je peut très bien faire un coup de sed sur mes sources python, ce sera aussi efficace, et je bénéficierai de toute la librairie standard python, et de toutes les compétences des devs python pour la maintenance de l’interpréteur.
      Concrètement, il apporte quoi relativement à Python ou Ruby, Whippet ? Encore une fois, remplacer "=" par ":=" et "#" par "--" n’est pas un apport.
      • [^] # Re: explications...

        Posté par . Évalué à 3.

        Plutot que de le comparer à Python ou Ruby, il est préférable de le repositionner par rapport à Lua ou Tcl dans l'esprit d'extension...

        Au commencement, l'objectif était de pouvoir y ajouter facilement des fonctionnalités spécifiques pour plus tard étendre une application existante. Pour se faire, l'idée était de posséder un interpréteur (et une syntaxe) assurant le minimum vital.

        Une usine à gaz comme Python n'est pas utile pour fournir une interface ligne de commande et de script comme dans les outils Xilinx (qui utilise Tcl je crois)

        Petit, léger, ne comprenant pas grand chose d'inutile (pour l'instant), facile à intégrer à l'existant, facile à compiler en standalone...

        Concernant la syntaxe, ceci est un choix, mais le fichier src/const.h permet de redéfinir facilement tous les mot-clefs et "balises" sans devoir modifier du code partout et obtenir une version très personnelle.
        • [^] # Re: explications...

          Posté par . Évalué à 3.

          OK, on s’approche d’un début de positionnement. Relativement à Lua, il apporte quoi ? Concrètement, tu annonces « simplicité de personnalisation ». En pratique, ça veut dire quoi ?
          1. Possibilité de modifier les mots clefs ("if" / "si") ? Pas très utile.
          2. Possibilité de créer des APIs spécifiques ? Lua le fait.
          3. Possibilité d’implémenter des paradigmes différents ? Là, ça peut être intéressant. Je peux facilement étendre le langage pour y mettre des closures ? Je peut en faire facilement un langage fonctionnel ?
    • [^] # Re: explications...

      Posté par . Évalué à 5.

      Est-ce qu'il existe une grammaire du langage ou alors c'est seulement le code source qui fait foi ?
  • # Oui, pète.

    Posté par (page perso) . Évalué à -1.

    *Prout*

    Sans prétention, peut-être. Sans odeur, ça reste à voir (ou à sentir).

    -->[ ]

Suivre le flux des commentaires

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