C’est officiel, Sawyer X a annoncé Perl 7. C’est une révolution pour Perl, clairement. Cependant, Perl 7 ne sera pas une révolution en termes de fonctionnalités mais une étape de modernisation pour activer un grand nombre de fonctionnalités par défaut, qui étaient jusque‑là activables à la demande, ainsi que changer de paradigme de développement, puisqu’on va faire avancer le langage plutôt que de systématiquement privilégier la rétrocompatibilité.
Diapo explicative de Sawyer X
Sommaire
- YAPC
- Annonce de Perl 7
- Pourquoi Perl 7 ?
- « Feature guards »
- Après l’annonce
- Et Perl 5 dans tout ça ?
YAPC
Il y a quelques jours s’est tenue la plus grande conférence annuelle autour du langage Perl. Pendant trois jours se sont succédé :
- de nombreux ateliers (aussi appelés BOF soit « Birds Of a Feather »), par exemple sur les cadriciels Web Mojolicious et Dancer, ou sur la promotion de Perl ;
- des keynotes par des personnalités majeures de Perl ou Raku (Sawyer X, Damian Conway et Johnathan Worthington) ;
- des conférences sur de nombreux sujets comme les tests (Perl <3 tests…), la fonctionnalité async de Mojolicious, comment faire tourner Perl en WebAssembly, l’intégration continue avec Perl, le débogueur, l’analyseur, le YAML, etc. ;
- des discussions éclairs (lightning talks), par exemple sur OpenQA ou sur l’interfaçage avec d’autres langages (FFI).
Toutes les vidéos sont disponibles sur la page YouTube officielle de la conférence Perl & Raku, hébergée par la Fondation Perl. :)
Annonce de Perl 7
Lors de la keynote d’introduction, Sawyer X, l’actuel mainteneur en chef de Perl, a surpris tout le monde en annonçant que la prochaine version de Perl 5 serait Perl 7.
Monkey surprise, par @Doug88888 — licence CC BY‐NC‐SA 2.0.
Dans la foulée, brian d foy a annoncé la sortie de son livre qui explique comment se préparer à Perl 7.
Pourquoi Perl 7 ?
Tout simplement parce que Perl 6 est devenu un autre langage et a été renommé Raku.
« Feature guards »
Toutes ces années, l’interpréteur (et le langage) ont bien continué d’évoluer avec des versions majeures, et ce, de façon très régulière… Mais sur les numéros mineurs… (nous en sommes à la version Perl 5.32.0). Voici les dépêches LinuxFr.org traitant des sorties de Perl :
- Sortie de Perl 5.10, en 2007 ;
- Sortie de Perl 5.12, en 2010 ;
- Sortie de Perl 5.14, en 2011 ;
- Sortie de Perl 5.16, en 2012 ;
- Sortie de Perl 5.18, 5.20 et 5.22 (5.18 en 2013, 5.20 en 2014, 5.22 en 2015) ;
- Sortie de Perl 5.30 (5.24 en 2016, 5.26 en 2017, 5.28 en 2018, 5.30 en 2020) ;
- Sortie de Perl 5.32, en 2020.
Perl évolue, mais ne casse jamais rien, car, jusque‑là, Perl a fait preuve d’une rétrocompatibilité presque maladive (et tant mieux !). Techniquement, les changements incompatibles sont « cachés » derrière des « feature guard ». Sawyer X a déclaré que « les feature guards sont très intéressants, ils gardent la syntaxe. L’idée est qu’elle ne changera jamais à moins que vous ne le demandiez, ce qui est une très bonne idée car cela offre une bonne protection contre une syntaxe et une sémantique non désirées.
Pour donner un exemple, le comportement du mot clé fc peut être modifié en activant use feature 'fc' dans notre programme (doc).
Plusieurs features guards peuvent être utilisés au sein d’un même programme selon les portions (portée lexicale) et l’on peut également supprimer des fonctionnalités avec no feature …. On peut également activer un ensemble de features guards tout d’un coup avec un use version.
Par exemple, use v5.32 active le « pack de fonctionnalités Perl 5.32 » et empêchera également, si besoin, l’exécution sur un interpréteur plus ancien :
$ perl -e "use v5.32;"
Perl v5.32.0 required--this is only v5.26.1, stopped at -e line 1.
Perl 5.000 est sorti en 1994 mais, dans la pratique, on peut dire que la rétrocompatibilité s’étend plutôt sans problème jusqu’à 5.10.* (5.10.0 en 2007) ou 5.8.* (5.8.0 en 2002), parfois même un peu plus (5.6.*…). Tous les détails sur les dates de sorties dans l’historique des sorties de Perl.
Si l’on n’essaye pas délibérément d’utiliser des fonctionnalités modernes (activables donc), on peut très facilement écrire du code qui tournera partout, pour longtemps, et même sur Perl 5.8.9 ou 5.10.1.
D’autres « défauts » ne sont pas des fonctionnalités, mais des recommandations comme use strict et use warnings qui permettent de protéger le programmeur de lui‑même et sont mises en avant comme bonnes pratiques par la communauté Perl depuis très longtemps.
Les développeurs de Perl ont donc décidé de se débarrasser de ce « fardeau » et d’activer un bon nombre de ces « défauts » qui sont quasi‑incontestables.
Le comportement des « défauts » va changer, mais les Perl porters ne sont pas fous et il sera toujours possible de retrouver le comportement d’avant avec un mode de compatibilité Perl 5…
Tous les détails techniques de la proposition Perl 7 sont disponibles sur cette page de wiki.
La version 7.0.0 est prévue au plus vite (si possible a la place de la 5.34.0).
En plus de la modernisation du langage, Perl 7 sert également de :
- pont vers Perl 8, qui est peut être la véritable révolution (qui verra sûrement de nombreuses nouveautés, ainsi que de nombreuses dépréciations et du nettoyage de code) ;
- communication pour faire parler du langage en donnant une image positive.
Après l’annonce
L’annonce a été très bien accueillie et laisse place maintenant aux discussions d’implémentation et à quelques inquiétudes ou quelques réfractaires. Le GitHub Perl 5, le canal IRC #p5p ainsi que la liste de diffusion (en particulier le fil de discussion « Announcing Perl 7 ») se sont transformés en forum :
Fils de discussion sur la liste de diffusion.
Parmi les remarques, il ressort que certains souhaitent à tout prix utiliser un marqueur de version majeure comme use v7 (sans pour autant s’en servir de « feature guard » à proprement parler), et cette demande a d’ailleurs par la suite été acceptée. Il y aura donc une sorte de « protocole » permettant de définir pour quelle génération de l’interpréteur est écrit le code. Le but étant de faciliter le plus possible une migration douce du CPAN.
L’idée étant « on peut casser, mais pas trop à la fois » et qu’il n’est pas souhaité de « forker » le CPAN. Toutes ces précautions se comprennent tout à fait, car la rétrocompatibilité était un des plus gros points forts de Perl… Mais ce n’est pas le seul !
Il y a également de nombreuses demandes de fonctionnalités (try‑catch, les types, le comportement des « sigils », de nouveaux opérateurs…). Mais, là, c’est plutôt hors sujet. Bref la communauté est en pleine ébullition !
Et Perl 5 dans tout ça ?
Il est prévu une période de support étendu de minimum cinq à dix ans pour Perl 5.32. Perl dispose d’une infrastructure d’outils (installateurs très intelligents qui pourraient modifier du code à la volée) et d’une culture du test qui va devoir tourner à plein régime pour migrer, tester et corriger les modules CPAN (presque 200 000 modules) !
En attendant, à très bientôt Perl 7, je l’espère !
Aller plus loin
- Vidéos de la conférence Perl (32 clics)
- Liste de diffusion p5p (14 clics)
- Perl (27 clics)
- Code source de Perl (14 clics)
# Une bonne initiative
Posté par raum_schiff . Évalué à 7.
IMHO : Avoir utilisé le principe "feature guard" pour faire évoluer le langage tout en conservant une rétro-compatibilité ne pouvait pas durer éternellement.
Ce principe appelait d’emblée à une mise à jour de Perl, car la rendait possible techniquement.
Il ne manquait plus que la volonté "politique" (merci sawyerX) de faire le premier pas.
Bien sûr, le plus dur dans cette migration sera le CPAN (dont l’automatisation a été proposée ici).
Mais les mainteneurs de modules étant responsables de leur code, c’est bien à eux de déterminer ou non la migration à terme de leur modules dans la branche 7 : si en plus, l’équipe du core de Perl leur propose les outils nécessaires pour le faire, les dents vont moins grincer.
Pour tout le code ≤ 5.8 sans flag strict et warnings qui tourne déjà sur des distrib pas upgradées depuis 10 ans il finira peu à peu dans des containers ou sera remplacé.
A bien y réfléchir, la fenêtre de temps d’environ 9 mois entre le renommage de Perl6 en Raku a libéré les esprits, pour le mieux.
Tous mes vœux de réussite aux prochaines versions de Perl (et Raku évidemment) !
# Oui, quel fardeau ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 8.
Il semblerait qu'un commentaire datant de l'ébauche de la nouvelle se soit retrouvé publié :)
Sinon, c'est interessant. Je ne savais pas que « Perl 6 n'était plus Perl » donc j'irai y jeter un œil aussi.
J'aurais pas été contre un petite liste des fonctionnalités activées de base aussi.
use strictet tout.[^] # Re: Oui, quel fardeau ?
Posté par ZeroHeure . Évalué à 4.
Corrigé, merci. Le coupable déménagera les serveurs de linuxfr sur son dos.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Oui, quel fardeau ?
Posté par deuzene (site web personnel) . Évalué à 4.
Tu peux jeter un œil sur le wiki de perl pour ça.
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
# Un coup d'état futile
Posté par cognominal . Évalué à 5.
Ca restera Perl 5 avec des défauts acceptables. Défauts dans les deux sens du mots. Je ne met pas en doute les compétences programmatiques de Sawyer. Mais appeler ça 7.0 est une escroquerie car l'architecture sous jacente reste la même. C'est un coup d'éclat égotique, futile et sans lendemain. La promesse d'une version majeure est d'attirer de nouveaux utilisateurs mais ça n'a aucun sens d'apprendre Perl en 2020.
Les détails importants sont flous et seront l'objet de guerres de tranchée. Véritable support objet, difficile donc exclu par Sawyer. Même utf-8 par défault n'est pas acquis et ne sera jamais comparable au support par raku.
Larry Wall, le créateur de Perl, voulait que le futur de Perl soit raku (anciennement Perl 6). Raku devait profiter de la notoriété de Perl. Le coup d'état à consisté à enfumer les gens de Perl 6.0 en leur demander de se renommer en raku. Le coût a été énorme, programmatique et de notoriété. Larry Wall voyait 7.0 comme une version hypothétique et parfaite donc personne n'a vu le coup venir. Mais 6.0 étant dégagé,
sawyer pouvait utiliser 7.0. Ne jamais faire de concessions à des manipulateurs, c'est le prélude à d'autres concessions.
Les modes de compatibilités prévus initialement prévus pour raku ne sont pas possible. On peut faire interopérer le moteurs de Perl 5 et de raku mais on ne pourra pas interpréter du Perl 5 ou 7 avec le moteur raku.
Raku est un excellent langage. Son moteur, MoarVM est excellent. Mais sans support
académique et corporate, il dépend du bon vouloir d'une core teapm excellente mais peu nombreuse.
On ne voit plus Larry Wall qui semble maintenant plus s'intéresser à ces petits enfants qu'à Perl. 7.0 ne vas pas le ramener.
Je fais du Perl depuis plus de 30 ans, ne suis plus guère Perl 5 et connaît les internes de raku. Les mongueurs de Perl qui auraient dû publier ce post mais sont en état de coma avancé.
[^] # Re: Un coup d'état futile
Posté par cognominal . Évalué à 6. Dernière modification le 16 juillet 2020 à 19:41.
J'ai dit : Même utf-8 par défault n'est pas acquis et ne sera jamais comparable au support par raku.
Je précise.
raku utilise en interne des code synthétiques de longueur constante de 32 bits donc tous les caractère même composites sont de même longueur ce qui facilite l'implémentation
des routines concernant les chaines. Bien sûr l'utf-8 est supporté mais pas utilisé en interne.
[^] # Putsch ou guerre civile ?
Posté par raum_schiff . Évalué à 10.
Le changement de nom de P6 vers Raku semble autant voulu des deux côtés (pour des raisons différentes) afin d'éviter l’explosion en vol.
La situation initiale était très toxique pour la communauté et la majorité des bonnes volontés de rapprochement des deux langages est venue des devs de Raku : Avec des portages ad-hoc de modules de Perl5 par Elizabeth Mattijsen et le module Inline::Perl5 (a noter qu’il y a aussi Inline::Python, mais c’est une autre histoire …).
Le retour de la Perl Fondation a été inexistant même si elle a financé et continue de le faire les travaux d’optimisation de la VM de Raku; la communauté quant à elle s’est montrée inintéressée voire hostile dans sa majorité.
Le changement de nom, IMHO à fait du bien aux deux parties, laissant certes Raku dans une position de faiblesse au niveau de ses ressources et de sa visibilité, mais a libéré des énergies qui auraient été gâchées par des querelles de chapelles. En optant pour un nouveau nom, Raku est sortit par la grande porte au niveau moral en laissant plus d’écho aux voix du changement dans la communauté Perl (Curtis Poe, Sawyer, et même Damian Conway).
Si le passage à P7 paraît mineur (il l’est, je ne le nie pas), il ouvre le chemin vers des modifications plus profondes ; modifications que j’espère, mais si le camp des conservateurs l’emporte (Sawyer même si il semble jouer sur du velours, mise gros sur ce coup là) et cela ne résulte que d’un coup d’épée dans l’eau, seule la communauté de Perl aura à s’en mordre les doigts et Camelia (ça aurait pu être un nom sympa, soupirs …) n’aura pas à en souffrir.
Pour en revenir à Raku, je pense aussi que c’est un excellent langage, compréhensible autant que compréhensif pour l’utilisateur qui offre la possibilité de produire du code clair (voir même naïf) pour des situations simples, et permet la complexification sans charge cognitive trop lourde.
Note : si Larry semble maintenant plus s'intéresser à ces petits enfants, c’est tout à son honneur.
Il a toujours insisté sur le côté humain du dev dans ses conférences, son attitude est donc linguistiquement autant pertinente que performative.
# enfin!!
Posté par nomorsad . Évalué à 1.
Je fut grand amateur de Perl mais je suis toujours consterné de voir des programmes d'autres écrits en comme du shell vaguement amélioré.
Perl a mon avis de grands avantages mais était plombé par sa sainte rétrocompatibilité qui l'empêchait d'évoluer. Mais rien qu'un
use strict;activé par défaut aurait tellement amélioré la qualité de tous les codes et au passage améliorer sa réputation….Python a choisi le chemin inverse et malgré quelques difficultés, ça se passe bien!
Je vais suivre avec attention ce Perl7 !
# 21 jours, 12 commentaires.
Posté par Rafael (site web personnel) . Évalué à 4.
Une nouvelle (supposée) version majeure de Perl, un renoncement en ellipse (Raku), et 12 commentaires en 21 jours. Que les temps ont changé…
[^] # Re: 21 jours, 12 commentaires.
Posté par bistouille . Évalué à 5. Dernière modification le 18 août 2020 à 11:30.
Bonjour,
Je pensais aussi un peu ça, mais récemment un jeune ex-collègue parti récemment dans une autre boîte a dû apprendre Perl (le bon vieux Perl 5 devenu "7") car dans cette société les outils de test de leurs produits sont développés en Perl depuis presque 20 ans.
Et d'autres outils bien présents comme RT sont toujours développés et mis à jour chez Best Practical. C'est sûr qu'on est loin de l'engouement des années 1990-200x pour ce langage.
Je suis certain que Raku a plein de qualités, pourquoi ça n'a pas pris? J'avance quelques hypothèses: une certaine confusion, liée aux effets d'annonce et à la grande attente générée autour de Perl6 dans l'esprit des amateurs de Perl dont je fais partie. A l'époque j'ai eu du mal à saisir ce qu'il y avait de concret et fonctionnel, entre les implémentations en Haskell, en C, ou celle utilisant du bytecode compatible avec une JVM, est-ce que les "gros" modules CPAN (les plus utilisés) seraient portés?
Pour ma part à l'époque j'utilisais beaucoup Perl d'abord comme un super shell pour du système, les modules Perl/Tk et PDL pour prototyper des petits outils d'analyse d'image simples, tester une idée rapidement, faire des interfaces sans y passer trop de temps pour des applis "one-shot" pour une manip, et puis un peu plus tard j'ai du utiliser Catalyst aussi, non sans mal car j'étais peu familier des concepts et des frameworks web… et donc, à tort ou à raison, je m'étais gardé à distance de tous ces trucs un peu nébuleux autour de Perl6, tout en espérant égoïstement que le langage allait bientôt être prêt à l'emploi (mon emploi :-) )
Par contre je regrette beaucoup cette époque, l'atmosphère qu'il y avait dans cette "communauté" des Mongers (j'aime pas trop ce mot-valise mais bon…) était particulière, les gurus parlaient aux novices, on ne se faisait pas humilier quand on posait une question un peu naïve (du moins ça ne m'est jamais arrivé).
[^] # Re: 21 jours, 12 commentaires.
Posté par raum_schiff . Évalué à 5.
Coucou,
Si Raku n'a pas "pris" en temps que "nouvelle" version de Perl c'est à cause (IMHO) de l'éloignement progressif de la syntaxe des deux langages qui a amené à l'éloignement des communautés.
Bouger un monolithe comme Perl qui mise sur la stabilité et la rétrocompatibilité vers des nouveaux paradigmes (Typage progressif des variables, Modèle objet intégral, Refonte des regex, Parser modifiable, etc ..) n'allait pas être une mince affaire. Rien que pour implémenter toutes les RFC de Raku avec une équipe réduite, cela pris plus de 10 ans (Un petit retour sur les RFC est dispo ici); si une fois effectif Raku a tendu la main à la communauté Perl, l'accueil a été plus que froid.
Cela peut se comprendre, si Raku est capable d'interpréter du Perl, l'inverse tient de de l'impossible. Un convertisseur 5 vers 6 aurait pu se faire, mais aurait demandé de très grands efforts des deux côtés. Vu que le torchon brulait déjà au sein d'une communauté qui au fur et à mesure des années est devenue de plus en plus conservatrice (le temps des mongeurs bienveillants envers les nouveaux est depuis longtemps passé, mais il reste heureusement beaucoup de types sympas), le cas était plié d'avance.
Si Raku ne prend pas en temps que langage propre, seul le temps le dira. L'objectif d'une version majeure de Perl n'étant plus d'actualité, il en va autant de l'efficacité rapide à des fins commerciales qui a poussé Perl dans les années 90/2000. Reste donc le "fun" ou la volonté d'enrichir le langage pour lui même, un langage qui a beaucoup à offrir.
Je pense quoiqu'il en soit que la mise en place prochaine d'un conseil décisionnaire apportera du grain à moudre quand à l'avenir de Raku.
[^] # Re: 21 jours, 12 commentaires.
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2. Dernière modification le 19 août 2020 à 10:33.
Je ne sais pas si cela peut se comprendre mais je ne vois pas le problème dans cette affirmation, si effectivement raku est capable d'interpréter du perl 5 alors tout est bien non, on respecte la backword-compat. Je ne connais pas des masses de choses qui sont forward-compatible sur une version majeure N+1.
Même perl 5.10 va avoir du mal a interpréter du code utilisant les fonctionnalités réçentes.
[^] # Re: 21 jours, 12 commentaires.
Posté par raum_schiff . Évalué à 1.
Effectivement le "parsage" de P5 -> P6 n'aurait eut aucun intérêt.
Ces fonctionnalités sont contingentées, P5 reste P5; du 5.10 en core ne pourra pas interpréter (par ex)
use feature bitwise;
En revanche, le "use feature" est ici très utile pour isoler du code obsolète ou upgrader ce même code de façon progressive (les "feature guards" pouvant être scopées dans un bloc { … }
Toucher au CORE est une autre chose, je suis d'accord qu'une version majeure casse des choses, mais jusqu'à quel point ?
Vu le nombre gragantuesque de modules du CPAN, la ré-écriture des modules et de leur dépendances même en passant par inline-perl5 (qui encapsule le code dans un objet) aurai été cyclopéenne (et invoqué Cthulhu ?).
Je ne sais pas si un outil de conversion de code a été envisagé, mais même si cela avait été possible, la communauté l'aurait-elle accepté ?
Quand on voit la levée de boucliers sur P7 et ses changements mineurs, la réponse est (IMHO) non.
D'où le "fork" (terme a prendre ici avec des pincettes) de Raku.
[^] # Re: 21 jours, 12 commentaires.
Posté par flan (site web personnel) . Évalué à 6.
Mais est-ce vraiment inattendu ?
Si on compare à Python, ce dernier s'est beaucoup modernisé sur plein d'aspects (même s'il garde des problèmes, notamment sur le packaging) et s'est développé dans beaucoup de domaines (scripting comme Python, mais aussi web, admin sys, data-mining/IA/…).
Ils ont décidé de casser la compatibilité pour le pire (genre les strings), mais de façon progressive (plus de 10 ans !).
Maintenant, Python 3.8 se retrouve avec pas mal de choses sympa comme du typage, des nouveaux outils de gestion de dépendances, etc. On peut faire du code intégralement typé (mon IDE est capable de dire le type précis de chaque variable, que ce soit par de l'inférence ou par des indications) — que ce ce type soit ignoré à l'exécution n'est pas grave, ce qui compte est d'avoir l'information à l'écriture.
# ça débat dans la communauté Perl
Posté par tisaac (Mastodon) . Évalué à 1.
Visiblement tout le monde de Perl n'est pas forcément enthousiaste sur les évolutions et sur la manières dont ces évolutions ont été décidées.
Surtout, ne pas tout prendre au sérieux !
# try-catch et pas d'utf8 interne
Posté par Maxzor . Évalué à 0. Dernière modification le 20 août 2020 à 14:53.
Je n'ai jamais fait de perl, je fais du shell, du sed, un peu d'awk, du python.
lol, svp pas la programmation avec exceptions!
Le non utf8 en interne est un gros problème je trouve.
Ce qui manque aujourd'hui dans ma compréhension actuelle est une bibliothèque de traitement utf8 décente niveau performance et fonctionnalité.
Ni perl, ni icu - ce dernier est issue du monde sun et java, utf16 en interne - ne paraissent remplir ce rôle…
[^] # Re: try-catch et pas d'utf8 interne
Posté par anaseto . Évalué à 3.
Qu'est-ce qui te manque exactement dans le support utf-8 de Perl 5 ?
En particulier, je ne sais pas trop ce que tu veux dire par « non utf8 en interne » : il faut explicitement dire à perl qu'on veut traiter de l'utf8, mais une fois fait, perl adapte ses représentations internes de sorte à manipuler efficacement l'utf8.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.