Informatique‎ > ‎

Se (re)lancer en Perl

Se lancer dans Perl aujourd'hui est une grande et belle aventure mais qui peut mal tourner si l'on ne se prépare pas un minimum. Perl est un langage qui a évolué avec le temps, et il s'agit de se caler sur les coutumes du moment, pas celles datant de 1997. Se replonger dans le langage nécessite également de se débarrasser de certaies mauvaises habitudes qui auraient pu être prises par le passé. Les quelques conseils ci-dessous devraient permettre d'éviter les déconvenues et les incompréhensions.


Bookmarks

Chercher de l'information ou de l'aide sur Perl peut parfois tourner à l'archéologie involontaire. Le Web héberge un certain nombre de sites bien intentionnés au moment de leur écriture mais franchement périmés et néfastes aujourd'hui. Malheureusement, ce sont souvent ceux que Google retourne en premier en réponse aux requêtes qu'on lui soumet. Une première astuce consiste à éviter tout site parlant de PERL. Il s'agit du symptôme typique du site dont la dernière mise à jour date de dix ans. Il fut un temps où PERL désignait le langage inventé par Larry Wall mais depuis bien longtemps, ce langage s'appelle Perl. Cela n'a l'air de rien, mais ce simple filtrage permet d'évacuer une très grande quantité de sites anciens (ou approximatifs), susceptible de faire perdre son temps au débutant, voire de le dégoûter du langage. Voici une petite liste de sites de référence :

  • La série menée par Gabor Szabo
  • Learn Perl
  • Modern Perl, livre en PDF
  • Le blog de chromatic, auteur du livre ci-dessus
  • Les blogs peuplant blogs.perl.org
  • Beaucoup de modules récents, comme Dancer, Moose, Catalyst fournissent un manuel complet ainsi qu'un tutorial avec le code. On peut consulter ces manuels soit via perldoc, soit depuis son navigateur Web, sur MetaCPAN.
  • StackOverflow est devenu la référence pour poser ses questions et obtenir des réponses pertinentes. En ce qui concerne Perl, de très grands noms fréquentent le site et y répondent aux questions posées par les utilisateurs. Bref, StackOverflow est parvenu à offrir la même qualité que ce que l'on a pu trouver sur Usenet il y a quelques années.
  • En France, nous avons également la liste de diffusion des Mongueurs de Perl. Même si l'on a pas de question à poser, c'est toujours une bonne idée de s'y abonner, pour lire du code et obtenir des réponses à des questions que l'on ne s'est pas encore posé...

Livres de référence

Perl a la chance de disposer d'excellents ouvrages s'adressant à tout le monde, du débutant au développeur confirmé. Une page de ce site est consacrée aux présentations détaillées des ouvrages de qualité pour Perl (et d'autres sujets).

  • Modern Perl constitue un guide concis et très à jour du langage.
  • Perl Moderne, publié en 2010, se présente comme un guide de survie et remplit à merveille sa mission. A noter qu'il est intégralement en français.
  • Effective Perl Programming, datant pour sa seconde édition de 2009, offre une collection de conseils précieux à la manière d'un cookbook de luxe.
  • La trilogie Learning Perl, Intermediate Perl et Mastering Perl appartient également aux livres de référence.
  • Perl Best Practices, même s'il est parfois un peu daté, car publié en 2005, fournit tout de même beaucoup d'excellents conseils quant aux bonnes pratiques de la programmation en Perl.
  • En revanche, il est important de noter que Programming Perl, dans sa troisième édition, est à éviter, car périmé sur bien des points. La quatrième édition, prévue pour la fin de l'année, devrait cependant y remédier.
  • Head First Design Patterns, même s'il s'appuie sur du code Java, constitue une excellente base pour intégrer les problématiques propres à l'objet et les méthodes consacrées par l'usage pour y répondre. Combiner son apprentissage de l'objet en Perl avec Moose et la lecture de ce livre permet là encore de s'épargner bien des soucis typiques de la programmation objet.

Les bons outils

Il existe aujourd'hui plusieurs manières d'installer perl ainsi que plusieurs outils gravitant autour.

Sous FreeBSD, OpenBSD et NetBSD, installer perl consiste à simplement passer par le système de package proposé par ces systèmes. Des versions très à jour du langage y sont proposées.

Sous Linux, certaines distributions traînent la patte. C'est notamment le cas de RedHat, qui ne propose que perl 5.8 pour sa RedHat 5 et perl 5.10 pour la 6, quand la dernière version de perl est la 5.14. Il s'agit alors, pour être à jour, de l'installer à la main si l'on veut bénéficier des dernières nouveautés. La version 5.10 permet cependant déjà de profiter de beaucoup de bonnes choses et peut se montrer suffisante dans la majorité des cas. Les distributions Fedora et openSuSE se montrent en revanche plus à jour et proposent la dernière version sous forme d'archive RPM.

Sous Windows, la meilleure solution consiste à installer StrawberryPerl. Ceci permet d'une part de profiter d'une version toujours à jour du langage, mais aussi de disposer de quelques outils précieux comblant l'absence de certains outils fondamentaux, comme dmake qui permet la compilation de code source quand Windows n'offre rien par défaut. StrawberryPerl autorise également les installations sur stockage externe et l'on peut donc toujours avoir sur soi une clef USB contenant un environnement Perl de secours.

L'outillage relatif au CPAN dépasse également aujourd'hui le seul utilitaire cpan.

  • CPANminus (ou cpanm) offre une interface particulièrement simple et concise pour l'installation de modules en provenance du CPAN. A noter que dès lors que local::lib est présent, les modules sont désormais installés dans le répertoire personnel de l'utilisateur, au lieu d'être écrits dans des répertoires réservés à l'administrateur, comme c'était le cas par le passé.
  • local::lib est le module permettant l'installation des modules dans son répertoire personnel, comme décrit plus haut.

Les bonnes habitudes

Il suffit de quelques bonnes habitudes à prendre pour se lancer sans peine dans le monde de Perl.

Les pragmas à utiliser

Certains pragmas sont aujourd'hui tout simplement incontournables, parce qu'ils permettent d'obtenir un comportement plus prévisible du code, parce qu'ils fournissent un affichage des messages d'erreur plus lisible ou encore parce qu'ils permettent d'utiliser les fonctionnalités des versions récentes de Perl. Ainsi, il est recommandé d'utiliser les pragmas suivants systématiquement :

  • use strict; Permet de contrôler la déclaration des variables, de prévenir l'usage de variables non initialisées, etc.
  • use warnings; S'inscrit dans la lignée du précédent en fournissant des avertissements pour toute construction semblant hasardeuse.
  • use 5.010; Permet de bénéficier des fonctionalités de Perl 5.10.
  • use utf8; Déclare que le fichier source est encodé en UTF-8. Ecrire son fichier dans cet encodage facilite grandement son partage par la suite.
  • use diagnostics; Permet d'afficher un extrait du manuel de Perl en cas d'erreur. Ce pragma est un incontournable lorsque l'on débute ou lorsque l'on se replonge dans Perl après une longue absence, tant il fait office de compagnon avisé, indiquant les points sensibles à travailler ou à creuser.

Créer ses modules

Par le passé, la création de modules impliquait de rédiger à la main les différents fichiers constituant une distribution digne de ce nom : README, COPYING, AUTHORS, ainsi que les scripts permettant d'installer le module en question. Plus tard, ExtUtils::MakeMaker, Module::Build et Module::Starter ont simplifié toutes ces tâches, facilitant la déclaration des dépendances et permettant de démarrer directement dans une arborescence standardisée. Désormais, Dist::Zilla remplit toutes ces fonctions et offre encore d'autres services autour des tests, de la documentation et de la publication sur le CPAN, tout en se montrant encore plus simple d'usage. Il est à noter qu'au final, c'est toujours ExtUtils::MakeMaker qui se charge de construire le module, mais toute la configuration est préparée aussi automagiquement que possible par Dist::Zilla.

Bien déclarer sa version

Les modules de Perl présentent l'avantage de pouvoir communiquer leur version au code y faisant appel (ainsi que de l'indiquer clairement au programmeur lisant leur code source). En revanche, la manière de présenter cette version a suscité bien des débats (et c'est peut-être l'une des rares fois où l'on aurait peut-être préféré qu'il n'y ait qu'une seule manière de faire...). Aujourd'hui, la pratique consiste à déclarer sa version de la manière suivante :

package Mon::Package;
use strict;
use warnings;
use 5.010;
use utf8;

{
  $Mon::Package::VERSION = '1.020005';
}

Le package ci-dessus affiche une version de 1.20.5. Les versions de Perl se lisent de la manière suivante : une version majeure (1, ici), un numéro mineur sur trois chiffres (020, ici) et un numéro de révision, également sur trois chiffres (005 dans l'exemple). C'est la raison pour laquelle on écrit use 5.010; et non use 5.10;. Il est également à noter que par convention, les version comportant un underscore sont considérées comme des releases pour développeur, ou des versions alpha. Ainsi,

package Mon::Package;
use strict;
use warnings;
use 5.010;
use utf8;

{
  $Mon::Package::VERSION = '1.020005_001';
}

attribue au module Mon::Package le numéro de version 1.20.5_1. Un tel module, s'il est publié sur PAUSE, ne sera pas indexé et ne sera pas visible sur le CPAN.

Bien déclarer ses dépendences

Déclarer la version de ses modules est une bonne chose ; indiquer clairement celles de ses dépendences en est le pendant direct. Au cours de l'écriture d'un module, on installe un certain nombre de modules depuis le CPAN. Ceux-ci vont par défaut être installés dans leur dernière version, et c'est probablement ce que l'on veut, afin de profiter du code le plus à jour. En revanche, une fois publié, si notre module ne précise pas les versions de ses dépendances, il risque d'être installé aux côtés de modules dont la version est en réalité inférieure à celle requise. Ce genre de scénario débouche généralement sur des bugs difficiles à tracer, ou en tout cas embarassants pour le développeur.

Une solution simple consiste à indiquer, au moment du use, la version nécessaire au bon fonctionnement du module :

package Mon::Package;
use strict;
use warnings;
use 5.010;
use utf8;
use Moose 0.92;

Chercher et sélectionner un module

Si CPAN.org reste le site central où sont mis à disposition tous les modules Perl, il existe aujourd'hui une interface Web mieux pensée pour en consulter le catalogue, metacpan.org. Il s'agit seulement d'une interface Web qui s'appuie en coulisse sur les Web Services de cpan.org, il n'y a donc aucun changement quant au contenu, si ce n'est que celui-ci profite d'une présentation plus synthétique, plus agréable et plus lisible. On voit ainsi tout de suite et facilement non seulement la date dernière mise à jour du module dont on consulte la page, mais aussi l'activité autour de ce bout de code (pratique pour repérer les modules endormis, ou au contraire sujets à beaucoup de changements), on gagne une coloration du code des exemples, une liste de toutes les dépendances, le résultat des derniers tests automatiques ; bref, on a toute l'information nécessaire pour sélectionner son module.

Le fait que la date de dernière mise à jour et que l'activité soit clairement présentée n'est pas innocent : le CPAN héberge plus de 20 000 modules et plus de 80 000 distributions, couvrant toute l'existence de Perl. Certains sont très anciens mais toujours utilisés, comme DBI, d'autres sont périmés mais laissés à disposition pour qui veut les reprendre ou simplement pour des raisons de compatibilité. Forcément, faire son choix dans un catalogue aussi vaste n'est pas facile. Le bon réflexe pour éviter que l'éventail des possibilités ne se change en épouvantail consiste à toujours garder un oeil sur la date et l'activité. Lorsque plusieurs modules proposent des choses similaires, le plus récent est peut-être un choix plus sûr et permet de s'assurer que l'on va trouver d'autres utilisateurs de ce module.

Enfin, il existe sur le CPAN un meta-module baptisé Task::Kensho. Il s'agit en réalité d'une liste de modules jugés sûrs et pertinents par l'équipe derrière l'initiative Enlightened Perl. Task::Kensho constitue un excellent point de départ pour se faire une idée des modules modernes et pérennes que l'on peut utiliser, voire dont on peut étudier le code.

Ne pas utiliser les regex aveuglément

Perl, parce qu'il a fait des expressions rationelles des éléments de premier plan au sein de sa syntaxe, a su se tailler une belle réputation dans le domaine. Malheureusement, la facilité avec laquelle cet outil peut être utilisé mène parfois à des usages abusifs. Afin de bien utiliser les expressions rationnelles, il suffit de suivre quelques règles simples :

  • Ne pas utiliser les regex pour parser du HTML (ou du XML). Utiliser HTML::Parser, HTML::TreeBuilder et XML::Twig, par exemple.
  • Bien étudier les modificateurs d'expressions et utiliser xms.
  • Ne pas utiliser les regex pour de simples recherches de chaînes. Utiliser substr à la place.
  • Ne pas écrire des regex pour des motifs connus et pour lesquelles un module dédié a déjà été publié sur le CPAN. Par exemple, il est contre-productif de chercher à écrire une regex pour capturer un email quand on en trouve une, bien testée, très utilisée, écrite par une pointure comme Abigail et qui fait partie du bundle Regexp::Common

Utiliser Moose

Dès lors qu'il s'agit de développer des applications conséquentes, complexes et nécessitant la mise en place d'objets, le bon réflexe consiste à s'orienter vers Moose. Moose permet de bénéficier d'un système d'objets capable de gérer l'héritage (même multiple), le typage des données, l'implémentation de rôles (similaires aux catégories de Smalltalk et Objective-C ou aux mixins de Ruby) et tout ce qui fait un système d'objets moderne. Il reprend autant que possible les idées du Meta Object Protocol, sur lequel s'appuie le Common Lisp Object System, dont la puissance et la souplesse ne sont plus à prouver. Moose fournit pour tout ceci une syntaxe permettant de nombreuses facilités, comme la génération d'accesseurs, ou la définition court-circuits typique de l'Aspect Oriented Programming (before, after, around). Au final, on écrit moins de code et ce code en fait beaucoup plus et de manière plus souple que s'il avait été écrit à la main. Enfin, tout ceci reste du Perl et ne pose donc absolument aucun problème de compatibilité avec quoi que ce soit.

kafka - Janvier 2012

Réagir par mail