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

[Daniel Cordey]

On 04. 03. 18 21:19, Laurent Franceschetti wrote:
>
> Mon idée centrale est que si on le compare à un script bash, alors il 
> se défend.

Absolument.

> _Perl est surtout un language de bas niveau_.

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 me demande is Perl ne devrait pas être au script shell, ce que C 
> est  l’assembleur: un espéranto; donc juste un poil plus haut niveau 
> que le script shell (et donc plus portable), mais justement pas au 
> point d’être un langage de haut niveau!

Je trouve cette comparaison très juste.

>
> Pareil pour moi: j’adore Python y-compris pour l’administration 
> système, et je n’aime pas Perl… mais je déteste encore plus les 
> scripts shell!

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.

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()...

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 :-)

>
> Si on relève les défauts de Perl (avec raison), alors pourquoi les 
> scripts shell ne sont-ils pas cloués au pilori?

Absolument ! le shell (tous) ont de très gros problèmes... mais quand il 
s'agit d'écrire deux ou trois lignes on ne se pose pas trop de questions.

> Et pourtant, si nous continuons à les utiliser, il doit bien y avoir 
> une raison…

Oui, le shell utilise massivement de tas de commandes GNU, alors que la 
plupart de ces fonctions sont intégrées à Perl. Le problème est qu'il 
faut les apprendre en plus d'une syntaxe différente. C'est sans doute 
une barrière d'entrée pour pas mal de gens.

>
> Je crois que la raison est que quand on fait des scripts shell 
> « bare-metal », on recherche précisément ce contact dur et froid avec 
> la machine: c’est un avantage. Python est un langage de l’élégance et 
> du raffinement  parce que son Zen est d'utiliser des librairies. Le 
> revers de la médaille, c'est qu'il nous isole parfois un peu trop de 
> l’OS,.

Ben, je trouve pas... 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.

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) !!! On te demande de faire partie d'une secte :-) Plus 
sérieusement, tu repars un peu à zéro et c'est sans doute ce qui rebute 
un certain nombre de gens; d'autant que ce que tu auras appris avec Perl 
(je parle de sa syntaxe et de la sémantique) est inutilisable ailleurs.

> Perl, au contraire, n’est pas fait pour être contemplé mais pour 
> l'atelier: il est fonctionnel, primitif et pour tout dire laid.  Mais 
> la grande force (oubliée) de Perl, _c’est d’adhérer de près logique du 
> système UNIX_: coller les utilitaires système à la McGyver, avec des 
> élastiques, des trombones et tout ce qu’on trouve sous la main.

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.

>
> Et je trouverais même une sorte de beauté dans ce style brutaliste…

Aïe... suis pas maso à ce point :-)

>
> Et pourtant ils apprennent toujours des scripts bash, ainsi que du C… 
> Et dans le style brutaliste, quid de JSON, voire CSS etc.?

Avec l'utilisation de macros & CPP on arrive à faire des choses très 
élégantes et très avancées en C. On peut même faire de la programmation 
objet en C (j'ai fait). Voire les premiers "translateurs/compilateurs" 
C++ et XtoolKit, entre autre.

>
> 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 :-)

dc