Perl 5.42 est sorti

Posté par Emmanuel Seyman le 18 août 2025 à 13:18. Édité par Benoît Sibaud. Modéré par patrick_g. Licence CC By‑SA.

Étiquettes :

août

2025

Perl est un langage généraliste créé en 1987 par Larry Wall. Il est distribué sous une double licence : Artistic Licence et GPL v1+. La plupart des modules du CPAN, dépôt de référence pour des modules tiers, sont également sous ces deux licences. Perl est inclus dans la quasi-totalité des distributions GNU/Linux, parfois installé par défaut.

La toute dernière version de Perl, la 5.42.0, est sortie le 3 juillet 2025. Vous la retrouverez bientôt dans votre distribution préférée.

L’association Les Mongueurs de Perl fait la promotion du langage dans les pays francophones, et ce depuis la fin de l’année 2001

Sommaire

Améliorations principales
Sécurité
- [CVE-2024-56406] Vulnérabilité de dépassement de tampon avec tr//
- [CVE-2025-40909] Les threads Perl présentent une situation de concurrence entre les répertoires de travail : les opérations sur les fichiers peuvent cibler des chemins non prévus.
Modifications incompatibles
- Suppression des références de fonctions englobantes pour les fonctions sans évaluation
Améliorations des performances

Améliorations principales

Nouveaux sous-programmes CORE::

chdir a été ajouté comme sous-programme à l'espace de noms CORE::.

Jusqu’ici, du code comme &CORE::chdir($dir) ou my $ref = \&CORE::chdir; $ref->($dir) renvoyait une erreur indiquant que &CORE::chdir ne peut pas être appelé directement. Ces cas sont désormais entièrement pris en charge.

Nouveau pragma `source::encoding`

Voir source::encoding

Ceci vous permet de déclarer que la partie d’un programme correspondant au reste de la portée lexicale de ce pragma est encodée soit entièrement en ASCII (pour use source::encoding 'ascii'), ou que l’UTF-8 est autorisé également (pour use source::encoding 'utf8'). Aucun autre codage n’est accepté. La seconde forme est entièrement équivalente à use utf8 et peut être utilisée de manière interchangeable.

Ce pragma a pour but de détecter rapidement les cas où vous avez oublié de spécifier use utf8.

use source::encoding 'ascii' est automatiquement activé dans la portée lexicale d’un use v5.41.0 ou supérieur.

no source::encoding désactive toutes ces vérifications pour le reste de sa portée lexicale. La signification des caractères non-ASCII n’est alors pas définie.

Nouvel attribut `:writer` sur les variables de champ

Les classes définies avec use feature 'class' peuvent désormais créer automatiquement des accesseurs d’écriture pour les champs scalaires, à l’aide de l’attribut :writer, de la même manière que :reader crée déjà des accesseurs de lecture.

class Point {
field $x :reader :writer :param;
field $y :reader :writer :param;
}


my $p = Point->new( x => 20, y => 40 );
$p->set\_x(60);

Nouveaux opérateurs `any` et `all`

Ajout de deux nouvelles fonctionnalités expérimentales, introduisant les opérateurs de traitement de liste any et all.

use v5.42 ;
use feature 'keyword\_all' ;
no warning 'experimental::keyword\_all' ;


my @nombres = ...


if ( all { $\_ % 2 == 0 } @nombres ) {
  say "Tous les nombres sont pairs" ;
}

Ces mots-clés fonctionnent de manière similaire à grep, sauf qu’ils ne renvoient que vrai ou faux, testant si un des éléments (ou tous) de la liste fait que le bloc de test renvoie vrai. De ce fait, ils peuvent court-circuiter, évitant ainsi de tester d’autres éléments si un élément donné détermine le résultat final.

Ces fonctions s’inspirent des fonctions du même nom du module List::Util, à la différence qu’elles sont implémentées comme des opérateurs de base directs, et donc plus rapides, et ne génèrent pas de trame de pile d’appel de sous-routine supplémentaire pour invoquer le bloc de code.

Les indicateurs de fonctionnalité activant ces mots-clés ont été nommés keyword_any et keyword_all afin d’éviter toute confusion avec la capacité du module feature à faire référence à toutes ses fonctionnalités à l’aide de la balise d’exportation :all. [GH #23104]

Les indicateurs d’avertissement expérimentaux associés sont donc nommés experimental::keyword_any et experimental::keyword_all.

L’apostrophe comme séparateur de noms global peut être désactivée.

Ceci a été déclaré obsolète dans Perl 5.38 et supprimé comme prévu dans Perl 5.41.3, mais, après discussion, il a été rétabli par défaut.

Ceci peut être contrôlé avec la fonctionnalité apostrophe_as_package_separator, activée par défaut, mais désactivée à partir du bundle de fonctionnalités 5.41.

Si vous souhaitez désactiver son utilisation dans votre propre code, vous pouvez la désactiver explicitement :

no feature "apostrophe\_as\_package\_separator";

Notez que la désactivation de cette fonctionnalité empêche uniquement l’utilisation de l’apostrophe comme séparateur de paquets dans le code ; les références symboliques traitent toujours ' comme :: même si la fonctionnalité est désactivée :

my $symref = "My'Module'Var";
\# fonctionnalités par défaut
my $x = $My'Module'Var; # fine
no feature "apostrophe\_as\_package\_separator";
no strict "refs";
my $y = $$symref; # comme $My::Module::Var
my $z = $My'Module'Var; # erreur de syntaxe

[GH #22644]

Déclaration de méthode lexicale avec `my method`

Comme sub depuis la version 5.18 de Perl, method peut désormais être préfixé par le mot-clé my. Cela déclare une sous-routine avec une visibilité lexicale, plutôt que de package. Voir perlclass pour plus de détails.

Opérateur d’invocation de méthode lexicale `->&`

Outre la possibilité de déclarer des méthodes de manière lexicale, cette version permet également d’invoquer une sous-routine lexicale comme s’il s’agissait d’une méthode, sans passer par la résolution habituelle des méthodes par nom.

Combinées à la déclaration de méthode lexicale, ces deux nouvelles fonctionnalités créent l’effet de méthodes privées.

Opérateur de commutation et de correspondance intelligente conservé, derrière une fonctionnalité

La fonctionnalité « switch » et l’opérateur de correspondance intelligente, ~~, ont été introduits dans la version 5.10. Leur comportement a été considérablement modifié dans la version 5.10.1. Avec l’ajout du système « experiment » dans la version 5.18.0, le « switch » et le smartmatch ont été rétroactivement déclarés expérimentaux. Au fil des ans, les propositions visant à corriger ou à compléter ces fonctionnalités ont été nombreuses et ont été abandonnées.

Elles ont été déclarées obsolètes dans Perl v5.38.0 et leur suppression était prévue dans Perl v5.42.0. Après de longues discussions, leur suppression a été reportée sine die. Leur utilisation ne génère plus d’avertissement d’obsolescence.

Switch lui-même nécessite toujours la fonctionnalité switch, activée par défaut pour les bundles de fonctionnalités de la version 5.9.5 à la version 5.34. Switch reste désactivé dans les bundles de fonctionnalités 5.35 et ultérieurs, mais peut être activé séparément :

\# pas de switch ici
use v5.10;
\# switch accepté ici
use v5.36;
\# pas de switch ici
use feature "switch"; # switch accepté ici

La correspondance intelligente nécessite désormais la fonctionnalité smartmatch, activée par défaut et incluse dans tous les bundles de fonctionnalités jusqu’à la version 5.40. Elle est désactivée à partir de la version 5.41, mais peut être activée séparément :

\# smartmatch accepté ici
use v5.41;
\# pas de smartmatch ici
use feature "smartmatch";
\# smartmatch accepté ici

[GH #22752]

Unicode 16.0 pris en charge

Perl prend désormais en charge Unicode 16.0, y compris les modifications introduites dans la version 15.1.

Assignation de l’opérateur logique xor `^^=`

Perl 5.40.0 avait introduit l’opérateur logique OU exclusif à priorité moyenne ^^. L’absence de la variante d’assignation ^^= n’avait pas été remarquée à l’époque. Cet oubli est désormais corrigé.

Sécurité

[CVE-2024-56406] Vulnérabilité de dépassement de tampon avec tr//

Une vulnérabilité de dépassement de tampon a été découverte dans Perl.

Lorsque des octets non-ASCII se trouvent à gauche de l’opérateur tr, S_do_trans_invmap() peut faire déborder le pointeur de destination d.

$ perl -e '$\_ = "\x{FF}" x 1000000; tr/\xFF/\x{100}/;'
Segmentation fault (core dumped)

On pense que cette vulnérabilité peut permettre des attaques par déni de service ou par exécution de code arbitraire sur les plateformes dépourvues de défenses suffisantes.

Ce problème a été découvert par Nathan Mills et déclaré [CVE-2024-56406] par le groupe de sécurité CPAN.

Le correctif pour corriger ce problème (87f42aa0e0096e9a346c9672aa3a0bd3bef8c1dd) s’applique à tous les Perl vulnérables, y compris ceux qui ne sont plus pris en charge.

[CVE-2025-40909] Les threads Perl présentent une situation de concurrence entre les répertoires de travail : les opérations sur les fichiers peuvent cibler des chemins non prévus.

Le clonage de threads Perl présentait une situation de concurrence entre les répertoires de travail : les opérations sur les fichiers peuvent cibler des chemins non prévus. Perl 5.42 ne fera plus un chdir avec chaque handle.

Ce problème a été découvert par Vincent Lefèvre via [GH #23010] et déclaré [CVE-2025-40909] par le groupe de sécurité CPAN.

Des correctifs ont été fournis via [GH #23019] et [GH #23361].

Modifications incompatibles

Suppression des références de fonctions englobantes pour les fonctions sans évaluation

Perl 5.40 a réintroduit les références inconditionnelles des fonctions vers les fonctions englobantes afin de corriger un bug introduit dans Perl 5.18 qui perturbait le comportement spécial de eval EXPR dans le paquet DB utilisé par le débogueur.

Dans certains cas, cette modification entraînait des chaînes de références circulaires entre les fermetures et d’autres références existantes, entraînant des fuites de mémoire.

Cette modification a été annulée, corrigeant le problème [GH #22547], mais le perturbant à nouveau [GH #19370].

Cela signifie que les boucles de référence ne se produiront pas et que les variables lexicales et les fonctions lexicales des fonctions englobantes pourraient ne pas être visibles dans le débogueur.

Notez que l’appel inconditionnel de eval EXPR dans une fonction force celle-ci à référencer ses fonctions englobantes comme elle l’a toujours fait.

Améliorations des performances

Les chaînes obtenues par une formule évaluée à la compilation sont désormais partageables via le mécanisme de copie sur écriture. [GH #22163]

Le code suivant aurait auparavant alloué onze tampons de chaînes, contenant chacun un million de « A » :

    my @scalars; push @scalars, ("A" x 1\_000\_000) for 0..9;

Un seul tampon est désormais alloué et partagé entre une opération CONST et les dix éléments scalaires de @scalars.

Notez que tout code utilisant ce type de constante pour simuler des fuites mémoire (par exemple dans des fichiers de test) doit désormais permuter la chaîne afin de déclencher une copie de la chaîne et l’allocation de tampons séparés. Par exemple, ("A" x 1_000_000).time pourrait être une petite modification appropriée.

tr/// s’exécute désormais à la même vitesse, quelle que soit la représentation interne de son opérande, tant que les seuls caractères traduits sont de type ASCII, par exemple : tr/A-Z/a-z/. Auparavant, si l’encodage interne était UTF-8, une implémentation plus lente et plus générale était utilisée.
Le code qui utilise la fonction indexed du module builtin pour générer une liste de paires index/valeur à partir d’un tableau ou d’une liste, puis la transmettre à une liste foreach à deux variables pour les décompresser, est désormais optimisé pour être plus efficace.

    my @array = (...);


    foreach my ($idx, $val) (builtin::indexed @array) {
    ...
    }



    foreach my ($idx, $val) (builtin::indexed LIST...) {
    ...
    }

En particulier, il n’y a plus génération d’une liste temporaire deux fois plus grande que l’originale. Au lieu de cela, la boucle parcourt le tableau ou la liste d’origine directement sur place, de la même manière que foreach (@array) ou foreach (LIST).

L’optimiseur à lucarne reconnaît les motifs substr à décalage nul suivants et les remplace par un nouvel opérateur dédié (OP_SUBSTR_LEFT). [GH #22785]

    substr($x, 0, ...)
    substr($x, 0, ..., '')

La transformation en chaîne des entiers par "print" in perlfunc et "say" in perlfunc, lorsqu’ils proviennent d’un SVt_IV, est désormais plus efficace. [GH #22927]
L’inversion de chaîne à partir d’un seul argument, lorsque le tampon de chaîne n’est pas « balayé », s’effectue désormais en une seule passe et est sensiblement plus rapide. L’ampleur de l’amélioration dépend du compilateur et du matériel. [GH #23012]

Aller plus loin

Perl sur Wikipedia (52 clics)
Guide Perl - Débuter et progresser en Perl (53 clics)
L'association Les Mongueurs de Perl (43 clics)

# 30 ans du CPAN

Posté par Sytoka Modon (site web personnel) le 18 août 2025 à 17:26. Évalué à 10 (+8/-0).

Et le 16 août, soit il y a deux jours, c'était l'anniversaire du CPAN : 30 ans déjà. Le CPAN avait repris l'idée du CTAN (TeX) en améliorant encore le concept. Le CPAN est une super idée plutôt que d'aller disperser le code sur 50 forges… plus ou moins libre. Au moins, le code est sur 50 CPAN !

Bref, Perl c'est du bon, mangez-en.

Répondre
# bloc peu lisible

Posté par Nicolas Boulay (site web personnel) le 19 août 2025 à 09:16. Évalué à 4 (+1/-0). Dernière modification le 19 août 2025 à 09:16.

Il est nécessaire de scroller horizontalement pour lire la phrase :

"Notez que tout code utilisant ce type de constante pour simuler des fuites mémoire (par exemple dans des fichiers de test) doit désormais permuter la chaîne afin de déclencher une copie de la chaîne et l’allocation de tampons séparés. Par exemple, ("A" x 1_000_000).time pourrait être une petite modification appropriée."

idem pour :

"En particulier, il n’y a plus génération d’une liste temporaire deux fois plus grande que l’originale. Au lieu de cela, la boucle parcourt le tableau ou la liste d’origine directement sur place, de la même manière que foreach (@array) ou foreach (LIST)."

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

Répondre
- [^] # Re: bloc peu lisible
  
  Posté par Benoît Sibaud (site web personnel) le 19 août 2025 à 10:30. Évalué à 4 (+1/-0).
  
  Corrigé, merci.
  
  Répondre
# History

Posté par Marcel4567 le 19 août 2025 à 11:02. Évalué à 3 (+5/-3).

Y a encore des gens qui utilisent Perl ? C’était à la mode dans les années 2000-2010 mais ça fait bien 10 ans que j’en ai pas vu…

Répondre
- [^] # Re: History
  
  Posté par oau le 19 août 2025 à 11:25. Évalué à 5 (+3/-0).
  
  j'avoue. J'ai écris du perl pendant 15ans. Depuis 10ans je fais du python et quand je reviens sur le perl que j'ai écris à la fin des années 2000. Ouille ca pique.
  
  Répondre
  - [^] # Re: History
    
    Posté par Benoît Sibaud (site web personnel) le 19 août 2025 à 11:44. Évalué à 10 (+9/-0). Dernière modification le 19 août 2025 à 13:16.
    
    https://packages.debian.org/trixie/perl-base paquet encore obligatoire sur une Debian 13 (100% d'installation sur le Debian Popularity Contest de fait https://qa.debian.org/popcon.php?package=perl )
    
    encore assez haut au classement TIOBE https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/ par exemple
    
    beaucoup plus profond dans https://spectrum.ieee.org/top-programming-languages-2024 ou dans https://www.statista.com/statistics/793628/worldwide-developer-survey-most-used-languages/
    
    Je dirais que le nombre de personnes qui en code chute, tandis que le nombre de personnes qui l'utilise est assez constant (même si c'est à leur insu de fait).
    
    Répondre
  - [^] # Re: History
    
    Posté par YBoy360 (site web personnel) le 24 août 2025 à 03:31. Évalué à 2 (+0/-0).
    
    Les outils Mandrake était en Perl (donc les dérivés actuels utilisent Perl pour leurs outillages), c'est vrai qu'a la relecture il y a un temps d'adaptation, mais on s'y fait. Il a été question de porté les outils en Python, mais aucun intérêt concret n'a convaincu les mainteneurs.
    
    Personnellement, j'aime à peine plus Python que Perl. Mais, c'est vrai que ce qui m'a fait apprécier Linux, c'est Qt et son binding Python.
    
    Aujourd'hui, j'apprécie le typage statique, des gros IDE en Java, et pouvoir redistribuer sur toutes les plateformes sans réfléchir (sur la durée).Donc C (ou C++--), soit Java. Je ne connais pas assez bien Rust (j'apprendrai, promis), ce qui me bloque c'est qu'il n'y a pas d'ABI stable.
    
    I use Arch BTW
    
    Répondre
  - [^] # Re: History
    
    Posté par Sytoka Modon (site web personnel) le 02 septembre 2025 à 18:20. Évalué à 4 (+2/-0).
    C'est vrai que la longueur de la mise en place de Raku n'a pas aidé. Mais aujourd'hui, Perl a retrouvé sa dynamique propre et le mot clef class comme les autres langage.
    
    Deux choses que je préfère en Perl par exemple à Python.
    1. le $ devant les variables. Je trouve que cela améliore la lisibilité des variables et en plus avec 'my', on déclare ses variables (surtout avec use strict). C'est bien plus clean.
    2. on peut déclarer des variables locales pour chaque bloc. Ainsi on a des variables locales dans les boucles for / foreach / while. Cela permet de faire du code beaucoup plus robuste sans risque de récupérer la valeur du passage de la boucle précédente.
    Donc au final, je code en Perl si possible plutôt qu'en Python.
    Répondre
- [^] # Re: History
  
  Posté par Paul POULAIN (site web personnel, Mastodon) le 19 août 2025 à 13:48. Évalué à 8 (+6/-0).
  
  C'est le langage dans lequel est écrit le logiciel métier à destination des bibliothèques le plus utilisé dans le monde, donc oui, c'est encore utilisé par plein de gens ;)
  https://koha-community.org si tu es intéressé par la ref.
  
  Répondre
  - [^] # Re: History
    
    Posté par mahikeulbody le 19 août 2025 à 17:36. Évalué à 6 (+4/-0).
    
    et c'est aussi le langage dans lequel est écrit le logiciel relatif aux métadonnées des photos/vidéos/… qui fait référence dans le monde (utilisé notamment par digiKam).
    
    Répondre
    - [^] # Re: History
      
      Posté par mahikeulbody le 19 août 2025 à 19:13. Évalué à 7 (+5/-0).
      
      j'ai complètement oublié de citer le nom du logiciel en question : exiftool.
      
      Répondre
- [^] # Re: History
  
  Posté par Psychofox (Mastodon) le 19 août 2025 à 21:09. Évalué à 6 (+3/-0).
  
  Comme pour tcl, les gens à qui ça importe de pouvoir executer leur logiciel dans plusieurs décennies, ou le maintenir à long terme?
  
  Parce que bon, c'est possible mais c'est un peu plus compliqué d'executer mais aussi de distribuer du code python 2.x d'il y à 20 ans.
  
  Moi j'ai encore vu et modifié du code perl il y a 1 ans à titre professionnel.
  
  Répondre
  - [^] # Re: History
    
    Posté par abriotde (site web personnel, Mastodon) le 20 août 2025 à 11:04. Évalué à 0 (+0/-1).
    
    Il y en a encore dans les distributions. Il y a encore quelques projets qui se lancent en Perl (Les haineux de Python ;) )… mais incontestablement c'est en grosse perte de vitesse.
    
    Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
    
    Répondre
  - [^] # Re: History
    
    Posté par oau le 21 août 2025 à 11:08. Évalué à 3 (+1/-0).
    
    c'est clair j'ai du code en perl en prod depuis (je viens de faire le calcul, je suis pas bien) au moins 15ans …
    
    Répondre
- [^] # Re: History
  
  Posté par abriotde (site web personnel, Mastodon) le 20 août 2025 à 11:01. Évalué à 5 (+4/-0). Dernière modification le 20 août 2025 à 11:06.
  
  Ce qui a pesé très lourd sur Perl, c'est Raku (la malédiction des version 6). La communauté s'est dispersée et cela a favorisé Python.
  https://fr.wikipedia.org/wiki/Raku_(langage)
  
  Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
  
  Répondre
  - [^] # Re: History
    
    Posté par raum_schiff le 20 août 2025 à 11:45. Évalué à 1 (+0/-0).
    
    Il y avait déjà des tensions avant (révision du modèle objet, feature-lock, etc.).
    
    Le fait que P6 soit devenu Raku (décision qui a été prise de façon collégiale) et vu le peu de membres de la communauté Raku; cela n'a pas eut plus d'impact que ça sur Perl.
    
    Répondre
    - [^] # Re: History
      
      Posté par abriotde (site web personnel, Mastodon) le 20 août 2025 à 23:04. Évalué à 2 (+1/-0).
      
      Bien sûr que ce n'est pas le seul élément. Mais pour un jeune développeur, quand il voit ça, il ne comprends pas trop quel est l'avenir. Doit-il apprendre Perl 5 ou Raku? Ca n'envoie pas un bon message.
      PHP 6 a eu les même déboires avec un résultat assez similaire (mais cela n'a pas été jusqu'à la scission, et donc moins lourd de conséquence.) Même Python, a envoyé un très mauvais message avec Python 3 qui rompait avec Python 2. On voit encore des gens critiquer Python pour sa non stabilité à cause de ça.
      
      A contrario, la très grande force de C, c'est de n'avoir jamais eu (a ma connaissance) ce genre de gros koik (enfin gros gap de passage de version). C K&R (ou plus sûrement C89) reste très proche de C 23 du moins il compilerai presque
      
      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
      
      Répondre
      - [^] # Re: History
        
        Posté par Benoît Sibaud (site web personnel) le 21 août 2025 à 08:12. Évalué à 3 (+0/-0).
        
        Il n'y a pas que les changements d'API, aussi ceux d'ABI : C a eu ses problèmes d'ABI notamment avec libc5 et libc6 si je me souviens bien. C++ a eu régulièrement des problèmes d'ABI aussi (gcc2 vs gcc3, les différentes gcc3.x, etc.).
        
        Pouvoir recompiler c'est bien, surtout quand tu es quasi obligé de le faire pour cause d'ABI qui ont changé.
        
        Répondre
      - [^] # Re: History
        
        Posté par Pol' uX (site web personnel) le 21 août 2025 à 08:12. Évalué à 3 (+1/-0).
        
        C K&R (ou plus sûrement C89) reste très proche de C 23 du moins il compilerai presque
        
        Python 3 reste très proche de Python 2, du moins il s'interpréterait presque.
        
        Adhérer à l'April, ça vous tente ?
        
        Répondre
        
        [^] # Re: History
        
        Posté par lasher le 05 septembre 2025 à 12:40. Évalué à 2 (+0/-0).
        
        En l'occurrence, et je me trompe sans doute, mais C89 est un sous-ensemble strict de C99 et C11 (je ne peux pas dire pour C23). Donc normalement, tout code C89 est compilable avec des normes plus récentes. La seule exception que je peux imaginer sont les codes écrits en C pre-ANSI/ISO, qui n'utilisent pas les signatures de fonction de C89 :
        
        fonc(a,b,c) int a; float b; char c { // … }
        
        Répondre
      - [^] # Re: History
        
        Posté par raum_schiff le 21 août 2025 à 10:21. Évalué à 3 (+2/-0).
        
        Pour faire de l'histoire :
        
        Il était clair à partir de la beta de 2015 (mais on s'en doutait déjà avant), qu'il n'y aurait pas de rétro-compatibilité.
        
        A partir de là, et considérant la pile de code monstrueuse produite antérieurement (plus le CPAM évidemment); le passage de version de façon "automatisable" devenait quasiment impossible; même si le P6 de l'époque pouvait encapsuler du code P5.
        
        Le changement de nom a eut lieu en 2019, avec entre temps de gros remous dans la communauté.
        
        Le monde de la programmation préfère les changements rapides et "lisses" de paradigmes plutôt que les changements lents d'adoption. Ici le coût de changement rapide était trop grand, et le changement lent a fait peur (pourquoi ?).
        
        Pour les "jeunes programmeurs" qui se focalisent sur le numéro de version cela peut paraître troublant. Mais soyons honnêtes, en 2015 la majorité des Perlistes-juniors n'étaient pas des devs rentrant dans le langage par curiosité mais plutôt des devs intégrant des équipes de Perlistes barbus travaillant sur des grosses bases de code.
        
        Donc parler d'un doute handicapant pour le langage à la période tenait plus de la panique injustifiée.
        
        En 2025 Perl se porte bien au niveau de son architecture, il est encore utilisé et peut avoir son utilité dans de nouveaux projets. Pour ce qui est de sa communauté et de son taux d'utilisation, je ne vais pas me prononcer car ayant arrêté de coder du Perl de façon pro en 2017.
        
        Répondre
      - [^] # Re: History
        
        Posté par pulkomandy (site web personnel, Mastodon) le 22 août 2025 à 15:58. Évalué à 7 (+4/-0).
        
        On voit encore des gens critiquer Python pour sa non stabilité à cause de ça.
        
        Personnellement j'ai beaucoup plus de problèmes avec la nouvelle approche. Chaque version mineure (3.x) de Python vient avec son lot de petits changements qui cassent certains scripts.
        
        Et des versions, il y en a souvent et elles ne sont pas maintenues longtemps. C'est surtout là que je vois des reproches à Python pour sa non stabilité, et c'est aussi ce qui peut expliquer que certains projets sont restés en Python 2 aussi longtemps que possible (la version 3 ne donnant plus de garantie que le code existant continuerait de fonctionner d'une version à l'autre).
        
        Ce n'est pas un compromis facile entre la rétrocompatibilité et l'évolution continue du langage. C++ ne casse que très rarement la compatibilité, mais par contre il accumule un certain nombre de problèmes qui ne peuvent pas être corrigés. Et surtout, on peut toujours configurer le compilateur pour compiler du code C89 si on a besoin. On ne peut pas faire la même chose en Python: prendre un interpréteur Python 3.13 et lui dire "interprète moi ce code qui est écrit en Python 3.8 et utilise des fonctionnalités qui ont été supprimées entretemps".
        
        Répondre
        
        [^] # Re: History
        
        Posté par fearan le 25 août 2025 à 15:48. Évalué à 5 (+2/-0).
        
        Chaque version mineure (3.x) de Python vient avec son lot de petits changements qui cassent certains scripts.
        
        C'est même une plaie, chaque outil viens avec son pyenv qui va re-télécharger le monde pour tourner et encombrer le disque dur. Y'a aucune mutualisation, tout viens au petit bonheur, et on espère que l'interpréteur du système est le bon; ou sinon on le livre avec…
        
        Et comme tous les gens ne sont pas avec la même version de python, ça devient vite l'enfer dès qu'on veut en utiliser de différentes sources.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        Répondre
        
        [^] # Re: History
        
        Posté par abriotde (site web personnel, Mastodon) le 25 août 2025 à 21:17. Évalué à 2 (+1/-0).
        
        Pour Python, c'est vrai que c'est problématique et encore plus quand on parle de projets un peu gros avec des dépendances… En fait la solution la plus utilisée aujourd'hui est Docker (Ou équivalent). Cela masque le problème et permet de faire tourner de très vieille version sans risquer qu'elle pète à une mise à jour serveur… ce qui signifie aussi qu'il y a moins de pression pour patcher les failles critique…
        
        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
        
        Répondre
- [^] # Re: History
  
  Posté par fearan le 22 août 2025 à 08:20. Évalué à 10 (+7/-0). Dernière modification le 22 août 2025 à 08:21.
  Oui, moi pas exemple, ne serait-ce que pour avoir un truc du genre
```
while(<>) {
  my ($id, $bidule, $machin) =~ /$regID$regBidule$regMachin/;
  [...]
}
```
  qui va permettre de parser ligne a lignes le(s) fichier(s) passés en paramètres ou simplement l'entrée standard.
  
  ou tout simplement la facilité d'usage pour les regExp qui sont une plaie à utiliser dans pas mal d'autres langages.
  
  Il ne me viendrait pas a l'idée de faire tout un projet en perl, mais des scripts d'appoints, c'est très utile;
  
  Il ne faut pas décorner les boeufs avant d'avoir semé le vent
  Répondre
  - [^] # Re: History
    
    Posté par abriotde (site web personnel, Mastodon) le 25 août 2025 à 21:18. Évalué à 2 (+1/-0).
    
    Perso j'utilise AWK…
    
    Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
    
    Répondre
- [^] # Re: History
  
  Posté par Alex G. le 26 août 2025 à 00:09. Évalué à 3 (+1/-0).
  
  Le cœur d'Open Food Facts est en PERL
  
  Répondre
  - [^] # Re: History
    
    Posté par Benoît Sibaud (site web personnel) le 26 août 2025 à 09:26. Évalué à 4 (+1/-0).
    Sur une Ubuntu 24.04 par exemple, juste une petite sélection de quelques logiciels un peu connu :
```
$ apt rdepends perl|grep -vE "lib.*-perl"|grep Dépend
(...)
  Dépend: chromium
  Dépend: ocsinventory-server (>= 5.14)
(...)
  Dépend: mariadb-server (>= 5.6)
(...)
  Dépend: git
(...)
  Dépend: vmware-manager (>= 5.10.0)
(...)
  Dépend: xen-tools
(...)
  Dépend: sympa (>= 5.8)
(...)
  Dépend: nix-bin
(...)
  Dépend: mimefilter
(...)
  Dépend: debmirror
(...)
  Dépend: spamassassin
(...)
```
    Répondre
    - [^] # Re: History
      
      Posté par Benoît Sibaud (site web personnel) le 03 septembre 2025 à 09:36. Évalué à 4 (+1/-0).
      open-vm-tools a aussi une dépendance sur perl par exemple.
      
      https://cultoffoxx.net/2019/2019-12-18-perl-is-still-a-requirement-for-open-vm-tools
      https://bugzilla.redhat.com/show_bug.cgi?id=1358108
      https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-0/vsphere-virtual-machine-administration/managing-virtual-machinesvsphere-vm-admin/customizing-guest-operating-systemsvsphere-vm-admin/guest-operating-system-customization-requirementsvsphere-vm-admin.html « Customization of Linux guest operating systems requires that Perl is installed in the Linux guest operating system. »
      
      (d'ailleurs il manque la dépendance à rpm sur le paquet open-vm-tools pour RockyLinux 9, et perl n'étant pas installé par défaut, les configurations échouent silencieusement)
      
      $ strings /usr/lib/x86_64-linux-gnu/libDeployPkg.so.0|grep perl /usr/bin/perl
      Répondre