Discussion :

[Olivier Famien]

Le comité de pilotage de Perl pourra-t-il sauver Perl du naufrage ?
Des propositions sont en cours d’élaboration pour faire passer Perl de la « vieille école » à une nouvelle base de référence

Il n’est étonnant pour personne que le langage de programmation Perl est en perte de vitesse. Depuis quelques années, plusieurs sources s’accordent pour dire que ce langage risque de ne plus être compté parmi les langages de programmation utilisés par un grand nombre de développeurs. Et pour cause, le langage de programmation Perl ne remplit plus certaines conditions chères à de nombreux développeurs. En 2019, Developpez.com, la plateforme francophone qui reçoit par mois plusieurs millions de visiteurs, a réalisé un sondage à l’issue duquel les intervenants ont désigné Objective-C et Perl comme les deux langages de programmation les plus susceptibles de disparaître dans les prochaines années. Pour sauver le langage, le comité de pilotage de Perl rassemble actuellement des propositions pour redonner au langage l'attrait qu'il avait auprès des utilisateurs. Mais pourra-t-il faire de Perl ce qu'il était il y a trente ans ?

Parmi les conditions nécessaires à la survie des langages de programmation, nous avons la communauté et la popularité. Pour juger de la popularité de Perl, l’on peut se tourner vers l’indice de popularité Tiobe qui retrace la courbe d’évolution du langage. En 1995, environ quelques années après la sortie de sa première version stable, le langage a été classé 3^e parmi les langages de programmation d’alors. En 2000, il est passé à la 4^e place. En 2005, il a perdu un rang et est passé à la 5^e place. En 2010, c’est la 7^e position qu’il occupait. Et en 2015, il est passé à la 8^e place. Jusqu’en 2015 donc, ce langage était utilisé par un nombre important de développeurs et d’entreprises.

Mais à partir de là, les développeurs ont commencé à prendre leur distance et en 2020, il est passé à la 14^e place. Pour ce mois de mars, il occupe la 17^e place dans le récent classement de Tiobe. Avec Redmonk, qui donne la tendance des langages sur les plateformes Github et Stack Overflow, Perl occupe la 19^e place dans son classement du mois de janvier. Et avec PYPL, qui mesure l’indice de popularité des langages de programmation en utilisant Google Trends, Perl a perdu deux places par rapport à l’an dernier et occupe pour ce mois de mars la 23^e place. Si les développeurs semblent délaisser Perl au fil des années, cela serait dû en partie aux efforts consentis pour maintenir le langage et lui apporter des fonctionnalités fraîches (frameworks, bibliothèques, performances, etc.) que l’on retrouve dans les langages de la dernière décennie. Pour certaines personnes (beaucoup plus jeunes en l’occurrence), Perl est considéré comme un langage de « grand-père », à peu près de la même façon que les gens voient COBOL aujourd’hui.

Google Trends : évolution de Perl de 2004 à nos jours

Ces personnes estiment que l’évocation du mot Perl renvoie une mauvaise image qui pourrait contribuer à éloigner les jeunes développeurs. En effet, pour de nombreux développeurs, Perl qui était autrefois un langage de programmation Web de premier plan, pragmatique et utile a acquis au fil des années la mauvaise réputation d’être un langage en écriture seule (write-only). D’après eux, les développeurs pensaient que le langage était efficace et portable, mais il s’est accompagné de complications. Plusieurs l’ont qualifié de langage « fragmenté », car il semble que les créateurs ont accumulé les fonctionnalités les unes après les autres sans penser à la manière dont elles seraient synchronisées.

Des efforts de modernisation du langage ont été faits avec la version 6 de Perl, mais avec cette dernière version du langage, l’on ne parle plus de Perl, mais de Raku, qui est devenu un langage sœur de Perl, tant les changements dans cette version 6 de Perl sont importants et radicaux par rapport à Perl 5. Si donc l’on s’en tient au langage Perl, l’on est actuellement bloqué sur la version 5 dont la première version est sortie depuis 1994. À ces problèmes d’évolution, d’autres utilisateurs ajoutent par exemple que pour un langage qui est censé être multiplaforme, l’exécutable de Perl ne fonctionne pas sous les dernières versions de Windows ou Ubuntu pour quelque raison que ce soit. En outre, le compilateur ne fonctionne plus non plus. Pour toutes ces raisons, la communauté du langage ne grandit plus et son utilisation diminue de plus en plus. Apple pour sa part a annoncé officiellement en 2019 que le runtime de Perl (et aussi ceux d’autres langages de scripts comme Python et ruby) ne sera plus installé par défaut dans les nouvelles versions de macOS. Cela rappelle fortement à la décision d’Apple de plus supporter Flash sur iOS, après quoi l’usage de Flash a baissé au fil des ans pour être entièrement abandonné par Adobe depuis l’an dernier.

Plan de relance pour sortir Perl de son déclin

Reconnaissant la baisse continue des utilisateurs de Perl année après année, le comité de pilotage de Perl planche actuellement sur son plan de relance qui passe par les points suivants :

• Améliorer la base de code de Perl en ajoutant des fonctionnalités modernes au langage ;
• travailler à changer la perception du langage en la faisant passer en un langage qui évolue continuellement, mais soigneusement avec de nouvelles fonctionnalités et abandonne les fonctionnalités obsolètes ;
• rendre Perl accueillant pour nouveaux utilisateurs, fiable pour les utilisateurs existants et convaincant pour tout le monde.

Stratégie

Pour atteindre les objectifs ci-dessus, l’équipe de Perl compte s’appuyer sur la stratégie suivante qui est toujours en cours d’élaboration :

• concevoir une feuille de route des fonctionnalités à intégrer dans le langage ;
• avant d’introduire des changements de rupture, il faut au préalable avoir une ou plusieurs versions majeures qui avertissent, si possible, et documentent le changement imminent ;
• produire un modèle clair de la manière dont les nouvelles fonctionnalités passent par les protections expérimentales et de fonctionnalités, puis évoluent avec diligence ;
• développer des règles sur la façon dont les comportements sont jugés dignes d’être marqués pour la suppression, ainsi qu’un processus sur la façon dont cela se produira ;
• soutenir les développeurs et fournir un chemin facile à suivre pour les aider à faire la transition de la « vieille école Perl » à la nouvelle base de référence.

Une « nouvelle base de référence » pour attirer de nouveaux développeurs

Pour attirer de nouveaux développeurs, l’équipe de maintenance de Perl compte appliquer une cure de jouvence qui passe par l’implémentation des points suivants :

• activer strict et warnings par défaut (mais pas pour —e ou —E), dans une prochaine version ;
• les signatures (actuellement une fonctionnalité expérimentale) seront activées par défaut. Cela signifie que la fonctionnalité doit d’abord cesser d’être expérimentale et qu’il va falloir décider comment résoudre les conflits avec du code utilisant des prototypes ;
• Certains des changements post-5.8 auront la protection de fonctionnalité supprimée, ou une valeur élevée et/ou un risque faible ;
• certaines fonctionnalités erronées du langage seront désactivées par défaut, mais peuvent être réactivées, du moins pour le moment ;
• nous voulons que certaines nouvelles fonctionnalités (pas encore en Perl) soient également activées par défaut : try/catch, trim ;
• nous sommes déterminés à améliorer la syntaxe orientée objet dans une prochaine version, et nous aimerions que ce soit la version 8, mais nous ne voulons pas retarder cette proposition, car l’orienté objet a besoin de temps pour mûrir.

Comment parvenir à cette nouvelle base de référence ?

• Selon les mainteneurs de Perl, des modifications ont été déjà apportées, mais pas à cette échelle. La version 5 de Perl sera utilisée comme appui pour passer aux changements. Par ailleurs, une période de transition sera donnée pour que les utilisateurs puissent toujours exécuter leur code source Perl 5, tout en identifiant plus facilement, si cela s’avère nécessaire, les changements qu’ils devront apporter pour que leur code s’exécute à l’avenir ;
• la version 7.0 suivra la 5.34, comme première étape sur la voie des changements de rupture :

• la version 7 introduira des avertissements pour les comportements par défaut qui changeront tels que les violations de restriction ou les conflits de noms ;
• la fonctionnalité « use v7 » activera toutes les choses énumérées ci-dessus. Perl 7 prêt à l’emploi exécutera tout ce que 5.34 exécutera, mais avec des avertissements supplémentaires ;
• le numéro de version est repoussé à 7 pour signaler le changement de direction et la portée du changement autorisé ;
• une fois Perl 7 publié, il n’y aura plus de version 5.x.0 (bien qu’il puisse y avoir d’autres versions 5.34.y) ;

• les grands changements de la version 8 sont des changements réels dans le langage :

• la version8 changera réellement les valeurs par défaut. Par exemple, les restrictions et les avertissements seront activés ;
• la version 8.0 suivra tout ce qui arrive en dernier avec la v7.X ; une fois la version 8 sortie, il n’y aura plus de sortie de versions de Perl 7 ;
• les versions ultérieures à la v8.x introduiront d’autres changements, derrière des protections expérimentales et des fonctionnalités ;

• la manière dont les « fonctionnalités » et les « expériences » fonctionnement n’a pas changé, mais l’équipe de Perl souhaite utiliser ces mécanismes pour mener un changement plus continu dans le langage, de manière à ce que les nouvelles fonctionnalités soient réellement utilisées.

Propositions pour les changements dans les différentes versions de Perl (5, 7 et 8)

Nous précisons qu’étant donné que Perl 6 a été nommé raku, il n’y aura donc pas de Perl 6, mais l’on passera de la version 5 à la version 7, puis à la version 8. Pour ce qui concerne le cycle de vie des versions stables, des versions de maintenance et des versions de développeur, il ne changera pas.

• Perl 8 constituera un changement radical par rapport au comportement par défaut de Perl 5 :

• les fonctionnalités strict et les avertissements sont activés par défaut (mais pas sur —e et —E). Il sera toujours possible de les désactiver ;
• les fonctionnalités protégées supprimées : say, state, __SUB__, fc, refaliasing, declared_refs, et try/catch ;
• no indirect, no multidimensional et no bareword :: filehandles sont activés par défaut. Certains pourraient penser que c’est un pas trop loin, mais l’équipe de Perl pense qu’il serait intéressant de l’essayer ;

• Perl 7 est le tremplin entre Perl 5 et Perl 8 :

• les choses qui seront abandonnées dans Perl 8 seront mentionnées dans Perl 7, par défaut, si possible;
• « use v7 » est la seule ligne que vous pouvez utiliser pour obtenir le comportement de Perl 8 (modulo ce qui vient dans les versions 7.x)
• 2 ou 3 versions de Perl 7 sont attendues, mais probablement 2 ;
• en passant de la version 5 à la version 7, l’équipe de Perl envisage de sauter la version 7.0 et passer directement à la version 7.1 qui serait dans un premier temps une version d’évaluation servant à supprimer les bogues liés au changement de version. La version 7 pourrait donc commencer par le numéro 7.1, puis passer à la 7.2 ;

• la version 5.34 sera la dernière version stable de Perl 5 :

• le nombre habituel de versions de maintenance sera conservé, mais il peut y en avoir plus ;
• cette version majeure sera toujours maintenue lors de la sortie de Perl 8 ;

• la période de publication de la version 7 sera utilisée pour aider les gens à accompagner l’équipe de Perl ;
• étant donné que plusieurs versions 8.x sont prévues :

• de nouvelles fonctionnalités seront introduites, avec des fonctionnalités/protections expérimentales au besoin ;
• des modifications mineures seront apportées à la famille de versions 8.x ;
• des modifications majeures entraîneraient une version v9, avec des avertissements dans deux versions 8.x antérieures ;

Et après ?

Après la mise en œuvre de tout ce plan, l’équipe de Perl compte se tourner vers les points ci-dessous :

• examen et commentaires initiaux du noyau, itération et affinement ;
• partage avec p5p ; itération et affinement ;
• plus large publication ;

À la suite de ce plan de propositions, plusieurs personnes pourraient avancer que ce plan n’est en rien différent de celui qui a été proposé l’an dernier, vivement débattu et jamais implémenté. Mais pour cette fois, l’équipe de Perl avance que ce plan de propositions est plus fermement exprimé en termes de services déjà disponibles.

Source : Propositions pour sauver Perl

Et vous ?

Utilisez-vous actuellement Perl ? Pourquoi ?

Selon vous, les propositions du comité de pilotage pourront-elles sauver Perl de son déclin ?

Au-delà de ces propositions, qu’est-ce que l’équipe de Perl pourrait faire pour redonner à Perl l'attrait qu’il avait auprès de la communauté de développeurs ?

Voir aussi

Perl est-il un langage de programmation mourant ? Le langage pourrait s’éteindre d’ici 2023, selon une étude
Perl 6 sera-t-il renommé avec un nom radicalement différent pour se démarquer de Perl 5 ? La communauté Perl divisée sur la décision à prendre après la sortie de Perl 6 qui rompt avec Perl 5
Sondage : quels sont les langages de programmation que vous détestez le plus en 2019 ? Pourquoi ? Partagez vos avis
Sondage : quels sont les langages de programmation qui vont probablement disparaître dans les prochaines années ?

[Blount]

Ces personnes estiment que l’évocation du mot Perl renvoie une mauvaise image qui pourrait contribuer à éloigner les jeunes développeurs.

En même, quand tu lâches une Perl, ca a rarement pour conséquence d'attirer les gens autour de toi.

[smarties]

Selon vous, les propositions du comité de pilotage pourront-elles sauver Perl de son déclin ?
Non. Il y a Python qui est équivalent je trouve et la syntaxe est plus claire, il y a une flopée de librairies et de fonctions.
En plus, en France, je n'ai jamais vu une offre d'emploi mentionnant PERL dans la région géographique ou je suis

Au-delà de ces propositions, qu’est-ce que l’équipe de Perl pourrait faire pour redonner à Perl l'attrait qu’il avait auprès de la communauté de développeurs ?
C'est une énergie dépensée pour rien à mon avis.


Perl est vieux et je trouve la lecture "difficile".

[esperanto]

Utilisez-vous actuellement Perl ? Pourquoi ?

J'ai découvert Perl avec ma première embauche, même pas évoqué à la fac. Et pas forcément mentionné dans les annonces. Faut dire que Perl, c'est un langage qu'on apprend un peu sur le tas, il ne répond pas vraiment aux modèles théoriques que les facs veulent enseigner.
Perl reste populaire dans le milieu des linguistes, cette syntaxe que vous trouvez bizarre ils l'aiment beaucoup pour sa ressemblance avec les langues naturelles. Faut dire que Larry Wall est linguiste, à la base.
Et puis le CPAN fournit une bibliothèque de fonctions pré-existantes particulièrement fournie. Bien sûr s'il cesse d'évoluer il finira fatalement par être rattrapé, mais il reste de la marge.

[*]nous sommes déterminés à améliorer la syntaxe orientée objet dans une prochaine version, et nous aimerions que ce soit la version 8, mais nous ne voulons pas retarder cette proposition, car l’orienté objet a besoin de temps pour mûrir.

C'est quoi le problème avec le modèle objet? Certes le modèle de Perl 5 est radicalement différent de celui de tous les autres langages, mais il est très puissant quand on le maîtrise bien. Et quand ce n'est pas le cas, il existe déjà des librairies permettant d'écrire des classes comme dans d'autres langages (genre Perl 6)

[*]les fonctionnalités protégées supprimées : say, state, __SUB__, fc, refaliasing, declared_refs, et try/catch ;

Bien, donc on va enfin arrêter d'introduire dans Perl 5 des bribes de syntaxe Perl 6 sans dans le même temps s'assurer qu'elles ne font pas doublon avec celles de Perl 5. Finalement la séparation des deux communautés était bien la meilleure chose à faire, il était temps.

Au-delà de ces propositions, qu’est-ce que l’équipe de Perl pourrait faire pour redonner à Perl l'attrait qu’il avait auprès de la communauté de développeurs ?

Ce qu'il manque à Perl, c'est une spécification. Impossible de réécrire une implémentation pour une nouvelle plateforme, comme Ruby ou Python ont pu le faire pour les plateformes Java (JRuby, Jython), C# (IronRuby, IronPython) et même Javascript. Il y a bien eu la tentative Perlito, mais pour l'avoir essayée, il est rare que je réussisse à prendre un script Perl et à le faire tourner en Java via Perlito, alors que ça me serait bien utile.
Autre effet pervers: comme on ne documente pas les nouvelles fonctionnalités dans une spec, on peut en rajouter beaucoup plus bien plus vite... ce qui ne fait qu'amplifier le problème.
L'idée de base de Perl 6 était pourtant de faire une spécification, mais ils sont tombés dans l'excès inverse, le langage est bien trop différent de Perl 5. Fatalement ça a fini par créer deux communautés séparées.
Pourtant ce n'est pas totalement inéluctable: PhP est parvenu à avoir une spécification assez tardivement, sans introduire excessivement d'incompatibilités, donc ça doit être possible. Et aujourd'hui on trouve des implémentations alternatives de PhP en Java.

[abriotde]

Perl s est tiré une balle dans le pied quand il s est enfoncé dans Perl 6. Ils n auraient jamais dû attendre aussi longtemps. C est idiot, mais quand un langage ne fait pas le buz il perd des jeunes utilisateurs, en plus le debat a perdu les développeurs. Et il y a un autre effet néfaste, c est que quand la nouvelle version sort il y a un trop grand gap à franchir pour les développeurs. On peut citer Python 3 en exemple. Mais Python 3 a fini par s en sortir car il n avait pas trop attendu. Mais attendre, c est aussi des fonctionnalités de modernité que les développeurs se lassent d attendre.
Et pour finir en créant Raku ils ont mathématiquement divisé la communauté par 2...

[pomoxp]

J'ai utilisé Perl très souvent à mes début et beaucoup beaucoup moins maintenant et puis comme cela a été évoqué par une précédente personne : ils ont eu envie de faire "raku" et ça a, selon mon point de vue, participé à générer l’incompréhension autour de Perl et sa perte de vitesse.
Raku personne n'en parle
Perl on en parle encore mais clairement il est en perte de vitesse

Autre aspect qui a contribué, selon mon expérience, au déclin de Perl :
a) le grand nombre de version des modules, la gestion des dépendances compliquée
Quand on a un parc de serveurs non connecté à internet, en version hétérogène (Linux, Aix, Solaris, Windows) et que vous voulez essayer d'avoir une base de distrib commune ... grosse galère en perspective...

b) les antagonismes Linux/Windows avec les aficionados anti-ceci, anti-cela,... ils ne doivent pas travailler en entreprise et ne se rendent pas compte qu'ils scient la branche sur laquelle ils codent
Du coup l'ingé système lambda lorsqu'il doit choisir entre tel ou tel module, telle ou telle langage de script, il finit par se lasser de ses querelles, guerres de clocher, il va voir ailleurs

[pchevee2]

Bonjour,

juste pour répondre à une question : utilisez-vous toujours le langage Perl, et pourquoi? Alors ma réponse est oui, pour une raison probablement historique: j'ai découvert ce langage quand j'ai voulu créer mon site web que je souhaitais interactif, à une époque où ce n'était pas encore la mode (un peu avant l'an 2000). Le php est arrivé par la suite, mais je l'ai simplement ignoré

Par la suite, j'ai utilisé le langage Perl "professionnellement", souvent en conjonction avec le tableur, pour traiter des données en masse. Mon profil est probablement atypique puisque je ne suis pas informaticien de profession - ma spécialité est le calcul dans le domaine de la mécanique (automobile). Je "développe" mes propres outils dans ce que j'ai sous la main, et ce langage en fait partie.

[archqt]

Non je n'utilise pas Perl, sa lecture m'a toujours semblé difficile. Je suis conscient que les concours visant à faire le code le plus petit pour faire une tâche n'ont pas aidé non plus à rendre un attrait pour perl. Perl c'est mieux que le bash au niveau lecture mais moins bien que python.

Du coup si script il y a je passe en python.

[GLDavid]

Bonjour

Pour ma part, honte à moi qui suis ancien modo de cette rubrique, je n'utilise plus Perl.
Il est vrai que mes choix sont dictés par le business. Mais le passage vers Perl 6 a été fatal.
Alors, je conçois que maintenant des nouvelles versions arrivent pour inverser la vapeur, il n'est peut être pas trop tard.
Mais, la force de Perl 5, c'était pas tellement le langage en lui-même mais le CPAN où l'on trouvait la librairie de son choix!
Et changer tout CPAN vers d'autres versions de Perl promet un mal de crâne sévère.
Je me demande finalement si Perl 5 ne va pas devenir le nouveau COBOL?

@++

[esperanto]

Mais le passage vers Perl 6 a été fatal.

Quel passage à Perl 6? Ils ont attendu 10 ans àvant d'avoir quoi que ce soit de stable et encore aujourd'hui je n'ai vu aucune distribution linux incluant l'interpréteur Raku. Par contre elles incluent encore toutes Perl 5, et ce n'est pas pour rien s'ils ont continué jusqu'à la version 5.34
Là où je travaillle, les scripts qui tournent sur des serveurs Unix sont toujours écrits en Perl 5. Bon c'est vrai qu'il y en a rarement qui soient vraiment nouveaux (c'est souvent la même méthode appliquée à un nouveau format de données) mais dès qu'il y a du traitement de langage naturel, on voit du Perl, pas du Python.

[GLDavid]

Quel passage à Perl 6? Ils ont attendu 10 ans àvant d'avoir quoi que ce soit de stable et encore aujourd'hui je n'ai vu aucune distribution linux incluant l'interpréteur Raku. Par contre elles incluent encore toutes Perl 5, et ce n'est pas pour rien s'ils ont continué jusqu'à la version 5.34
Là où je travaillle, les scripts qui tournent sur des serveurs Unix sont toujours écrits en Perl 5. Bon c'est vrai qu'il y en a rarement qui soient vraiment nouveaux (c'est souvent la même méthode appliquée à un nouveau format de données) mais dès qu'il y a du traitement de langage naturel, on voit du Perl, pas du Python.

Donc, ce que je dis est vrai: le passage vers Perl 6 a été raté (euphémisme). On se retrouve uniquement avec du Perl 5.X. Tu dis que tu as toujours des vieux scripts qui fonctionnent toujours, je reprend alors l'image de COBOL, véritable fossile vivant des langages informatiques.
Cependant, je te rejoins que dans ta branche, la linguistique, Perl est incontournable. Cependant, dans la mienne (bio/chemoinformatique), Perl a été le langage de prédilection, enseigné dans les cursus de bioinformatique jusqu'à... la tentative de passage vers Perl 6. Aujourd'hui, dans mon domaine, Perl ne fait plus figure de référence depuis plus de 10 ans. Maintenant, Python est le langage de script des sciences (rivalisant avec R sur les stats) mais peut être aussi changé par des langages tels Java ou C#.
Pour en revenir à ce sauvetage de Perl, j'attends de voir comment ils vont s'y prendre pour le futur Perl 7. J'ose espérer que le board Perl a retenu la leçon de Perl 6.

@++

[Gugelhupf]

Je vais ajouter mon grain de sel à la conversation, pour moi c'est "phpMyAdmin" qui a commencé à tuer Perl il y a 10-15 ans, et aussi les hébergeurs qui proposaient tous PHP à cette époque. Durant mes cours on utilisait encore Perl comme langage comparatif à PHP, mais c'est PHP qui nous servait de "complément Web" au C++. Un langage de haut niveau reste un langage simple à prendre en main, c'est surtout la facilité d'installation et la possibilité de déployer son build où l'on veut qui ont propulsés certains langages.

[yahiko]

... ou bien laisser le langage mourir.

Admettre que Perl n'apportait plus tant que ça par rapport aux autres langages, et qu'il ne manquera pas vraiment à l'informatique s'il venait à disparaître.

Parfois, vouloir maintenir en vie un langage moisi peut ressembler à de l'acharnement thérapeutique.

[esperanto]

Je vais ajouter mon grain de sel à la conversation, pour moi c'est "phpMyAdmin" qui a commencé à tuer Perl il y a 10-15 ans, et aussi les hébergeurs qui proposaient tous PHP à cette époque. Durant mes cours on utilisait encore Perl comme langage comparatif à PHP, mais c'est PHP qui nous servait de "complément Web" au C++. Un langage de haut niveau reste un langage simple à prendre en main, c'est surtout la facilité d'installation et la possibilité de déployer son build où l'on veut qui ont propulsés certains langages.

Sauf que contrairement à PhP, et contrairement à une croyance répandue, le web n'est pas la vocation première de Perl.

"Practical Extraction and Reporting Language" était à l'origine destiné à remplacer Awk, un langage beaucoup utilisé sous Unix pour construire des filtres, c'est à dire des programmes qui lisent un fichier texte ligne à ligne et produisent une sortie en fonction de certains critères. Ce n'est qu'à partir de la version 3 qui'on a pu écrire des programmes n'étant pas des filtres.

Après c'est vrai qu'il a été beaucoup utilisé pour les CGI, mais il ne visait pas le même public que PhP. Avec PhP on écrit typiquement des sites web dépendant d'une base de données, plus rarement des scripts dépendant de fichiers.

Sinon, autant je veux bien voir le lien avec PhP (quoique la plupart des hébergeurs acceptent aussi les CGI en Perl) mais avec PhPMyAdmin j'ai un peu plus de mal.

[CaptainDangeax]

Je viens de terminer un projet de modernisation d'une vieille application Perl datant de 2008. Les 2 développeurs de mon équipe se sont bien pris la tête et pour bien verrouiller le truc, il existe en plus dans le projet des librairies binaires qui ne fonctionnent QUE sous Debian 3.1 en mode x86. Docker permet de conserver cet existant, mais pour l'ajout de nouvelles fonctionnalités bonjour la difficulté. Evidemment si mon employeur me renvoie sur une autre mission de modernisation d'une vieille application (ce qui est probable vu mon historique pro) je l'accepterai. En tout cas Perl 5.8 était une découverte sur ce projet et je n'ai aucune envie d'approfondir.

[FatAgnus]

il existe en plus dans le projet des librairies binaires qui ne fonctionnent QUE sous Debian 3.1 en mode x86.

Je suis vraiment très curieux de connaître ces bibliothèques qui ne fonctionnent sur sous Debian Linux 3.1 Sarge sortie en juin 2005 ? L'un des gros avantages de Perl étant la stabilité et la compatibilité du langage. Généralement un script Perl écrit il y a vingt ans fonctionnera tel quel sous un interpréteur Perl récent (mais effectivement il peut y avoir un changement d'API de certains modules Perl qui ne dépendent pas vraiment du langage Perl). Alors que faire fonctionner un script Python ou PHP écrit en 2005 sur un interpréteur Python ou PHP actuel reste une gageure.

Apple pour sa part a annoncé officiellement en 2019 que le runtime de Perl (et aussi ceux d’autres langages de scripts comme Python et ruby) ne sera plus installé par défaut dans les nouvelles versions de macOS.

Vous reprenez un des nombreux arguments bidons du clown de The HFT Guy qui prédit la mort de Perl en 2023 mais qui a une connaissance très limitée de Perl (ce clown de The HFT Guy croit que si Perl est préinstallé sous GNU/Linux c'est dû à une spécification POSIX, on voit le niveau du gars).

Pourquoi le retrait de Perl et Python de macOS serait un signe de perte de vitesse de Perl alors que Python est lui même un langage très très populaire ? S'il vous plaît arrêter de faire du copier-coller et réfléchissez un minimum.

[FatAgnus]

Admettre que Perl n'apportait plus tant que ça par rapport aux autres langages, et qu'il ne manquera pas vraiment à l'informatique s'il venait à disparaître. Parfois, vouloir maintenir en vie un langage moisi peut ressembler à de l'acharnement thérapeutique.

Vous prétendez représenter l'avis de tous les développeurs ? Vous avez une expérience de développeur en langage Perl ou vous avez juste un avis sur tout sans rien connaître ?

Pour information dans un système d'exploitation comme Debian GNU/Linux (ou ses dérivés comme Ubuntu, Linux Mint...) le langage Perl a une priorité de type « required » et est classé comme « Essential ». Ce qui signifie qu'un système d'exploitation Debian GNU/Linux (ou ses dérivés) ne peuvent pas fonctionner sans l'interpréteur Perl. Des milliers de logiciels disponibles sous Debian et ses nombreuses dévrivées sont développés en langage Perl. Vous vous proposez de tout redévelopper en Python ?

Autre exemple, l'excellente solution libre de virtualisation Proxmox VE contient aussi des dizaines de milliers de ligne de code écrites en langage Perl. Vous vous proposez de tout redévelopper en Python ?

Perl est un très beau langage apprécié de certains développeurs. Je ne comprends pas cet entêtement (qui dure depuis plus de dix ans) de certaines personnes qui ne connaissent rien à Perl à vouloir la mort de Perl. Perl, n'est pas un langage à la mode, et alors ? Est-on obligé de développer dans un langage à la mode et de suivre le rythme effréné des développeurs de PHP ou Python qui ajoutent du sucre syntaxique à l'interpréteur PHP ou Python et cassent la compatibilité ? Si cela vous amuse de redévelopper vos applications tous les deux ans car PHP casse la compatibilité régulièrement, utilisez PHP ou un autre langage qui participent à cette fuite perpétuelle en avant, et laissez tranquille les développeurs Perl.

[facila]

activer strict par défaut dans les versions à venir
sera-t-il possible de le désactiver ou bien cela veut-il dire que strict sera obligatoire ?

si strict devient obligatoire , c'est pour moi au contraire une raison de ne plus faire de perl
dans ce cas plus possible d'utiliser des variables globales , ce qui contrairement à ce que certains croient est une fonctionnalité très importante

[esperanto]

activer strict par défaut dans les versions à venir
sera-t-il possible de le désactiver ou bien cela veut-il dire que strict sera obligatoire ?

Non, il sera toujours possible d'écrire "no strict", comme c'est déjà le cas depuis longtemps (tu peux très bien écrire "use strict" globalement et "no strict" au niveau d'un bloc).
Il y a aussi des options, comme "strict vars" ou "strict refs" suivant ce que tu veux autoriser ou pas.

Ce qui va changer, c'est le comportement des scripts qui ne contiennent ni "use strict" ni "no strict". Le seul souci c'est donc que certains programmes qui fonctionnent parfaitement en Perl 5 vont afficher des erreurs, que tu pourras faire disparaître en ajoutant explicitement "no strict" dans le fichier.
De toute façon "strict" était automatiquement activé lors de l'usage de certains frameworks.

si strict devient obligatoire , c'est pour moi au contraire une raison de ne plus faire de perl
dans ce cas plus possible d'utiliser des variables globales , ce qui contrairement à ce que certains croient est une fonctionnalité très importante

Même avec "use strict", tu peux toujours utiliser des variables globales, la différence est qu'il faut les déclarer: soit avec "use vars" (ancienne syntaxe dont je n'ai pas lu qu'elle serait supprimée) ou avec le mot-clé "our" à la place de "my" (à partir de Perl 5.6 si je me souviens bien).

L'intérêt de les déclarer, c'est d'éviter des erreurs bêtes comme des fautes de frappe: genre tu utilises $nomTresLong partout dans le script et à un endroit tu as écrit $nomtresLong, sans "use strict" il va créer deux variables distinctes. Avec use strict, vu que tu as déclaré $nomTresLong il va râler dès qu'il voit une autre orthographe.

Et pour moi c'est au contraire un plus de Perl par rapport à Python ou Ruby, parce que si ces langages distinguent bien les variables globales et locales, le fait qu'on ne les déclare pas fait que leur portée exacte (surtout pour les variables locales) ne saute pas aux yeux au premier coup d'oeil.

[Model_T101]

Face à PHP et Python Perl à perdu des utilisateurs, car ils y trouvent la solution à leurs besoins, certes. C'est très dommage que l'apport du créateur en personne de ce langage ait conduit à une scission destructrice de l'unité : Perl & Raku. Quand il a dit ceci est Perl6 ils ont forcé, non ça nous dérange appelle ça Raku et fais ça de ton coté comme un sidecar.HONTE.
Aujourd'hui "des" changements que ces gens là trouvaient trop révolutionnaires sont incorporés dans Perl5 avec on vous préviens que ça va être moins compatible. En adoptant Raku du premier coup en accompagnant tout le monde vers l'évolution en maintenant un nom unique connu de tous ils auraient évité le naufage. Non merci je préfère une salade et finalement je te pique une frite. C'est triste.
Incorporer du Raku dans Perl5 pour l'appeller Perl7 c'est donc tout ce qu'il leur reste comme méthode ?
Laurent Rosenfeld ici même à écrit d'excellentes leçons sur ce qui change dans Perl, puis sur la façon de s'approprier la nouvelle mouture.
Moi qui ne suis pas du tout developpeur ça ne m'a fait aucun changement et je comprend ceux qui ont passés beaucoup de temps sur Perl5, malgrés tout
à l'arrivé de Perl6 il aurait quand même fallu que toute la communauté passe la vague : sed s/Perl5/Perl6/ et non pas Raku qui pointe sur la poterie japonaise si tu omet "lang"

Aujourd'hui s'ils veulent eviter le naufrage il ne leur reste qu'a écouter Larry Wall car Raku est proprement génial. Ce n'est pas un "sister language" comme indiqué sur le CPAN, c'est l'évolution. Ils doivent en passer par l'étape qu'on vécut ceux qui ont appris Perl6 dès son arrivée et dû renommer Raku.
Dorénavent Perl devient Raku une bonne fois pour toutes, un seul language un seul nom le fork c'est la confusion et donc la dispersion.

https://perl.developpez.com/actu/280...ge-de-scripts/