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

[Marc SCHAEFER]

On Fri, Mar 09, 2018 at 11:34:49AM +0100, Laurent Franceschetti wrote:
> Peut-être qu???il y a, dans ces problèmes logiques et ces « encombrements » (qui ne sont pas rédhibitoires), une explication de pourquoi Perl peut rebuter?

L'erreur à ne pas faire en Perl est de l'aborder comme
un langage "classique" sans s'informer sur les différences importante:

   - perl est un véritable langage d'expression

   - le contexte scalaire, liste ou hash fonctionne différemment

   - les tableaux de hâchage ne sont pas des tableaux associatifs
     à ordre déterminé

   - il n'y a pas qu'une façon de faire quelque chose, car il
     n'y a pas besoin de quelqu'un qui nous impose des choix

En plus, je pense que ce qui peut gêner c'est la flexibilité
du langage: du langage permissif de script au langage solide
orienté objet et extensible.

Je pense que c'est une question de public.

La personne qui veut juste écrire un petit script qui traite des données
rapidement ne va pas s'inquiéter de la portée de ses variables ni
d'autres éléments: il ne va peut-être même pas écrire de "use strict;
use warnings;" et donc pas de "my" non plus.

La personne qui ne connaît pas l'orienté-objet mais qui écrit des
programmes un peu plus longs (petits web-services, traitement de
données un peu plus complexe, DB) va utiliser "use strict; use warnings",
voire même peut-être jouer avec la portée avec les packages (non
orientés OO). Elle utilisera les interfaces impératives des modules
CPAN, ou parfois les interfaces OO lorsque cela fait sens.

La personne qui veut faire 100% orienté-objet va utiliser Moose,
le use strict; use warnings est implicite et la plupart des déclarations
ont une portée limitée sans avoir besoin de "my" et autres. Elle
utilisera les interfaces OO des modules CPAN.

Il faut toutefois se rendre compte que les développeurs proches
du système n'ont pas forcément des connaissances orienté-objet poussées,
ni des besoins, finalement, de cette complexité supplémentaire. Il vaut
mieux pour eux rester à un niveau où ils sont productifs.

Perl est un langage qui a plus de 20 ans et qui malgré le fait qu'il
réponde à tous ces publics reste très largement rétro-compatible: je
tourne par exemple des scripts web que j'ai écrits fin 90 et qui
sont sécurisés pour les échappements HTML, urlencode et les
insertions dans la BD par binding.

Il y a peu d'autres langages -- à part un sous-ensemble du shell bash
et le langage C, tant qu'on se limite à la console -- qui offrent
cette flexibilité et cette puissance sur le long terme, à mon avis.

Je ne me plains jamais de la flexibilité et des choix qu'offrent
un système UNIX (choix de GUI, de langages, etc). J'apprécie la
flexibilité et les choix offerts par Perl.