Calendriers de l'avent Perl 5 et Perl 6

Posté par . Édité par Xavier Claude et Nÿco. Modéré par patrick_g. Licence CC by-sa
Tags :
19
4
déc.
2011
Perl

Comme chaque année, les équipes Perl 5 et Perl 6 publient leurs calendriers respectifs de l'avent [1] [2] qui démontrent les fonctionnalités des langages et de leurs bibliothèques et donnent des conseils stylistiques. Beaucoup programment en Perl 5 comme en C et ignorent que Perl est inspiré des principes qui règlent les langages naturels. Comme on s'exprime de manière différente selon le média, la situation et l'interlocuteur, on n'écrit pas en Perl de la même manière un gros programme et un uniligne [3] [4].

Rakudo Star, un Perl 6 pour les adopteurs précoces

Quant à Perl 6, une nouvelle release de Rakudo Star est prévue au plus tard pour janvier 2012, le temps de corriger les régressions dues à l'intégration de nouveaux blocs architecturaux. Le nombre, l'importance, et l'interdépendance de ceux-ci expliquent l'absence de release depuis juillet. Une explication détaillée pour les anglophones.

Le résultat est impressionnant. Exemples parmi d'autres : on peut écrire un système de débogage de grammaire en 200 lignes, ou intégrer de manière transparente une bibliothèque d'entiers en longueur variable, accessible sous le nom de type BigInt.

Finalement l'architecture étant stable, les développeurs de rakudo peuvent commencer à optimiser le compilateur en écrivant du code Perl 6 améliorant ainsi à la fois les performances du compilateur et celles du code utilisateur. Merci au système de métaclasses avec polymorphisme de représentations.

  • # Perl vs Ruby

    Posté par . Évalué à 1.

    Par pure curiosité, quels sont les avantages qui restent à Perl vis-à-vis du langage Ruby qui a pris la suite ?

    • [^] # Destructeurs

      Posté par . Évalué à 2.

      Des destructeurs ?
      Enfin ça, c’est pour quasiment tous les langages orientés objets par rapport à Ruby...

      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

    • [^] # Re: Perl vs Ruby

      Posté par . Évalué à 6.

      Son taux de pénétration sur les plateformes Unix ?
      les perf ?
      des structures du langage comme given/when ?
      la manipulation en ligne de commande ?
      les variables utilisée implicitement ?
      son API très intuitive pour qui viens du C ?
      un langage plus flexible dans le quel beaucoup de choses sont implémentés dans le langage lui même (les objets avec Moose, MooseX et autre) ?

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

      • [^] # Re: Perl vs Ruby

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

        Une panoplie de lib sur CPAN
        Des one-liner de la mort qui tue...

      • [^] # Re: Perl vs Ruby

        Posté par . Évalué à -1. Dernière modification le 07/12/11 à 20:50.

        Son taux de pénétration sur les plateformes Unix ?

        Perl 6 n'a pas un très gros taux de pénétration, pour le coup

        la manipulation en ligne de commande ?

        Ruby a aussi les options -p, -n, -e et -i.

        les variables utilisée implicitement ?

        Ruby reprend de Perl un certain nombre d'entre elles.

    • [^] # Re: Perl vs Ruby

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

      Ruby a pris la suite ?

      La formulation est un peu étrange, la suite de quoi ?

      Ruby a du mal à se distinguer de Rails. Même si Ruby est un langage bien plus généraliste que PHP, au final il reste dans les faits bien plus un "concurrent" de PHP que de Perl.

      Le "concurrent" de Perl c'est plutôt Python.

      Alors que reste-t-il à Perl ?

      C'est un langage vraiment multi-paradigmatique. Ruby s'en rapproche, Python est très loin derrière (mais c'est la volonté même de son concepteur !). Mieux, c'est quasiment un langage de recherche en plus d'être un langage extrêmement pratique.

      C'est un langage qui a un nombre de bibliothèques de qualités très important (CPAN).

      C'est un langage qui commence à avoir de la bouteille et ça signifie : les bonnes pratiques sont connues et documentées, et dans le cas de Perl richement documentées !

      La communauté est excellente.

      En gros pour moi la force de Perl c'est :

      • Son expressivité et sa puissance
      • le CPAN
      • La documentation
      • la communauté
      • Compatibilité descendante excellente

      Principaux défauts :

      • Pas de REPL en standard
      • Langage devenu un peu brouillon par endroit et donc difficile à appréhender au début
      • [^] # Re: Perl vs Ruby

        Posté par . Évalué à 0.

        Ruby a du mal à se distinguer de Rails. Même si Ruby est un langage bien plus généraliste
        que PHP, au final il reste dans les faits bien plus un "concurrent" de PHP que de Perl.

        Le "concurrent" de Perl c'est plutôt Python.

        Je ne comprends pas du tout cet argument; en quoi l'existence et la popularité de Rails est un problème pour Ruby? Il y a plein de gens qui utilisent Ruby en dehors de Rails!

        • [^] # Re: Perl vs Ruby

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

          Je n'ai pas dit le contraire.

          Ce que je voulais dire c'est que finalement Ruby est surtout un langage pour le web. Non qu'il soit incapable de faire autre chose, mais historiquement il s'est fait connaître par Rails, il a attiré les devs web et voilà.

          Il suffit de voir un système unix. Quel est le langage qui mange un peu du pain réservé jusqu'alors à Perl ? Python, principalement Python, majoritairement Python.

          Quitte à faire de l'ombre à Perl j'aurais également préféré que ce soit par Ruby !

          Mais c'est ainsi.

          De même pour Perl. Perl est théoriquement capable de tout faire. Mais grosso-modo ses meilleures bibliothèques tournent autout du web, de l'admin système, du traitement des données textuelles. Et c'est pas un hasard, c'est par là qu'il s'est fait connaître.

          Ses bibliothèques pour les GUI ou le dev de jeux (SDL etc.) sont notoirement moins connues et moins peaufinées que celle de Python.

          Ce qui n'empêche pas de faire des jeux et des GUI en Perl !

  • # Perl 6

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

    Concernant Perl 6, vu le peu de point commun avec Perl 5 en terme de langage, je me demande pourquoi ça s'appelle encore Perl. J'ai l'impression qu'il y a à peu près autant de points communs entre Perl 5 et Perl 6 qu'entre le C et l'assembleur (en gardant en tête qu'on peut embarquer de l'assembleur dans du C très facilement).

    • [^] # Re: Perl 6

      Posté par . Évalué à 2.

      Je pense que Perl 6 sera la continuation d'une idée qui n'a été qu'ébauchée avec la lignée Perl jusque là. Il y a toujours des sigils par exemple.

      Il y aura donc deux lignes concurrentes Perl 5 et Perl 6. Perl 5 évoluera encore longtemps, mais contraint par les règles de rétrocompatiblité avec bientôt 25 d'existence. Alors que Perl 6 est conçu dès le départ pour évoluer avec l'expérience acquise pendant tout ce temps.
      L'existence d'un mécanisme de grammaire permet à chacun d'étendre le langage à son goût et les expériences les plus réussies entreront dans le langage standard. Peu de langage ont réussi une évolution aussi propre. Dans le monde des langages dynamiques, Perl est le premier et encore longtemps le seul car les autres langages ont sérieusement cassé la compatibilité avec leurs release majeures.
      Cela n'enlève rien aux mérites propre des autres langages.

      • [^] # Re: Perl 6

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

        Peu de langage ont réussi une évolution aussi propre. Dans le monde des langages dynamiques, Perl est le premier et encore longtemps le seul car les autres langages ont sérieusement cassé la compatibilité avec leurs release majeures.

        Malgré toute ma sympathie pour Perl, que j'aime beaucoup, je ne suis pas totalement d'accord avec cette opinion.

        Certes, si l'on compare Perl à Ruby, Lua et Python, c'est vrai.

        Mais c'est très vite oublier la vieille famille de langages Lisp, infiniment plus propre et d'autant moins soumis aux problèmes de rétrocompatibilité que Lisp est champion (tous langages confondus) en matière de "programmabilité" il est LE langage programmable et donc naturellement extensible.

        • [^] # Re: Perl 6

          Posté par . Évalué à 1.

          Mais c'est très vite oublier la vieille famille de langages Lisp, infiniment plus propre et d'autant moins soumis aux problèmes de rétrocompatibilité que Lisp est champion (tous langages confondus) en matière de "programmabilité" il est LE langage programmable et donc naturellement extensible.

          En effet.
          Malheureusement, si Lisp est l'ancêtre des langages dynamiques, il n'est pas très populaire aujourd'hui.

          Lisp est toujours une source d'inspiration pour les designers de langage et de VM.
          Ainsi, Parrot a des véritables systèmes de continuation et de GC, et non un simple système de comptage de référence comme Perl 5; Perl 6 propose a la fois des variables lexicales et des variables dynamiques; il propose des aussi des macros hygiénique (en cours d'implémentation).

          Mais côté grammaire, le choix de Perl 6 est opposé à celui de Lisp. Il a une syntaxe riche, et maintenant extensible, qui permet de mettre en valeur la structure des programmes et la nature des données (sigils et twigils). Cela ne s'oppose pas à l'extensibilité puisque le système de grammaire entièrement intégrés à l'objet est très expressif.

          • [^] # Re: Perl 6

            Posté par . Évalué à 2.

            Malheureusement, si Lisp est l'ancêtre des langages dynamiques, il n'est pas très populaire aujourd'hui.

            On se demande pourquoi. Il est intéressant de noter qu'il n'y a à peu près que C qui soit très vieux (créé avant Epoch) et qui soit toujours populaire. lisp arrive en second (grâce à des logiciels comme emacs), mais les langages comme Fortran et COBOL sont utilisé par héritage du passer sans être populaire.

            Lisp est toujours une source d'inspiration pour les designers de langage et de VM.

            Il y a tout de même des choses qu'on essaie de ne pas reproduire comme le contexte dynamique des fonctions (si je me trompe bien c'est ce que fait lisp).

            Parrot a des véritables systèmes de continuation

            Qu'est ce que c'est ?

            Édition :

            sed -e 's/si je me trompe bien/si je ne me trompe pas/'
            
            

            Je la laisse apparente car elle m'a fait rire.

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

            • [^] # Re: Perl 6

              Posté par . Évalué à 1.

              continuation.

              D'après ce que je sais, les premiers Lisps avaient pour seul scopage, un scopage dynamique. Cela a été ensuite remplacé par un scopage lexical qui est généralement ce que le programmeur désire.
              Si je me souviens bien Perl a commencé avec le seul scopage local (mécanisme similaire au scopage dynamique) pour y ajouter plus tard le scopage lexical.

              Mais il y a des cas où le scope dynamique est préférable.
              Le scopage dynamique est très utilisé pour passer du contexte sans passer par des paramètres explicites. Ainsi dans la grammaire Perl 6, les variables avec le twigil '*' sont des variables dynamiques.

              • [^] # Re: Perl 6

                Posté par . Évalué à 2.

                Le scopage dynamique est très utilisé pour passer du contexte sans passer par des paramètres explicites.

                C'est pas une forme d'effet de bord inversée ? Ça ne me semble pas souhaitable, car ça peut être compliqué à corriger en cas d'erreur.

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

            • [^] # Re: Perl 6

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

              Fortran et COBOL

              Je ne connais pas du tout COBOL et il est bien possible que ses développements actuels ne servent plus qu’à maintenir la bas existante dans les logiciels bancaires. Par contre Fortran est encore très utilisé, y compris dans des nouveaux codes. Fortran me paraît surtout adapté pour remplacer le C, lorsque l’on manipule beaucoup de tableaux de données (qui sont une horreur à allouer/désallouer à la main en C) et est, de fait, très utilisé pour l’implémentation de méthodes numériques et d’outils de simulation où le plus important dans le programme est l’algorithme utilisé, et non la mise en place d’interfaces et de sous-systèmes en tout genre pour découper le code proprement (même si ça arrive avec les dernières versions du langage).

              C’est un domaine parallèle à l’informatique et peut-être méconnu par les informaticiens de formation, mais je vois tous les jours des codes Fortran (essentiellement 95), y compris pour de nouveaux développements, et je dois avouer qu’avec le temps je me mets à apprécier ce langage et comprends sa popularité dans le secteur de la recherche ou du développement de logiciels de simulation et de bibliothèques d’outils numériques.

              • [^] # Re: Perl 6

                Posté par . Évalué à 1.

                La seule fois où j'ai eu à en rencontrer c'était Cast3m pour de la simulation nucléaire et c'était considéré comme une charge car tout le reste des simulateurs était en C++ et qu'ils aimeraient bien unifier les langages (d'après ce que j'ai compris fortran commencent par allouer une mémoire qu'il manipule ensuite et l'un de leur projet était d'interfacer le C++ et le fortran via cette mémoire).

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

                • [^] # Re: Perl 6

                  Posté par . Évalué à -1.

                  De mémoire dans Cast3M, c'est une extension du Fortran développée au CEA (appelée Esope)
                  qui est surtout hyper boulet ainsi que le langage de script pour coder les procédures
                  (pour lequel 2+3*4 == 5*4, pas de priorité dans les opérateurs par exemple).
                  Bref, je ne pense pas que ce soit le Fortran en tant que langage qui soit considéré
                  comme une charge (pour l'interface mémoire, elle existe avec du Python mais de ce que
                  j'ai compris elle est loin d'être stable).

Suivre le flux des commentaires

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