[gull] Faut-il réhabiliter Perl comme langage de scripting système?

Mon Mar 5 08:42:51 CET 2018

> Le 5 mars 2018 à 00:25, Daniel Cordey <dc at pxcluster.com> a écrit :
> 
> 
> Je ne dirais pas ça. Perl est un langage qui a été conçu pour pouvoir écrire des scripts d'administration plus facilement qu'en shell; et c'est ce qu'il fait exactement.

Je suis d’accord avec ce positionnement.

> 
> 
> J'ai écrit des dizaines de milliers de lignes en sh/ksh/bash... mais c'est vrai qu'aujourd'hui je ne le ferais plus. Très souvent on commence par un petit script de 20-30 lignes et on fini par exagérer. Il est toujours difficile de savoir à partir de quel moment il faut changer de cheval. Perl permet d'aller beaucoup plus loin que le shell, en plus du fait qu'il existe des tas de librairies Perl. Mais, comme tout, il a aussi ses limites. A partir de quel moment faut-il encore changer de cheval ? Je crois que la question est souvent très personnelle, car elle dépend des compétences que l'on a dans les différents langages. Il est évident que si tu ne connais pas C ou Python, tu ne vas pas t'y mettre d'un seul coup.
> 
> Il m'est aussi arrivé d'osciller entre bash et Python.. de commencer d'écrire en bash puis de basculer à Python lorsque le problème se complexifie.
> 

Dans le mille! C’est bien la question qui occupait mon esprit, mais je ne l’avais pas formulée aussi explicitement. Quel outil pour quelle tâche? Et si on s’aperçoit que ça devient trop compliqué, qu’est-ce qu’on fait?

Cela m’est également arrivé de réécrire mon script en Python. Le bon c’est qu’on a l’impression de passer d’un vieil Unimog militaire <http://r2087.free.fr/new/pages.php3?num=87> à une limousine civile tout confort. Mais (à moins qu’on trouve la librairie toute faite, ce qui est souvent le cas) aussi il y a toujours ce moment désagréable où il faut convaincre le langage d’interagir avec le shell… on dirait presque que c’était intentionnel.

> Un exemple :
> 
> Je voulais écrire un bout de script qui me donne des statistiques sur les packages/modules Python que j'ai. J'ai commencé à l'écrire en bash puisque je ne voulais initialement que le nombre de lignes, le nombre de commentaire, etc. C'était assez simple au début et ça allait assez bien. En effet, $ coup de wc -l, grep -v, sed, awk, etc. je m'en sortais très bien et ça restait simple et petit. Naturellement, j'en ai voulu toujours plus et j'ai commencé à produire des statistiques plus fines concernant les doc strings, les fonctions, les méthodes, etc. Et les limites du shell sont apparues. Le faire en Perl... j'aurais eu le même problème car je ne pouvait me contenter de faire joujou avec des regexp... le problème devenait trop complexes car il fallait analyser la syntaxe. J'ai donc récrit en Python et j'ai mes stats... mais maintenant je m'aperçoit que je devrais passer à l'utilisation de Lex/Yacc (Ply en Python) car l'analyse syntaxique ne peut plus se suffire de combinaisons de regexp et split()…

Très adapté (la fameuse barrière des parenthèses imbriquées).

> 
> Ce qui me fait dire que rien n'est jamais définitif et que l'on doit toujours se poser la question de savoir si l'on doit persévérer dans une voie ou remettre les choses à plat. Ce qui fait que l'on devrait penser en terme de solution finale, mais on a rarement tous les éléments lorsque l'on commence un script :-)

Oui, c’est le noeud du problème. I

> 
> 
> ... tous les modules io, os, os.path, etc. sont très proches des librairies C (chapitre 2 & 3). C'est vrai que l'argument 'mode' de la fonction 'open' a le don de m'énerver, mais à part ça, je retrouve un environnement familier.
> 

Deux bons points

> C'est aussi vrai que lorsque tu connais le shell et le C, l'écriture de Perl pour lire un fichier a de quoi dérouter.
> 
> my $filename = 'data.txt';
> open(my $fh, '<:encoding(UTF-8)', $filename)
> or die "Could not open file '$filename' $!";
> while (my $row = <$fh>) {
> ...
> 
> En fait dans Perl, on te demande d'entrer dans un monde assez exclusif ou tu dois pratiquement oublier tout ce que savais au sujet de ce que tu connais déjà. De plus, aucun autre langage n'utilise '<' pour parler de open-en-mode-lecture; en plus du fait que ce n'est absolument pas intuitif) !!! 

Voilà, tu as mis le doigt sur ce qu’on n’aime pas dans Perl: son côté cryptique et exclusif — ce qui le rend parfois asocial.

Plus le temps passe, et plus je suis convaincu du bien-fondé de la "programmation littéraire »: qu’on écrit à la fois pour la machine et pour les humains qui vont relire notre code. Pour ma part, je souscris à l’atticisme: « Pureté, clarté et élégance » (en référence au style littéraire de l’Antiquité).

Or Perl permet, pour peu que l’auteur soit renfermé sur soi ou tordu, d’écrire du code grotesque. Entre la poésie Perl <https://docstore.mik.ua/orelly/perl/prog3/ch27_02.htm> et la poésie des Vogons <https://www.youtube.com/watch?v=ysb-TwA7JCQ>, c’est une échelle d’insupportabilité… Pour être juste, Perl a introduit POD pour documenter le code, mais ça aurait été mieux de faire du code lisible au départ.

> 
> Mais le shell fait justement ça de manière encore plus logique à mes yeux. Il utilise pour ça les commandes GNU : grep, sed, sort, awk, tr, etc. C'est logique, la doc se trouve en faisant 'man'... Non, Perl ajoute des capacités de traitement et une forme de structure de donnée qui est absente, ou trop cryptique, en shell. Perl est justement rès complet pour faire dus système admin car il a tous les outils, sauf qu'il traîne un certain nombre de points négatifs avec lui et c'est sans doute ce qui le rend moins attractif lorsque tu as des alternatives.
> 

Bon résumé. Perl traîne avec lui ce boulet. 
> 
>> 
>> Il me semble d’ailleurs que les jeunes informaticiens (en tout cas ceux qui s’expriment sur les réseaux sociaux) sont assez pragmatiques et ouverts aux nouvelles idées. Cela les rendrait peut-être plus à même de casser les stéréotypes des générations précédentes?
> 
> Ouai, mais va falloir leur faire avaler les 'my', '$', '@' et autres bizarreries de Perl... c'est pas gagné :-)
> 
> Mais... pourquoi ne pas essayer... On ne sait jamais... j'ai peut-être tout faux :-)

Non, je crois que tu as raison. A ce stade je ne verrais que trois solutions, qui ne sont pas forcément incompatibles:

On enseigne Perl aux nouvelles générations, en leur disant que c’est un drill pour informaticiens: pour apprendre à s’exprimer correctement non pas parce que le langage les oblige, mais parce que leur pensée doit être limpide. 

On adapte un langage de haut niveau la résolution de ce problème (j’ai expérimenté une idée assez radicale en Python, que j’aimerais une fois vous soumettre).

Ou alros, remet l’ouvrage sur l’atelier, en créant un nouveau langage de programmation système à partir de zéro (avec l’effort énorme que cela comporte).

Encore merci pour ces considérations, qui alimentent bien ma réflexion!

Bonne journée,
L.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20180305/7f7c68f8/attachment-0001.html>