Rapidement abordé sur l'édito précédent, une news de fou pour les perleux du monde entier a pointé le bout de son nez le 24 juin 2020 sur le site officiel du langage Perl.

Announcing Perl 7

Et là, on s’est tous dit : mais wtf, Perl6 a déjà été tenté et s’est avéré être un échec (pour les perleux), principalement à cause du changement de philosophie majeure et de la cassure au niveau rétrocompatibilité. Snif, pour un langage qu’on a attendu 10 ans. D’ailleurs, Perl 6 est tellement différent en terme de … Bah en fait, tout, qu’il a été renommé Raku pour bien casser le lien.

Cette parenthèse sur Perl 6 effectuée, penchons-nous sur le vif du sujet.

Pourquoi Perl 7, qu’est-ce que c’est et pourquoi ça va sans doute marcher et être mieux adopté que Perl 6?

Alors pourquoi Perl 7? Deux raisons.

La première : parce qu’on a beau faire ce qu’on veut (oui, le monde est contre les perleux, n’en doutez pas), Perl 5 ne veut pas mourir. Il est trop fort pour ça, on l’aime trop et il est trop bien. Vous remarquerez au premier coup d'œil que ceci est un avis impartial.

La deuxième : parce que Perl 6 a déjà été tenté (en tant que numéro de version, je veux dire), et puis comme le disent les développeurs principaux du langage, PHP est passé de 5 à 7 et personnne n’en est mort. La version 6 porte peut-être malheur, va savoir.

Perl 7 sera, dans sa première version, basiquement Perl 5.32 (dernière version majeure stable de Perl 5) avec quelques paramètres par défaut. Explications.

Quand on commence un morceau de code Perl 5 destiné à un usage un tant soit peu sérieux, on utilise quelques best practices. Ces best practices ont été implémentées en tant que module ou pragma au fil des années.

use utf8;
use strict;
use warnings;
use open qw(:std :utf8);
no feature qw(indirect);
use feature qw(signatures);
no warnings qw(experimental::signatures);

Ça fait pas mal de code boilerplate pour coder de façon un tant soit peu moderne. En gros :

  • les classiques strict et warnings pour nous obliger à faire du code propre
  • utf8 pour l’encodage
  • feature signature pour utiliser les signatures pour écrire des fonctions et méthodes (exemple : sub add($a, $b) au lieu de sub add)
  • faire sauter le warning lié à une feature expérimentale avec no warnings qw(experimental::signatures);

Perl 7 implémentera tout ça par défaut. Et dans sa première version, ce sera tout. Ce qui nous amène tout de suite à la question suivante :

Pourquoi cela va-t-il être mieux adopté que Perl 6

L’essence même de Perl est la rétrocompatibilité. Toute nouvelle version de Perl n’a jamais cassé un fonctionnement majeur de la précédente itération. De ce fait, il y a par exemple eu de nombreuses tentatives d’implémenter du vrai objet dans Perl par module plutôt que dans le cœur (coucou Moose).

Et c’est pour ça que ça va sans doute fonctionner : l’idée derrière Perl 7 est que la première version sera full compatible avec Perl 5, en gros une pierre sur laquelle prendre appui pour démarrer sainement des changements de plus en plus majeurs et au fur et à mesure. En gros, nouveau départ mais en conservant l’essence de Perl. Pour moi, c’est pour ça que ça va fonctionner.

Quand ?

L’idée est que la première itération de Perl 7 sorte durant l’année à venir, avec quelques releases intermédiaires.

Et le CPAN alors ?

Le CPAN, Comprehensive Perl Archive Network, recense les modules Perl de par le vaste monde. Il en héberge plus de 200.000. L’avantage de Perl 7 et de sa rétrocompatibilité sera que les mainteneurs n’auront pas grand chose (voire rien) à changer à leur code pour qu’il continue de fonctionner : le CPAN est donc là pour durer.

Ça promet du bon pour l’avenir des perleux et j’ai hâte de voir ça !