<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 5 mars 2018 à 00:25, Daniel Cordey <<a href="mailto:dc@pxcluster.com" class="">dc@pxcluster.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">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.<br class=""></div></div></blockquote><div><br class=""></div><div>Je suis d’accord avec ce positionnement.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>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?</div><div><br class=""></div><div>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 <a href="http://r2087.free.fr/new/pages.php3?num=87" class="">vieil Unimog militaire</a> à 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.</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Un exemple :<br class=""><br class="">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()…</div></div></blockquote><div><br class=""></div><div>Très adapté (la fameuse barrière des parenthèses imbriquées).</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">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 :-)<br class=""></div></div></blockquote><div><br class=""></div><div>Oui, c’est le noeud du problème. I</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><br class="">... 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.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Deux bons points</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">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.<br class=""><br class="">my $filename = 'data.txt';<br class="">open(my $fh, '<:encoding(UTF-8)', $filename)<br class="">or die "Could not open file '$filename' $!";<br class="">while (my $row = <$fh>) {<br class="">...<br class=""><br class="">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) !!! <br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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é).</div><div><br class=""></div><div>Or Perl permet, pour peu que l’auteur soit renfermé sur soi ou tordu, d’écrire du code grotesque. Entre la <a href="https://docstore.mik.ua/orelly/perl/prog3/ch27_02.htm" class="">poésie Perl</a> et la <a href="https://www.youtube.com/watch?v=ysb-TwA7JCQ" class="">poésie des Vogons</a>, 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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class="">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.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Bon résumé. Perl traîne avec lui ce boulet. </div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><br class="">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?<br class=""></blockquote><br class="">Ouai, mais va falloir leur faire avaler les 'my', '$', '@' et autres bizarreries de Perl... c'est pas gagné :-)<br class=""><br class="">Mais... pourquoi ne pas essayer... On ne sait jamais... j'ai peut-être tout faux :-)<br class=""></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">Non, je crois que tu as raison. A ce stade je ne verrais que trois solutions, qui ne sont pas forcément incompatibles:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">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. <br class=""><br class=""></li><li class="">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).<br class=""><br class=""></li><li class="">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).</li></ol><div class=""><br class=""></div></div><div class="">Encore merci pour ces considérations, qui alimentent bien ma réflexion!</div><div class=""><br class=""></div><div class="">Bonne journée,</div><div class="">L.</div><div class=""><br class=""></div></body></html>