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

Marc SCHAEFER schaefer at alphanet.ch
Sat Mar 10 08:55:28 CET 2018


On Sat, Mar 10, 2018 at 01:07:41AM +0100, Daniel Cordey wrote:
> programmeur Perl aura moins tendance à faire un "for" sur une
> variable préfixée '$', mais si la fonction a retourné une liste
> plutôt qu'un scalaire, nous aurons aussi une erreur. On a simplement

Non, justement. Si la fonction a retourné une liste plutôt qu'un
scalaire, dans ta variable préfixée $ tu as le premier élément
de la liste.

On ne peut pas faire un foreach avec une variable $. Sauf si
c'est une référence, mais alors il faut le dire explicitement.
En bref, un argument de foreach sera toujours une variable
qui commence par @ ou un contexte de liste. Ce qui permet
à Perl de planter à la "compilation" si ton contexte
est faux.

foreach my $i (@tableau) {
}

foreach my $i (@$tableau_reference) {
}

Effectivement, en PHP par exemple, tu auras des erreurs à l'exécution si par
malheur ta $variable n'a pas le bon type; en Perl, sans utiliser les
références, tu n'auras que des erreurs à la "compilation".

La sémantique que l'appelant a voulu est donc préservée.  Ca choque,
effectivement, car quasiment tous les langages à typage à la compilation
imposent le type de la signature de la fonction. Il n'y a pas de signature
en Perl. Toute fonction reçoit toujours une liste (un tableau, qui peut se
réduire à un seul scalaire) comme arguments et retourne
ce qu'elle veut (une liste, qui peut se réduire à un seul scalaire).

Ensuite c'est à toi de décider en tant qu'appelant ce que tu veux
en faire, explicitement en utilisant une variable @, % ou $:

> Si je désire assigner un type particulier à ma variable, je
> veux avoir le choix de le faire de manière explicite et non
> restrictive et sans limite; avec des fonctions de type int(), str(),
> tuple(), etc. Si cela n'est pas possible, l'erreur pointera
> exactement sur cette opération et ne sera pas décalée ailleurs dans
> le code.

Je suis d'accord, pour tout langage classique. Or Perl est basé
sur la notion de contexte ...  c'est une des grandes puissances
de ce langage. Tu enlèves ça et tu as peu ou prou du PHP (oui,
bon, pas tout à fait :->)

Ok, en Perl on peut aussi

   1. définir l'interface de la fonction pour ne supporter qu'un
      seul argument scalaire (style: sub do_something($)), même
      si c'est peu utilisé.

   2. utiliser le passage de paramètre nommé, du genre
         do_something(-scalaire=> $bla)
      (assez utilisé)

   3. passer des objets avec accesseurs (très utilisés, par les
      développeurs qui maîtrisent l'OO)

La méthode 1 est peu utilisée car on aime bien des
fonctions génériques qui peuvent traiter un ou plusieurs
arguments et retourner un ou plusieurs arguments (contexte liste),
dans une sémantique cohérente.

> Perl fait le boulot, mais je ne le prendrais pas comme langage
> didactique... à moins d'être chargé d'enseigner le "code
> obfuscating" :-)

Non, effectivement, je parlais de la pérennité de l'investissement,
de la puissance du langage, etc. Avoir appris ce langage il y a 22
ans a été un excellent investissement.

Apprendre Perl aujourd'hui n'est pas forcément utile, vu par exemple
la place de Python.

Encore que si l'on utilise les concepts modernes exclusivement
(Moose par exemple), Perl est très propre et pourrait être enseigné.
En particulier si le but pédagogique est que tous les étudiant-e-s
soient au même niveau au départ :->

Plus sérieusement, en ce qui me concerne, dans un cursus de développement
logiciel aujourd'hui, je proposerais:

   - le C pour appliquer les notions d'architectures des ordinateurs,
     y compris la portabilité

   - le python pour voir un langage de script générique (appliqués aux
     calculs mathématiques ainsi qu'au développement Web p.ex. avec Django,
     le fonctionnel, l'OO)

   - le Java car c'est le langage Entreprise de référence aujourd'hui et
     la JVM est très importante dans plein de langages

   - le Javascript car c'est l'assembleur portable d'aujourd'hui

et pour ceux qui vont plus dans la direction "système":

   - bash

et pour ceux qui vont plus dans l'embarqué:

   - C++

   - assembleur (code bootstrap notamment)

Quant à Perl, PHP, Ruby, etc, je les proposerais en
option pour investiguer un axe en particulier (Perl: regexp,
Moose, Mojolicious), PHP (Laravel), Ruby (On Rails).

Il y a des gens qui utilisent Caml? :)


More information about the gull mailing list