Pour tout savoir du Perl post‐moderne

Posté par . Édité par Ysabeau, Davy Defaud et ZeroHeure. Modéré par Xavier Claude. Licence CC by-sa.
Tags :
38
10
juil.
2019
Perl

Cette dépêche est un complément de celle qui retrace l’histoire de Perl à l’occasion de la sortie de la version 5.30. Elle se concentre sur les ressources : documentation, tutoriels, folklore, outils pour découvrir et développer en Perl.

Pour rappel, Perl est un langage généraliste créé en 1987 par Larry Wall. « Perl continue de prospérer dans sa troisième décennie grâce à une communauté d’utilisateurs et de développeurs très dynamique. », dixit perldelta. Perl est distribué sous une double licence : Artistic Licence et GPL v1+. La plupart des modules du CPAN suivent également ce même traitement.
Perl 5 raptor  Perl 5 raptor de kraih, licence CC-BY-SA 4.0

Sommaire

Liens utiles

Les paragraphes qui suivent concernant les liens n’ont pas pour but d’être exhaustifs mais plutôt de fournir des pointeurs vers des ressources ou d’attiser votre curiosité.

Développement de Perl core

Officiel

  • perl.org, la « maison » de Perl ;
  • Perl Fundation, la fondation Perl ;
  • White Camel Awards, récompense annuelle pour des personnes ayant contribué de manière importante à Perl. Et ce pas forcément avec du code !

Modules et installeurs

Général

Autour du CPAN

  • [NOUVEAU] CPANdoc, doc de modules importants ;
  • CPAN Testers, un site pour gérer les contructions et rapports de test des modules CPAN ;
  • CPAN map, carte des espaces de noms CPAN ;
  • CPAN Cover, couverture de test des modules CPAN ;
  • CPAN TS, Kwalitee métriques ;
  • CPAN IO classement des auteurs CPAN selon leur activité.

Social

Docs officielles

Tutoriels

Tutoriels en français

Tutos interactifs

Méta‐site qui liste les tutoriels

Folklore autour de Perl

Écosystème Perl

Exécution de code Perl en ligne

Exécution de code Perl en ligne (sites non spécifiques à Perl)

Développer avec Perl

Installer des modules du CPAN

La méthode moderne consiste à utiliser cpanm (cpanminus). L’outil se charge d’aller chercher le module demandé et de résoudre les dépendances. Par exemple, pour installer l’excellent module XML::LibXML de Shlomif qui est la bibliothèque de liaison Perl de libxml2, on peut faire sudo cpanm XML::LibXML, qui produit la sortie suivante (tronquée) :

--> Working on XML::LibXML
Fetching http://www.cpan.org/authors/id/S/SH/SHLOMIF/XML-LibXML-2.0201.tar.gz ... OK
==> Found dependencies: Alien::Libxml2
--> Working on Alien::Libxml2
Fetching http://www.cpan.org/authors/id/P/PL/PLICEASE/Alien-Libxml2-0.09.tar.gz ... OK
[...]
Building and testing Alien-Libxml2-0.09 ... OK
Successfully installed Alien-Libxml2-0.09
Configuring XML-LibXML-2.0201 ... OK
Building and testing XML-LibXML-2.0201 ... OK
Successfully installed XML-LibXML-2.0201 (upgraded from 2.0128)
13 distributions installed

Réinstaller un ensemble de modules Perl CPAN peut se faire simplement en réexécutant une série de commandes cpanm ou bien en spécifiant des dépendances dans un fichier cpanfile (et utiliser carton pour la configuration).

Les linters

Exécutables à la main ou intégrables dans vos scripts, IDE ou éditeurs (utilisateurs de vim : ale ou syntastic).

  • perl -c, pour vérifier la syntaxe. Attention ça fait plus que simplement vérifier la syntaxe, ça exécute aussi ce qui est dans les blocs BEGIN et END qui sont destinés à être exécutés pendant la compilation. Ce design est la raison pour laquelle le linter par défaut utilisé par le greffon vim ale n’est plus perl -c (ni même perl -w). La vérification de syntaxe est top. Personnellement, j’ai un projet qui contient ça dans le script de tests unitaires avec des vrais tests après :
my @files = <./*.pl>;
push @files, <./*.pm>;

for my $f (@files) { 
    system("perl -c $f 2>/dev/null");    
    my $real_ret_value = $? >> 8;
    if($real_ret_value !=  0) { 
        print "$f : Syntax error !\n";
    } else { 
        print "$f : OK\n";
    }
    ok($real_ret_value == 0) or $fails += 1;
}

C’est quand même la base d’avoir du code syntaxiquement juste. :)

  • Perl::Critic, qui critique votre style de codage mais ne fait pas de vérification de syntaxe. Par exemple, le fichier bad.pl contien :
use strict;
print "toto" }{

Et perl -c bad.pl nous affiche bien :

Unmatched right curly bracket at bad.pl line 3, at end of line
syntax error at bad.pl line 3, near ""toto" }"
Missing right curly or square bracket at bad.pl line 3, at end of line
bad.pl had compilation errors.

Mais perlcritic bad.pl nous dit que tout va bien bad.pl source OK (mais il râle si on ne met pas le use strict).

  • Un module qui était dans le cœur de Perl mais qui est sorti du core en 5.19 : B::Lint. Au passage comment fait‐on pour retrouver l’historique d’un module ? Utilisez corelist ! corelist B::Lint qui nous donne :
Data for 2017-09-22
B::Lint was first released with perl 5.005, deprecated (will be CPAN-only) in v5.17.9 and removed from v5.19.0

Toujours disponible dans CPAN évidemment. :)

  • Et encore un Perl::Lint qui se concentre sur la vitesse tout en étant compatible avec Perl::Critic.

Comment compiler perl

Instructions pour compiler perl. En fait, ça va donner ça :

wget https://www.cpan.org/src/5.0/perl-5.30.0.tar.gz
tar -xzf perl-5.30.0.tar.gz
cd perl-5.30.0
./Configure -des -Dprefix=$HOME/localperl
make
make test
make install

Portabilité de perl : (plus de cent plates‐formes)

Compiler les modules

Qu’on utilise ou non un installeur de modules comme cpanm, au bout du compte le module est compilé avec ExtUtils::MakeMaker ou Module::Build. ExtUtils::MakeMaker est toujours un module du core, alors que Module::Build a été ajouté puis enlevé (5.9 → 5.19). David Golden explique dans un billet de blog pourquoi il a demandé à retirer Module::Build.

ExtUtils::MakeMaker

Le module ExtUtils::MakeMaker génère un makefile à partir d’un fichier Makefile.PL :

perl Makefile.PL
make
make install

Module::Build

Le module Module::Build sert à la même chose mais génère un fichier Build à partir d’un fichier BUILD.PL :

perl Build.PL
./Build
./Build test
./Build install

Aller plus loin

  • # LemonLDAP::NG

    Posté par (page perso) . Évalué à 10 (+8/-0).

    Dans l'écosystème Perl on peut également citer LemonLDAP::NG, une solution libre de WebSSO, contrôle d'accès et fédération d'identité, massivement déployée dans le secteur public en France.

  • # Un projet Perl sympa et qui a de l'impact.

    Posté par . Évalué à 10 (+10/-0).

    Je ne sais pas si on fait du Perl moderne ou post-moderne, mais un projet Perl sympa et qui a (beaucoup) d'impact, c'est Open Food Facts :-)

    C'est du code qui permet a des millions de français (et plus) de mieux manger, et il y a pas besoin d'un niveau avancé en Perl pour contribuer de manière significative :)

    si ça vous dit:
    https://github.com/openfoodfacts/openfoodfacts-server
    et contact at openfoodfacts pouint org

    Pierre

  • # Je veux crier ma haine !

    Posté par . Évalué à 4 (+8/-6).

    En général, sur un projet avec du perl dedans, ma première réaction c'est la fuite.

    Quelques phrases que j'ai (trop) souvent entendu :

    • "on a enfin trouvé pourquoi le script xxxxxx était super lent ; c'était la partie perl" (et je travaille essentiellement sur des applications en Java, pas le truc réputé rapide, hein…)

    • "on a un script perl écrit il y a plusieurs années, mais personne n'ose y toucher, donc on corrige les bugs dans un script qui tourne juste après" (et je travaille avec des applications legacy basées sur des frameworks qui ont souvent disparu depuis plusieurs années)

    Autant, j'arrive à justifier la présence de Python pour disposer des outils de machine learning ou faire du prototypage rapide autant pour Perl…

    Et comme disait mon ancien boss : "la différence entre perl et whitespace, c'est que dans whitespace, l'obfuscation c'est fait exprès". La même marche aussi avec lisp, évidemment.

    • [^] # Re: Je veux crier ma haine !

      Posté par . Évalué à 6 (+4/-0).

      "on a enfin trouvé pourquoi le script xxxxxx était super lent ; c'était la partie perl" (et je travaille essentiellement sur des applications en Java, pas le truc réputé rapide, hein…)

      Je ne suis plus un fan de Perl, mais là … Perl a en général de perfs très bonnes, bien meilleures que Python. Du coup je me demande si c'est réellement la partie Perl qui pose problème. A moins que la personne ait tenté de faire du Perl multithreadé et s'est vautré dans son dev (libs pas prévues pour, gestion calamiteuses des locks …) mais dans ce cas c pas Perl le problème, mais le dev (un autre langage aurait causé les mêmes problèmes).

      "on a enfin trouvé pourquoi le script xxxxxx était super lent ; c'était la partie perl" (et je travaille essentiellement sur des applications en Java, pas le truc réputé rapide, hein…)

      Ca par contre je le comprends.

      • [^] # Re: Je veux crier ma haine !

        Posté par (page perso) . Évalué à 4 (+2/-0).

        Ca par contre je le comprends.

        Pas moi. Mais je crois que c'est dû a une erreur de copié-collé.
        Ou alors je suis hermétique à ton humour.

        • [^] # Re: Je veux crier ma haine !

          Posté par (page perso) . Évalué à 4 (+2/-0).

          Ou alors je suis hermétique à ton humour.

          c'est une remarque d'ops, pas de dév

          • dev : chez moi ça marche le parsing du fichier de log de 10 Mo sur mon pc fixe avec 16 Go de RAM et quad-core
          • ops : bin avec 4 Go de log dans la VM 2vCPU / 4 Go RAM, moins :/
        • [^] # Re: Je veux crier ma haine !

          Posté par . Évalué à 2 (+0/-0).

          Effectivement, erreur de copier coller. Je voulais coller la partie indiquant que oersonne ne voulait toucher le code Perl développé il y a longtemps.

    • [^] # Re: Je veux crier ma haine !

      Posté par (page perso) . Évalué à 6 (+4/-0).

      "on a un script perl écrit il y a plusieurs années, mais personne n'ose y toucher, donc on corrige les bugs dans un script qui tourne juste après"

      Perso, il me semble que dans tous les langages dynamiques du style (Perl, Python, …), si le code est maladroit ou n'a pas de tests, on n'ose pas y toucher.

      Tu comparerais à des langages fortement typés comme Go ou Rust et là je te dirais, oui, le code vite-fait et sans tests fait nettement moins peur (après, du code sans tests fait toujours un peu peur à moins que ce soit court). Mais Python ou Perl ou Ruby ou Tcl, pour moi c'est à peu près les mêmes vraies difficultés : tous ces langages offrent très peu de garanties à la compilation (Tcl quasiment aucune, Python un peu plus mais moins que Perl avec use warnings et use strict) et permettent d'écrire de façon trop intelligente, car ils sont très flexibles et ont beaucoup de fonctionnalités.

      Par exemple : systèmes OO très riches (sans l'extension Moose, Python va même plus loin par défaut que Perl dans les abstractions non évidentes comme les itérateurs etc.), du mutable dans tous les sens (Tcl s'en sort mieux que Perl et Python pour ça), plein de sucre syntaxique ad hoc (list comprehensions en Python, manipulation de chaînes en Perl), effets de bords pas évidents à détecter (OO), portée non lexicale (i.e pas par blocs) des variables en Python et Tcl, dépendances circulaires de modules, overload d'opérateurs (particulièrement présent en Python, beaucoup moins en Perl ou Tcl), différents types d'égalité (is vs ==, etc.), des booléens qui sont des entiers (True == 1) et, dans tous les cas, gare au typos dans les noms de fonctions ou variables (Perl détecte les typos dans les noms de variables, mais pas des fonctions, Python aucun des deux et Tcl ne détecte aucune sorte de typos, même dans les mots-clés du langage, car ce sont de simples fonctions). Et on pourrait continuer longtemps.

      Même si j'aime beaucoup les langages dynamiques (même le plus dynamique d'entre eux qui est Tcl), je trouve qu'ils demandent tous une grande discipline et que les différences de clarté entre les plus connus sont assez insignifiantes au final : les difficultés résident dans la nature de ces langages et leur flexibilité, pas dans leur utilisation des $ ou l'indentation qui font pourtant souvent plus parler d'elles.

      Bref, dans le doute et sans connaissances au préalable d'un projet, je préfère lire du Go :-)

    • [^] # Re: Je veux crier ma haine !

      Posté par . Évalué à 7 (+5/-0).

      Et comme disait mon ancien boss : "la différence entre perl et whitespace, c'est que dans whitespace, l'obfuscation c'est fait exprès". La même marche aussi avec lisp, évidemment.

      Blage à part, écrire des programmes illisibles ou difficiles à modifier pour d'autres raisons est plus une question d'état d'esprit que de langage.

      Qu'il s'agisse de Java, Perl, Lisp, C, Python ou quoique ce soit d'autre. Même en Shell on peut écrire des programmes propre et maintenables, c'est dire!

      • [^] # Re: Je veux crier ma haine !

        Posté par . Évalué à 5 (+4/-1).

        Disons qu'avec certains langages c'est plus facile d'écrire du code illisible qu'avec d'autres.

      • [^] # Re: Je veux crier ma haine !

        Posté par . Évalué à 2 (+1/-1).

        Des langages ont plus idiomatiques que d'autres, plus expressif, et donc plus facilement obscur pour qqun qui ne les connaît pas bien.
        Perl est IMHO très idiomatique : beaucoup de tournures que l'on ne comprend pas à la lecture sans vraiment maîtriser le langage.
        Java est IMHO peu idiomatique : ça se lit. Pour rendre un programme très obscure, volontairement ou non, il faut multiplier les indirections (héritage à plusieurs niveau avec surcharge, factory).

    • [^] # Re: Je veux crier ma haine !

      Posté par . Évalué à 4 (+3/-0).

      "on a enfin trouvé pourquoi le script xxxxxx était super lent ; c'était la partie perl"

      "on a un script perl écrit il y a plusieurs années, mais personne n'ose y toucher"

      Est-ce qu'il n'y aurait pas un rapport entre les deux phrases ?

      « La partie que personne ne maîtrise, dans un langage qui n'est pas celui qu'on connaît le mieux, qui a été codé il y a 20 ans et que personne n'ose toucher n'est pas la partie la plus optimisée ».

      ^_^

  • # Perl 5 ?

    Posté par (page perso) . Évalué à 4 (+2/-0).

    Je rêve ou bien ? Je quitte LinuxFR pendant 10 ans, je reviens et Perl 6 n'est toujours pas sorti ? C'est quoi c'brin ?

    /o\

    • [^] # Re: Perl 5 ?

      Posté par . Évalué à 6 (+5/-0).

      On t'a dit pour Hurd ?

      Par contre Debian est sortie. Plusieurs fois même.

    • [^] # Re: Perl 5 ?

      Posté par . Évalué à 0 (+0/-0). Dernière modification le 20/07/19 à 08:38.

      Perl 6 est sorti en 2015…

Envoyer un commentaire

Suivre le flux des commentaires

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