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
_______________________________________________
gull mailing list
[email protected]
http://forum.linux-gull.ch/mailman/listinfo/gull
