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

2018-03-13 Par sujet Laurent Franceschetti 
C’est juste, c’est quand même le comble qu’aujourd’hui ce soit toujours la 
croix à la bannière, de faire un petit utilitaire GUI pour l’administration 
système.

A mettre dans les specs du cheval de labour?

Bonne journée,
Laurent


> Le 12 mars 2018 à 23:17, Daniel Cordey  a écrit :
> 
> 
> Tcl est aussi un langage de scripting qui a un certain nombre d'années au 
> compteur (30), par rapport au sh/ksh de l'époque c'était déjà un gros plus 
> (listes + associative arrays) et il était surtout associé à Tk qui était l'un 
> des seul moyen de faire un programme (facilement) avec un GUI à l'époque (Je 
> dis facilement parce que l'exercice avec Dtksh était hyper lourdingue (pour 
> ceux qui ont connu Motif et les ressources des Widgets)). Aujourd'hui, ce 
> fameux couple est toujours vivant mais il a perdu de son attrait au détriment 
> de choses comme Python/Tkinter (tiens... Tk !). L'avantage de Tcl est qu'il 
> est très peut gourmand en mémoire et c'est un bon candidat pour de 
> l'embarquer. Y'a mieux, mais ça reste un langage simple. C'est un langage de 
> programmation générale et pas forcément le meilleur choix pour faire du sys 
> admin; mais c'est parfaitement possible et on peut faire des choses un peu 
> plus compliquées qu'en *sh en conservant de la lisibilité et des fonctions de 
> "debuging".

___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-12 Par sujet Daniel Cordey 



On 12. 03. 18 22:49, Laurent Franceschetti wrote:
Et pour le repoussoir, le Powershell n’est pas l’idée que je me fais 
d’un langage logique d'administration — leur système de pipes à objets 
c’est comme la défunte industrie soviétique: une fois qu’on a enfin 
trouvé un écrou dans le fatras, il faut encore chercher longtemps pour 
trouver le boulon qui va avec, à moins que la livraison ne soit prévue 
que dans le prochain plan quinquennal…


MDR !

Félix a écrit :

>  Il y a des gens qui utilisent LISP! J'ai même vu, en 2017, du Tcl/Tk!!

Tcl est aussi un langage de scripting qui a un certain nombre d'années 
au compteur (30), par rapport au sh/ksh de l'époque c'était déjà un gros 
plus (listes + associative arrays) et il était surtout associé à Tk qui 
était l'un des seul moyen de faire un programme (facilement) avec un GUI 
à l'époque (Je dis facilement parce que l'exercice avec Dtksh était 
hyper lourdingue (pour ceux qui ont connu Motif et les ressources des 
Widgets)). Aujourd'hui, ce fameux couple est toujours vivant mais il a 
perdu de son attrait au détriment de choses comme Python/Tkinter 
(tiens... Tk !). L'avantage de Tcl est qu'il est très peut gourmand en 
mémoire et c'est un bon candidat pour de l'embarquer. Y'a mieux, mais ça 
reste un langage simple. C'est un langage de programmation générale et 
pas forcément le meilleur choix pour faire du sys admin; mais c'est 
parfaitement possible et on peut faire des choses un peu plus 
compliquées qu'en *sh en conservant de la lisibilité et des fonctions de 
"debuging".


dc



___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-12 Par sujet Laurent Franceschetti 
Il me semble qu’on touche des points importants ici.


> Le 12 mars 2018 à 14:28, Daniel Cordey  a écrit :
> 
> Oui, mais de l'embarqué a souvent un système vraiment minimum et on a que 
> 'sh' parfois avec quelques commandes. La tendance est à avoir plus de RAM et 
> des cartes SD, mais ce n'est pas garanti et là tu n'as que 'sh' ou des fois 
> seulement du code compilé (Arduino). On ne peut donc pas généraliser et le 
> vrai embarqué aura toujours pas mal de limites.

Cela restera comparativement limité, mais les nouvelles plateformes embarquées 
supportent désormais des langages assez évolués, même si ce sont des versions 
réduites comme MicroPython (par exemple sur micro:bit 
).

Javascript semble désormais aussi un candidat pour l’embrarqué.

>> 
> 
> C'est justement là que Perl prend le relais. Les shells (dont bash) sont des 
> langages de scripting quand même limités et ne sont pas destinés à devenir 
> des langages de programmation généraux. Comme préciser au début de cette 
> discussion, attention à ne pas sur-utiliser bash/sh/*sh. Bash est un langage 
> destiné à exécuter des commandes et a énormément de limitations comme langage 
> de programmation générale (pas de calculs en flottant, pas de binaire, etc.)
> 

C’est là que je mettrais Perl, parce que c’est ce qui se rapproche le plus de 
l’idée que je me fais d’un langage de scripting système.

Mais je dois quand même dire qu'il y a quelque chose dans Perl qui le rend un 
peu problématique, même à mes yeux. Une fois, van Rossum avait dire de certains 
développeurs que « they are too smart for their own good ». Peut-être que le 
créateur de Perl a voulu faire quelque chose de trop sophistiqué, un langage 
avec de très grandes ambitions. Et comme on dit parfois, « le mieux est 
l’ennemi du bien » et le résultat est que cela a fait fuire les programmeurs.

Il y a quelque chose dans Perl, d’avoir desespérément voulu accéder aux plus 
grandes gloires… et de se retrouver en relégation justement à cause de ça. Si 
cela m’était donné à faire ou à refaire, je ne tenterais pas de faire un 
Bucéphale, mais juste un bon cheval de labour, aimable, fiable et prévisible, 
une bonne bête quoi.

En attendant, je suis prêt à reexperimenter avec Perl, mais je suis conscient 
que ce serait à une place dont ses fans ne voudraient pas. Il y a quelque chose 
d’un petit peu triste, mais peut-être une lueur d’espoir: peut-être qu’on 
pourrait redéfinir une approche qui rendrait ce langage plus compréhensible et 
aimable pour des néophytes?


>> 
> 
> Ce n'est pas parce que l'on peut le faire que c'est une bonne idée ou que 
> c'est efficace. Ce genre d'opération s'écrit de manière beaucoup plus lisible 
> et plus simple dans plusieurs autres langages mieux adaptés. Et que se 
> passe-t-il si les enregistrements dans la base contiennent des BLOB en 
> binaire ? Jolie démonstration mais que l'on ne peut hélas pas généraliser.
> 
> C'est bien de savoir écrire ce genre de chose en bash, c'est aussi bien de 
> savoir lire ce code... mais il faut le maintenir. Ce n'est pas (plus) 
> vendable dans une équipe IT aujourd'hui; même le Perl ne trouve plus grâce 
> aux yeux des "agilistes" aujourd'hui. Les outils d'admin dans le domaine des 
> clusters sont écrits en Python/Go/Lua/etc. Bien ? Pas bien ? Peut-être, 
> peut-être pas... C'est juste un fait.
> 

J’aurais tendance à être d’accord. Bien que je sois parfois supris des 
aptitudes des jeunes informaticiens (et des embrasements mystiques pour vim ou 
alors Emacs…), je ne crois pas qu’ils partiraient dans de la programmation « 
dure » en bash.

En effet, ils seraient plutôt dans les langages modernes. C’est la vie, même si 
je pense qu’il y aurait de la place pour une bonne bête de somme pas trop 
ambitieuse, qui pourrait nous faire les tâches répétitives, faire une requête 
dans une base SQL, ou lire un fichier docx ou xlsx au passage.

Et pour le repoussoir, le Powershell n’est pas l’idée que je me fais d’un 
langage logique d'administration — leur système de pipes à objets c’est comme 
la défunte industrie soviétique: une fois qu’on a enfin trouvé un écrou dans le 
fatras, il faut encore chercher longtemps pour trouver le boulon qui va avec, à 
moins que la livraison ne soit prévue que dans le prochain plan quinquennal…

A ce compte, Perl n’est pas si mal…

Bonne soirée,
Laurent


___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-12 Par sujet Daniel Cordey 


On 12. 03. 18 11:06, felix wrote:


Sans oublier les languages du web: HTML (3 à 5) et CSS(>=2)!


Langages purement "descriptifs" mais que l'on ne peut pas vraiment 
considérer pour apprendre la programmation. Control-flow ?



( mais, les faire bosser sur LaTeX, pour leur rapports et présentations,
   avec des outils comme gnuplot, dotty... Cela se fait encore beaucoup
   dans les universités et est très utile pour la cohérence et la pérénité
   des documents... -> ``R'' )


Sans compter que l'on peut absolument tout faire avec ça, alors que ce 
n'est pas le cas des logiciels de traîtement de texte. Sauf que, là 
encore, on ne parle d'une "application" d'un ensemble d'outils et pas 
d'une langage de programmation. Qui penserait faire du sys admin en 
Latex ? Ce n'est pas parce que c'est possible (et illisible) que ça a un 
sens.



En effet, l'``administration'' doit concerner l'embarqué, les serveurs
et les desktops... Dans bien des cas, ``bash'' n'est pas installé, soit
pour des raisons de mémoire, soit pour des raisons de sécurité (trop
complexe).


Oui, mais de l'embarqué a souvent un système vraiment minimum et on a 
que 'sh' parfois avec quelques commandes. La tendance est à avoir plus 
de RAM et des cartes SD, mais ce n'est pas garanti et là tu n'as que 
'sh' ou des fois seulement du code compilé (Arduino). On ne peut donc 
pas généraliser et le vrai embarqué aura toujours pas mal de limites.



bash doit cependant occuper une part importante, il devient de plus en
plus un language de programmation...


C'est justement là que Perl prend le relais. Les shells (dont bash) sont 
des langages de scripting quand même limités et ne sont pas destinés à 
devenir des langages de programmation généraux. Comme préciser au début 
de cette discussion, attention à ne pas sur-utiliser bash/sh/*sh. Bash 
est un langage destiné à exécuter des commandes et a énormément de 
limitations comme langage de programmation générale (pas de calculs en 
flottant, pas de binaire, etc.)



utilisant des raccourcis permettant
par exemple une interaction bidirectionnelle avec un sous-process (voire
perl Open2 et perlipc ;)
  ...

   $ ps --sid $(ps ho sid $$) fw


Ce n'est pas parce que l'on peut le faire que c'est une bonne idée ou 
que c'est efficace. Ce genre d'opération s'écrit de manière beaucoup 
plus lisible et plus simple dans plusieurs autres langages mieux 
adaptés. Et que se passe-t-il si les enregistrements dans la base 
contiennent des BLOB en binaire ? Jolie démonstration mais que l'on ne 
peut hélas pas généraliser.


C'est bien de savoir écrire ce genre de chose en bash, c'est aussi bien 
de savoir lire ce code... mais il faut le maintenir. Ce n'est pas (plus) 
vendable dans une équipe IT aujourd'hui; même le Perl ne trouve plus 
grâce aux yeux des "agilistes" aujourd'hui. Les outils d'admin dans le 
domaine des clusters sont écrits en Python/Go/Lua/etc. Bien ? Pas bien ? 
Peut-être, peut-être pas... C'est juste un fait.


dc




___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-12 Par sujet felix 
Coucou,

Oui, je vais dire un mot:

On Sat, Mar 10, 2018 at 08:55:28AM +0100, Marc SCHAEFER wrote:
> On Sat, Mar 10, 2018 at 01:07:41AM +0100, Daniel Cordey wrote:

> 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

Sans oublier les languages du web: HTML (3 à 5) et CSS(>=2)!

( mais, les faire bosser sur LaTeX, pour leur rapports et présentations,
  avec des outils comme gnuplot, dotty... Cela se fait encore beaucoup
  dans les universités et est très utile pour la cohérence et la pérénité
  des documents... -> ``R'' )

> et pour ceux qui vont plus dans la direction "système":
> 
>- bash
Je dirais ``Shell'', avec des challenges utilisant busybox et/ou dash!

En effet, l'``administration'' doit concerner l'embarqué, les serveurs
et les desktops... Dans bien des cas, ``bash'' n'est pas installé, soit
pour des raisons de mémoire, soit pour des raisons de sécurité (trop
complexe).

bash doit cependant occuper une part importante, il devient de plus en
plus un language de programmation... utilisant des raccourcis permettant
par exemple une interaction bidirectionnelle avec un sous-process (voire
perl Open2 et perlipc ;)

Voici comment dialoguer avec un serveur mysql distant (sans port TCP),
en utilisant ssh et bash. 
  $ read tdir < <(mktemp -d)
  $ mkfifo $tdir/fifo.{out,err}
  $ ssh -f -L $tdir/mysqld.sock:/var/run/mysqld/mysqld.sock $sqlhost sleep 5
  $ exec 5> >(exec stdbuf -oL -eL mysql -S $tdir/mysqld.sock -p'myPassword' \
  database >$tdir/fifo.out 2>$tdir/fifo.err )
  $ exec 6<$tdir/fifo.out
  $ exec 7<$tdir/fifo.err 
  $ rm -fR $tdir

  $ echo >&5 'SELECT CURRENT_USER,CURRENT_DATE,CURRENT_TIME;'
  $ while read -t .01 -u 6 sqlout;do echo ">" $sqlout;done
  > CURRENT_USER CURRENT_DATE CURRENT_TIME
  > felix@localhost 2018-03-12 10:48:58
  $ while read -t .01 -u 6 sqlerr;do echo "E:" $sqlerr;done

  $ ps --sid $(ps ho sid $$) fw


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

Je pense, pour ma part, que PHP devient nécessaire en raison du
nombre d'applications que l'on rencontre tous azimuths.

Ne suis pas fan, bien au contraire, mais il m'a été utile de le
connaître pour debugguer des CMS installés, mais égallement pour
désosser des ``virus'' (venu du froid) qui transforment les
serveurs web en zombies...

Pour ce qui est de Perl, je dois dire que je peux ``penser'' en Perl.
Ce qui rend les scéances de ``Brainstorming'', en solo devant mon
écran, plutôt efficaces. (Ce que je pond n'est pas forcement très
lisible, heureusement, perl regorge d'outils tels que perltidy,
debug et autres critic - merci Xavier Gattuso -...)

> Il y a des gens qui utilisent Caml? :)
Il y a des gens qui utilisent LISP! J'ai même vu, en 2017, du Tcl/Tk!!

-- 
 Félix Hauri  --  http://www.f-hauri.ch
___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-10 Par sujet Daniel Cordey 

On 10. 03. 18 08:55, Marc SCHAEFER wrote:

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, c'est sans doute ce fait que je trouve perturbant, dés lors que mes 
réflexes me poussent vers le classicisme.



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


Je ne peux qu'être d'accord sur tous les points :-)

dc



___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-10 Par sujet Laurent Franceschetti 
Je suis plutôt d’accord a priori avec ce choix de langages.


> Le 10 mars 2018 à 08:55, Marc SCHAEFER  a écrit :
> 
> 
> 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? :)


Pour ceux qui veulent explorer le paradigme fonctionnel, Haskell est le langage 
qui semble aujourd’hui le mieux placé?




___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-09 Par sujet Marc SCHAEFER 
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? :)
___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-09 Par sujet Daniel Cordey 

On 09. 03. 18 23:58, Marc SCHAEFER wrote:

En fait, ce qui pose aussi problème, c'est la pollution de l'espace de
nommage.  Mais pas en Perl, du moins pas avec les modules propres de
CPAN. Chaque module a son "namespace".


Il me semble que c'est aussi le cas d'autres langages de scripting; en 
tout cas Python. Les programmes de 'lint' peuvent s'avérer utiles pour 
débusquer les flemmards :-) En général, il est possible de voir ce qui a 
été défini à l'extérieur du "namespace" (un seul niveau), mais une 
définition "intérieure" ne peut être exportée à moins de le faire 
explicitement et cette variable doit aussi avoir été instanciée 
préalablement dans le "namespace" extérieure. C'est un tout cas vrai 
pour Python et il me semble aussi en PHP (me souvient plus trop...).


Ce sont les mauvaises pratiques de ceux qui programment qui sont 
répréhensibles, pas forcément les langages.



Je pense que c'est une des forces (et un des dangers de Perl), de pouvoir
déterminer en fonction du contexte si l'on est en "liste" (tableau) ou en
scalaire.


C'est le mot "déterminer" qui me gène. On décide que... or, dans un 
langage ou tout est un objet (comme Python), l'assignation d'un objet à 
une variable va déterminer le type de cette dernière. C'est la fameuse 
opposition du "Duck Typing" par rapport à la notion de 
déclaration-définition dans les langages "static" fortement typés 
(C/C++, Java, etc.)



Perl permet de faire ça:

my $variable = appel_fonction();

ainsi que

my @variable = appel_fonction();


Je trouve que c'est troublant... à mes yeux, c'est le type retourné par 
appel_fonction() qui devrait "déterminer" quel sera le type de 
"variable". Donc, si ma fonction me retourne un scalaire ou une liste, 
ma variable aura exactement ce type là. Naturellement, le 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 déplacé l'endroit où l'erreur 
se produira.


La tendance actuelle est d'introduire plus de possibilité de contrôle en 
amont, pour éviter les erreurs à l'exécution. Ceci est bien visible avec 
les initiatives PEP de Python, comme : 
https://www.python.org/dev/peps/pep-0362/


Les langages duck-typing essayent de se rapprocher des langages à 
définition "static", et les langages essaient d'introduire de la 
souplesse :-)


Oui, Perl permet beaucoup de choses, et c'est peut-être aussi ce qui le 
rend plus difficile à maintenir, et donc moins attractif pas les temps 
qui cours.



Dans d'autres langages, il faut explicitement dire que l'on retourne un
tableau, de mémoire en PHP c'est le mot-clé list, ou alors passer par des
références ou des structures complexes.


Justement, dans un langage fortement typé il me semble plus judicieux de 
rendre la "source" comme type primaire. Si ma fonction retourne une 
liste, je dois manipuler ce qu'elle renvoie comme une liste. Décider à 
la réception des données que le type n'est pas ce que l'on veut me 
semble moins intuitif car cela peut induire en erreur. 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.


Autre exemple, prendre des bouts de tableaux:

$tableau[5] représente le 6e élément; @tableau[5..7] un sous-tableau
de 5 à 7.

D'autres langages ont des fonctions complexes pour faire la même chose,
le $ désigne un résultat scalaire et le @ un résultat liste (tableau).


Tous les langages n'ont pas forcément ces restrictions. SI je reprends 
l'exemple en Python, je peux écrire :


variable = tableau[5]
variable = tableau[5 : 20 : 2]

Où, la première ligne extrait l'objet en 5ème position de 'tableau'. Le 
type de variable sera alors celui du cinquième élément du tableau. Or, 
il se pourrait très bien que ce cinquième élément soit un... tableau, ou 
un dictionnaire, ou un fichier, etc. Je ne suis donc pas restreint  à 
prédéfinir le type de l'assignation.


Dans la deuxième ligne, on assigne à 'variable' une nouvelle liste des 
éléments de 'tableau' compris entre 5 et 20, pas pas de 2.


Il ne s'agit donc pas, à mon avis, de fonctions très complexes.


Autre exemple, en Perl, je peux écrire:

my @tableau = (@tab1, @tab2, @tab3);

et il est immédiatement évident que l'on veut concaténer le contenu des 3
tableaux. Dans certains langages on obtiendra un tableau 2D, ou une
structure complexe avec des références de tableaux.


Je reconnais là que Perl est parfaitement logique dans sa syntaxe :-) 
Remarque que je ne me souviens plus trop en PHP, mais en Python tu écrisy :


tableau = tab1 + tab2 + tab3

Pas très cryptique non-plus ?

Je reconnais que, les limitations à traiter des variables plus subtiles 
que de simples scalaires en sh

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

2018-03-09 Par sujet 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.
___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-09 Par sujet Marc SCHAEFER 
On Fri, Mar 09, 2018 at 12:47:47PM +0100, Daniel Cordey wrote:
> Oui et cette "imposition" est bien utile. Ce n'est d'ailleurs pas
> une contrainte... mais on voit des tas de programmes où des gens
> utilisent 'global' a tour de bras. Il est illusoire de croire qu'un

En fait, ce qui pose aussi problème, c'est la pollution de l'espace de
nommage.  Mais pas en Perl, du moins pas avec les modules propres de
CPAN. Chaque module a son "namespace".

> qui utilise quand même Lex & Yacc... Avec une table de symbole, on
> peut facilement faire du "scoping", détecter l'usage d'un
> symbole/variable et les instantiations... Bizarre...

Je pense que c'est une des forces (et un des dangers de Perl), de pouvoir
déterminer en fonction du contexte si l'on est en "liste" (tableau) ou en
scalaire.

Perl permet de faire ça:

my $variable = appel_fonction();

ainsi que

my @variable = appel_fonction();

Dans d'autres langages, il faut explicitement dire que l'on retourne un
tableau, de mémoire en PHP c'est le mot-clé list, ou alors passer par des
références ou des structures complexes.

Autre exemple, prendre des bouts de tableaux:

   $tableau[5] représente le 6e élément; @tableau[5..7] un sous-tableau
   de 5 à 7.

D'autres langages ont des fonctions complexes pour faire la même chose,
le $ désigne un résultat scalaire et le @ un résultat liste (tableau).

Autre exemple, en Perl, je peux écrire:

   my @tableau = (@tab1, @tab2, @tab3);

et il est immédiatement évident que l'on veut concaténer le contenu des 3
tableaux. Dans certains langages on obtiendra un tableau 2D, ou une
structure complexe avec des références de tableaux.

D'un autre côté, cela peut créer des problèmes, exemple:

# validons que le paramètre de formulaire
# colours est un entier.
my $scalar = $query->param('colours');
if ($scalar =~ /^\d+$/) {
   # BUGS
   #- si $query->param('colours') est un
   #  paramètre multi-valué, on n'aura
   #  validé que le 1er élément du tableau,
   #  alors qu'on passe le tableau entier
   #  à do_something() 
   do_something($query->param('colours'));
}

NB: j'ai exprès mis une variable scalaire temporaire, mais si on l'enlève
la sémantique est la même: dans le premier cas, quand on applique la regexp
on est en contexte scalaire et dans le deuxième en contexte liste.
___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-09 Par sujet xavier . gattuso 
En allant par là,

Le module Perl::Critic est très rigolo, surtout si vous le passez sur vos 
scripts.

https://en.wikipedia.org/wiki/Perl::Critic



March 8, 2018 1:02 PM, "Daniel Cordey"  wrote:

> On 08. 03. 18 12:25, Laurent Franceschetti wrote:
> 
>> Dans le cas de Perl, c’est cette habitude de commencer tous les programmes 
>> par 'use strict’ et ‘use
>> warnings’. Soit c’est toujours nécessaire et le langage devrait l’imposer, 
>> soit il y a des
>> exceptions de bon sens (ce qui est mon opinion). Donc, AMHA, cette 
>> recommandation de toujours
>> commencer tous les programmes par ces 2 pragmas tient de la schizophrénie. 
>> En particulier, si on
>> écrit des petits programmes où on sait ce qu’on fait, il n’y a pas de raison 
>> valable de se
>> compliquer la vie.
> 
> Je ne suis sans doute pas aussi versé dans les subtilités de Perl que
> certains sur cette liste, mais ça ne me gène pas d'être rappelé à
> l'ordre par le "langage" si je m'écarte trop des bonnes pratiques. C'est
> la raison pour laquelle j'utilise 'strict' et 'warnings' car je me dis
> que ça m'évitera certaines erreurs. Je n'ai jamais trouvé ça gênant et
> je ne vois pas, à mes yeux, de contre-indication à ces emplois. Mais...
> je serais intéressé d'avoir ton avis un peu plus détaillé à ce sujet car
> je suis persuadé que je passe à côté de quelque chose :-)
> 
> dc
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> http://forum.linux-gull.ch/mailman/listinfo/gull
___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-09 Par sujet Daniel Cordey 

On 09. 03. 18 11:34, Laurent Franceschetti wrote:


Avant que j’aille un peu plus dans le détail: au fond il y a une 
question sous-jacente: les choix de Perl avec le scope lexical des 
variables. C’est peut-être le choix de base (scoping global) qui a été 
problématique. On sait depuis longtemps que le scoping global est 
source d’erreurs. Les nouveaux langages ont des scopes locaux.


Oui et cette "imposition" est bien utile. Ce n'est d'ailleurs pas une 
contrainte... mais on voit des tas de programmes où des gens utilisent 
'global' a tour de bras. Il est illusoire de croire qu'un langage va 
pouvoir "imposer" d'écrire des programmes "propres" et élégants. Un 
programmeur non-rigoureux produira toujours du code pourri et il se peut 
que le problème soit amplifié par le langage; mais le vrai responsable 
n'est pas ce dernier. Il est aussi vrai qu'un programmeur rigoureux peut 
aussi produire du code le plus propre possible... toujours dans les 
limites de ce que le langage permet. Lorsque je lis les bouts de code de 
Marc, c'est lisible et évident immédiatement; ce n'est hélas pas le cas 
de beaucoup de codes Perl que l'on trouve sur le net. Je pense donc que 
certains langages apporte une aide efficace dans la production de code 
propre, et d'autre un peu moins... Perl est peut-être un peu trop 
permissif à mon goût.




Ce que j’ai appris avec Python, c’est le principe d’économie: ne pas 
écrire des choses évidentes. En éradicant sans pitié tout ce qui 
encombre le code (le « boiler plate » et les commentaires-pléonasmes), 
on met en relief l’essence de la pensée. Il est vrai que « my » ce 
n’est que 3 lettres (avec l’espace), mais je trouve que c’est dommage 
qu’on doive encore l’indiquer, _si ça devient auto-évident qu’il 
faudrait toujours utiliser my_.


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?


J'ai un avis, très personnel il est vrai, concernant les langages qui 
utilisent le signe '$' pour identifier ses symboles... C'est en général 
le signe que l'analyseur syntaxique est limité. C'est surprenant de voir 
ce genre d'exigence syntaxique dans un langage qui utilise quand même 
Lex & Yacc... Avec une table de symbole, on peut facilement faire du 
"scoping", détecter l'usage d'un symbole/variable et les 
instantiations... Bizarre...


dc





___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-09 Par sujet Laurent Franceschetti 



> Le 9 mars 2018 à 10:04, Marc SCHAEFER  a écrit :
> 
> Hello,
> 
> Perl laisse le choix, par exemple le code suivant:
> 
>   $ cat a.pl 
>   #! /usr/bin/perl
> 
>   my $data = "toto";
> 
> 


Avant que j’aille un peu plus dans le détail: au fond il y a une question 
sous-jacente: les choix de Perl avec le scope lexical des variables. C’est 
peut-être le choix de base (scoping global) qui a été problématique. On sait 
depuis longtemps que le scoping global est source d’erreurs. Les nouveaux 
langages ont des scopes locaux.

Ce que j’ai appris avec Python, c’est le principe d’économie: ne pas écrire des 
choses évidentes. En éradicant sans pitié tout ce qui encombre le code (le « 
boiler plate » et les commentaires-pléonasmes), on met en relief l’essence de 
la pensée. Il est vrai que « my » ce n’est que 3 lettres (avec l’espace), mais 
je trouve que c’est dommage qu’on doive encore l’indiquer, si ça devient 
auto-évident qu’il faudrait toujours utiliser my.

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?___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-09 Par sujet Marc SCHAEFER 
> # see qw/DBIx::Class::Schema::Loader
> use base qw/DBIx::Class::Schema::Loader/;

bel exemple de commentaire inutile, vu que
l'on sait que toutes les classes Perl sont
dans le man:

   $ man DBIx::Class::Schema::Loader
   DBIx::Class::Schema::LUserrContributed Perl 
DoDBIx::Class::Schema::Loader(3pm)
   
   NAME
  DBIx::Class::Schema::Loader - Create a DBIx::Class::Schema based on a
  database
   
   SYNOPSIS
### use this module to generate a set of class files
   [ ... ]
___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-09 Par sujet Marc SCHAEFER 
Hello,

Perl laisse le choix, par exemple le code suivant:

   $ cat a.pl 
   #! /usr/bin/perl
   
   my $data = "toto";
   
   print $date, "\n";

   $ ./a.pl 

avec les warnings:

$ perl -w a.pl 
Name "main::date" used only once: possible typo at a.pl line 5.
Use of uninitialized value $date in print at a.pl line 5.

avec use strict: 
   $ ./a.pl 
   Global symbol "$date" requires explicit package name at ./a.pl line 7.
   Execution of ./a.pl aborted due to compilation errors.

On Thu, Mar 08, 2018 at 12:25:36PM +0100, Laurent Franceschetti wrote:
> raison valable de se compliquer la vie.

man perl

   Using the "use strict" pragma ensures that all variables are properly
   declared and prevents other misuses of legacy Perl features.

   The "use warnings" pragma produces some lovely diagnostics. One can
   also use the -w flag, but its use is normally discouraged, because it
   gets applied to all executed Perl code, including that not under your
   control.

En ce qui me concerne, je trouve le risque de n'être pas informé
de ce genre d'erreurs plus grave que d'écrire 2 lignes systématiquement
dans mes scripts Perl.

Après, il y a aussi le style de programmation, comparer:

   #! /usr/bin/perl
   
   use strict;
   use warnings;
   
   my %data = ('un' => 'bla', 'deux' => 'toto');
   
   print $data{'deux'},
 $data{'uns'}, # <-- ici un warning, bien
 "\n";
   
   $data{'uns'} = 'toto'; # <-- ici pas de warning, clé 'uns' créée alors
  # que je voulais réellement mettre à jour
  # 'un'
   
   # NB: en Perl on peut aussi écrire $data{uns} sous certaines conditions,
   # mais je ne préfère pas.

avec:

   #! /usr/bin/perl
   
   use strict;
   use warnings;
   
   my $data = new data;
   
   # setters
   $data->un("new value");
   $data->deux("new value 2");
   
   # getters $obj->nom ou $obj->nom()
   print join("\n", $data->un, $data->deux(), "");
   
   # print $data->uns; # <-- ici erreur, bien (un peu comme avant)
   
   $data->uns("new value"); # <-- ici erreur, mieux qu'avant
   
   package data;
   use strict;
   use warnings;
   use parent 'Class::Accessor::Fast';
   
   BEGIN {
   __PACKAGE__->mk_accessors(qw/un deux/);
   }
   
   sub new {
  my $class = shift;
   
  return $class->SUPER::new();
   }

Après, je dois avouer que je fais rarement ce genre d'erreurs, donc j'utilise
rarement ça, d'un autre côté, avec la vue qui baisse avec l'âge ...

NB: pour de l'OO encore plus moderne, par exemple (exemple de la manpage Moose)

 package Point;
 use Moose; # automatically turns on strict and warnings

 has 'x' => (is => 'rw', isa => 'Int');
 has 'y' => (is => 'rw', isa => 'Int');

 sub clear {
 my $self = shift;
 $self->x(0);
 $self->y(0);
 }

 package Point3D;
 use Moose;

 extends 'Point';

 has 'z' => (is => 'rw', isa => 'Int');

 after 'clear' => sub {
 my $self = shift;
 $self->z(0);
 };

J'ai un peu joué avec Moose, mais ce n'est pas ma façon de
faire du Perl, c'est trop haut niveau :->

En ce qui me concerne, si j'utilise souvent du code qui fait
usage de ce genre de chose ou approchant (style l'autoparseur
de DB existante qui génère les classes ORM automatiquement,
complété ci-dessous par une requête complexe manuelle

# http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/Manual/Cookbook.pod
# 
http://stackoverflow.com/questions/8939475/dbix-and-arbitrary-sql-through-a-custom-resultsource
package get_services_complex_query;
use strict;
use warnings;
use base 'DBIx::Class::Core';

__PACKAGE__->table("dummy");

__PACKAGE__->add_columns('name');

__PACKAGE__->result_source_instance->name(\'(
   SELECT p.name
  FROM proto p, source_fetch of, source_fetch_content ofc, 
source_fetch_content_data ofcd, source o
  WHERE (p.id = ofcd.proto) AND (of.id = ofc.source_fetch) AND (of.source = 
o.id) AND (o.id = ?)
)');

1;

# generate classes at runtime from the DB schema
# see qw/DBIx::Class::Schema::Loader
package schema;
use base qw/DBIx::Class::Schema::Loader/;

__PACKAGE__->loader_options(
);

__PACKAGE__->register_class(get_services_complex_query => 
'get_services_complex_query');

1;

Qu'on utilise ensuite ainsi:

my $dbi = schema->connect($CFG::config{'dbi_dsn'},
  $CFG::config{'dbi_user'},
  $CFG::config{'dbi_pass'},
  { RaiseError => 1, AutoCommit => 1 });
my $o = $dbi->resultset('Services')->find({name => $service});

my @r = $dbi->resultset('get_services_complex_query')
->search({},
{bind => [ $o->id ]});

return map { $_->name } @r;

)

je suis plus `manuel' dans mon code Perl. Question de goût.

___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/l

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

2018-03-09 Par sujet Laurent Franceschetti 

Je suis d’accord avec toi et peut-être que je me suis pas tout à fait bien 
exprimé.

Ma remarque ne visait pas du tout l’usage de ces directives (qui ont toute leur 
raison d’être), mais ceux qui les appliquent par principe et non par utilité. 
Pour moi la forme est au service de la fonction (en mathématiques et en 
programmation, la beauté de la forme est dans son utilité…) et non le 
contraire. En dernier ressort, l’utilité doit primer la forme. J’ai eu la 
sensation distincte que certains managers, les contraintes formelles et même 
Lint pouvaient se transformer en « culte du cargo 
 » — non pas que Lint 
soit inutile (bien au contraire) mais un mauvais programme Linté ne sera jamais 
qu'un mauvais programme glorifié.

A vrai dire, je comprends pourquoi certaines entreprises donnent des 
instructions formelles contraignantes: à cause des programmeurs débutants, qui 
autrement feraient n’importe quoi. Mais peut-être qu’ils feraient mieux de 
faire comme l’Armée suisse, qui a des modalités différentes pour l’école de 
recrues et le reste de la vie militaire... 


> Le 8 mars 2018 à 13:01, Daniel Cordey  a écrit :
> 
> Je ne suis sans doute pas aussi versé dans les subtilités de Perl que 
> certains sur cette liste, mais ça ne me gène pas d'être rappelé à l'ordre par 
> le "langage" si je m'écarte trop des bonnes pratiques. C'est la raison pour 
> laquelle j'utilise 'strict' et 'warnings' car je me dis que ça m'évitera 
> certaines erreurs. Je n'ai jamais trouvé ça gênant et je ne vois pas, à mes 
> yeux, de contre-indication à ces emplois. Mais... je serais intéressé d'avoir 
> ton avis un peu plus détaillé à ce sujet car je suis persuadé que je passe à 
> côté de quelque chose :-)

___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-08 Par sujet Daniel Cordey 

On 08. 03. 18 12:25, Laurent Franceschetti wrote:

Dans le cas de Perl, c’est cette habitude de commencer tous les programmes par 
'use strict’ et ‘use warnings’. Soit c’est toujours nécessaire et le langage 
devrait l’imposer, soit il y a des exceptions de bon sens (ce qui est mon 
opinion). Donc, AMHA, cette recommandation de toujours commencer tous les 
programmes par ces 2 pragmas tient de la schizophrénie. En particulier, si on 
écrit des petits programmes où on sait ce qu’on fait, il n’y a pas de raison 
valable de se compliquer la vie.


Je ne suis sans doute pas aussi versé dans les subtilités de Perl que 
certains sur cette liste, mais ça ne me gène pas d'être rappelé à 
l'ordre par le "langage" si je m'écarte trop des bonnes pratiques. C'est 
la raison pour laquelle j'utilise 'strict' et 'warnings' car je me dis 
que ça m'évitera certaines erreurs. Je n'ai jamais trouvé ça gênant et 
je ne vois pas, à mes yeux, de contre-indication à ces emplois. Mais... 
je serais intéressé d'avoir ton avis un peu plus détaillé à ce sujet car 
je suis persuadé que je passe à côté de quelque chose :-)


dc




___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-08 Par sujet Laurent Franceschetti 
Il me vient à l’esprit un point à propos de Perl, que j’appellerais la « 
bigoterie formelle »: quand on enseigne des règles formelles d’un langage, 
qu’on est censé appliquer par coeur sans se poser de questions (et qui 
soulèvent des protestations indignées chaque fois qu’on les viole).

Dans le cas de VB, c’était la convention de Microsoft qu’il fallait mettre le 
type d’une variable dans le nom: str_name, int_age (Linus Torvalds avait dit, à 
juste titre, que c’était « braindamaged »). Si le langage permet de nommer des 
variables indépendamment du type, alors c’est dans l’esprit du langage. Si ça 
pose un problème, c’est soit une maladie imaginaire, soit le langage est mal 
fait (dans le cas de VB, c’était largement une maladie imaginaire). 

Dans le cas de Perl, c’est cette habitude de commencer tous les programmes par 
'use strict’ et ‘use warnings’. Soit c’est toujours nécessaire et le langage 
devrait l’imposer, soit il y a des exceptions de bon sens (ce qui est mon 
opinion). Donc, AMHA, cette recommandation de toujours commencer tous les 
programmes par ces 2 pragmas tient de la schizophrénie. En particulier, si on 
écrit des petits programmes où on sait ce qu’on fait, il n’y a pas de raison 
valable de se compliquer la vie.

Qu’en pensez-vous? D’accord ou pas d’accord?

Bonne journée,
Laurent







> Le 7 mars 2018 à 23:08, Laurent Franceschetti  a 
> écrit :
> 
> Chers Marc et Daniel,
> 
> C’est drôle, quand j’étais petits j’étais tombé dans la marmite de Pascal — 
> j’étais habitué aux points-virgules mais les accolades me rebutaient.
> 
> Au début Python me rebutait, parce que j’étais dérouté par l’idée de ne pas 
> avoir un « end » à la fin d’un bloc. Très vite je l’ai trouvé naturel et 
> d’ailleurs d’autres ont emboîté le pas (YAML par exemple). Sur le point de 
> Python 2 à Python 3, ça a été une grosse histoire, mais je crois qu’on peut 
> tous dire que c’est derrière nous. AMHA Python 3 est plus cohérent et plus 
> facile pour un débutant.
> 
> Les langages à accolades, j’aime toujours moyennement mais ça va; mais 
> maintenant j’oublie tout le temps les points-virgules là où il en faut…
> 
> Mais après près de 35 ans et toutes sortes de syntaxes, je me dis que ce ne 
> sont finalement que des conventions de présentation et une question 
> d’habitude et de goût. Mais qui sait, peut-être que les éditeurs de demain 
> dissocieront la syntaxe de stockage, de la présentation au programmeur; ce 
> qui fait que chaque programmeur choisira la présentation qui lui donne le 
> maximum de productivité: accolades, begin/end, indenté… tout en garantissant 
> que le code produit restera le même? On a séparé la forme du contenu depuis 
> des années avec TeX et HTML, alors pourquoi pas avec du C, Perl, Javascript 
> ou Python?
> 
> Pour ce qui est des gestionnaires de package en Python, c’est justement ce 
> que je ferais… mais il y a une multiplicité d’outils pour différents usages 
> et aussi différentes manières de travailler. C’est encore heureux que nous ne 
> sommes pas tous du même moule, autrement cela serait bien morne.
> 
> En tout cas, je continue mon expérience d’écrire à nouveau du Perl là où 
> j’aurais auparavant écrit un shell script. Les premiers essais sont 
> encourageants.
> 
> 
> 
> Cordialement,
> Laurent
> 
> 
> 
> 
> 

___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-07 Par sujet Laurent Franceschetti 
Chers Marc et Daniel,

C’est drôle, quand j’étais petits j’étais tombé dans la marmite de Pascal — 
j’étais habitué aux points-virgules mais les accolades me rebutaient.

Au début Python me rebutait, parce que j’étais dérouté par l’idée de ne pas 
avoir un « end » à la fin d’un bloc. Très vite je l’ai trouvé naturel et 
d’ailleurs d’autres ont emboîté le pas (YAML par exemple). Sur le point de 
Python 2 à Python 3, ça a été une grosse histoire, mais je crois qu’on peut 
tous dire que c’est derrière nous. AMHA Python 3 est plus cohérent et plus 
facile pour un débutant.

Les langages à accolades, j’aime toujours moyennement mais ça va; mais 
maintenant j’oublie tout le temps les points-virgules là où il en faut…

Mais après près de 35 ans et toutes sortes de syntaxes, je me dis que ce ne 
sont finalement que des conventions de présentation et une question d’habitude 
et de goût. Mais qui sait, peut-être que les éditeurs de demain dissocieront la 
syntaxe de stockage, de la présentation au programmeur; ce qui fait que chaque 
programmeur choisira la présentation qui lui donne le maximum de productivité: 
accolades, begin/end, indenté… tout en garantissant que le code produit restera 
le même? On a séparé la forme du contenu depuis des années avec TeX et HTML, 
alors pourquoi pas avec du C, Perl, Javascript ou Python?

Pour ce qui est des gestionnaires de package en Python, c’est justement ce que 
je ferais… mais il y a une multiplicité d’outils pour différents usages et 
aussi différentes manières de travailler. C’est encore heureux que nous ne 
sommes pas tous du même moule, autrement cela serait bien morne.

En tout cas, je continue mon expérience d’écrire à nouveau du Perl là où 
j’aurais auparavant écrit un shell script. Les premiers essais sont 
encourageants.



Cordialement,
Laurent









> Le 7 mars 2018 à 20:27, Daniel Cordey  a écrit :
> 
> On 07. 03. 18 19:39, Marc SCHAEFER wrote:
> 
> Salut Marc,
> 
>> python j'ai essayé, mais c'était en plein dans la migration 2.6 -> 3.x
>> et c'était un bordel incommensurable, pis je suis tombé dans les
>> langages à accolades quand j'étais petit.
>> 
> 
> Les choses se sont calmées depuis et on arrive à écrire du code très conforme 
> aux exigences de 3.* en 2.7. Le changement perçu comme radical avec 3.* fut, 
> à mon avis, une bonne chose. Plein de choses sont plus logiques et moins 
> ambiguës en 3.*. Il n'y a pas de raison à continuer à faire du code en 2.*, 
> vu que toutes les libraires existent maintenant en 3.*, sauf si l'on a pas le 
> temps de migrer un vieux code...
> 
> Moi c'était la marmite à pointeurs :-)
> 
> Comme tu le dis si bien : Si Perl avait une syntaxe un peu moins *, il aurait 
> sans doute plus de succès :-)
> 
> dc
> 
>   
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> http://forum.linux-gull.ch/mailman/listinfo/gull
> 

___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-07 Par sujet Daniel Cordey 

On 07. 03. 18 19:39, Marc SCHAEFER wrote:

Salut Marc,


python j'ai essayé, mais c'était en plein dans la migration 2.6 -> 3.x
et c'était un bordel incommensurable, pis je suis tombé dans les
langages à accolades quand j'étais petit.



Les choses se sont calmées depuis et on arrive à écrire du code très 
conforme aux exigences de 3.* en 2.7. Le changement perçu comme radical 
avec 3.* fut, à mon avis, une bonne chose. Plein de choses sont plus 
logiques et moins ambiguës en 3.*. Il n'y a pas de raison à continuer à 
faire du code en 2.*, vu que toutes les libraires existent maintenant en 
3.*, sauf si l'on a pas le temps de migrer un vieux code...


Moi c'était la marmite à pointeurs :-)

Comme tu le dis si bien : Si Perl avait une syntaxe un peu moins *, il 
aurait sans doute plus de succès :-)


dc



___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-07 Par sujet Marc SCHAEFER 
On Sun, Mar 04, 2018 at 03:50:04PM +0100, Laurent Franceschetti wrote:
> Je souhaiterais avoir votre avis sur le rôle de Perl dans notre « skill set 
> », parce que je me demande s???il mériterait peut-être qu???on l???enseigne à 
> nouveau aux programmeurs.

C'est une excellente question. A mon avis, Perl est un excellent langage
généraliste, performant. J'y fais des engins de recherche, du monitoring
system, du déploiement d'applications, du web scraping et bien sûr des
applications web. Je n'y fais pas vraiment d'administration système,
sinon un peu de collecte de données.

Perl dispose d'énormément de frameworks, a tous les outils qu'il faut.

En ce qui me concerne, je ne regrette ni d'avoir appris Perl
il y a plus de vingt ans, ni de l'utiliser aujourd'hui avec
les outils modernes qu'il propose.

Je trouve par exemple Mojolicious::Lite idéal comme framework
web simple, ou du web scraping.

Toutefois, je dois reconnaître que la syntaxe est parfois
rebuttante (quoique très logique): si Perl avait eu une syntaxe
un tout petit peu plus simple, il aurait obtenu encore plus
d'audience qu'il n'a déjà.

Toutefois, je ne partage pas l'avis d'utiliser Perl comme lanceur
de commandes systèmes: si c'est possible, le shell bash me semble
plus adapté pour ça.

En ce qui me concerne, je peste plutôt quand je vois que
certaines distributions dépendent de python pour les
paquets systèmes :)

python j'ai essayé, mais c'était en plein dans la migration 2.6 -> 3.x
et c'était un bordel incommensurable, pis je suis tombé dans les
langages à accolades quand j'étais petit.

___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-04 Par sujet Laurent Franceschetti 



> Le 5 mars 2018 à 00:25, Daniel Cordey  a écrit :
> 
> 
> 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 suis d’accord avec ce positionnement.

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

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?

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 vieil Unimog militaire 
 à 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.




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

Très adapté (la fameuse barrière des parenthèses imbriquées).


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

Oui, c’est le noeud du problème. I

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

Deux bons points

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

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.

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

Or Perl permet, pour peu que l’auteur soit renfermé sur soi ou tordu, d’écrire 
du code grotesque. Entre la poésie Perl 
 et la poésie des Vogons 
, c’est une échelle 
d’insupportabilité… Pour être juste, Perl a intro

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

2018-03-04 Par sujet 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 nomb

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

2018-03-04 Par sujet Laurent Franceschetti 
> Le 4 mars 2018 à 20:32, Daniel Cordey  a écrit :
> 
> Comme tu le dis, Perl est victime de l'arrivée d'un jeune mâle dans la meute 
> :-) Ce que tu dis au sujet des shells est très juste; il est important de ne 
> pas aller trop loin avec ! Perl a remplit le rôle d'intermédiaire pendant des 
> années et, jusqu'à il y a quelques années, il était sans conteste la 
> meilleure solution entre le shell et les langages compilés. Aujourd'hui, il 
> est bousculé par un langage qui permet de faire "plus", mais requiert aussi 
> un prix de départ un poil plus élevé, mais c'est assez relatif tout compte 
> fait.

Tu relèves un aspect essentiel, qui est le positionnement de Perl: si on le 
compare à Python, il n’a aucune chance (j’ai beaucoup aimé ta liste de points).
Mon idée centrale est que si on le compare à un script bash, alors il se défend.

> 
> De plus en plus d'outils d'administration sont réalisés en Python. Sans doute 
> parce qu'il s'interface aisément avec Gtk/Qt/etc., ou qu'il est plus puissant 
> en structure de donnée et en calcul

Je te suis tout à fait: Python c’est un factotum tout à fait adéquat pour 
l’administration système.


>  Ou parce que la nouvelle génération ne connaît pas ou n'apprend pas Perl ? 
> Je ne sais pas…
> 

C’est bien ce que je me demande… Partout sur le web, on trouve l’affirmation 
que Python fait mieux pour ce qui est programmation de haut niveau, ce qui est 
vrai. Mais quelque part, on passe à côté de l'essentiel, c’est que Perl est 
surtout un language de bas niveau.

C’est comme si on voulait comparer C à Java et que la réponse était: « ah oui, 
mais Java est plus haut niveau. » Oui mais justement, C a été correctement 
positionné comme remplaçant de l’assembleur! 

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!


> 
> 
> Voilà, c'est très perso... Je ne suis pas objectif car j'ai détesté Perl dés 
> le début et j'ai toujours réussi à en faire un minimum, me contentant de 
> jongler entre le shell et des programmes C que j'écrivais lorsque les choses 
> devenaient trop compliquées en shell (ou avaient besoin de performance). 
> L'arrivée de Python m'a comblé en tant que programmeur et je vois bien que ce 
> langage recouvre un peu les domaines où Perl fut pendant longtemps le seul 
> pour résoudre un type de problème. Les avantages de Perl s'en sont trouvés 
> remis en cause et ses limitations sans doute plus visibles.

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! 

Si on relève les défauts de Perl (avec raison), alors pourquoi les scripts 
shell ne sont-ils pas cloués au pilori? Et pourtant, si nous continuons à les 
utiliser, il doit bien y avoir une raison…

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,. 

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. 

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

> 
> Recommencer l'enseignement de Perl ? Pourquoi pas... mais à qui ? Sans doute 
> pas à la nouvelle génération, baignée de concept antinomiques :-)

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

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?

Encore merci pour ces réflexions et bonne soirée,
L.

___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull

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

2018-03-04 Par sujet Daniel Cordey 



On 04. 03. 18 15:50, Laurent Franceschetti wrote:
Je souhaiterais avoir votre avis sur le rôle de Perl dans notre 
« skill set », parce que je me demande s’il mériterait peut-être qu’on 
l’enseigne à nouveau aux programmeurs.

...
Pour moi ce ne sont pas des conclusions, mais des réflexions de 
travail (je vais faire l'expérience d’écrire mes petits scripts en 
Perl au lieu de bash). Je serais curieux d’avoir vos réactions — 
favorables ou contraires — à ce sujet?


Comme tu le dis, Perl est victime de l'arrivée d'un jeune mâle dans la 
meute :-) Ce que tu dis au sujet des shells est très juste; il est 
important de ne pas aller trop loin avec ! Perl a remplit le rôle 
d'intermédiaire pendant des années et, jusqu'à il y a quelques années, 
il était sans conteste la meilleure solution entre le shell et les 
langages compilés. Aujourd'hui, il est bousculé par un langage qui 
permet de faire "plus", mais requiert aussi un prix de départ un poil 
plus élevé, mais c'est assez relatif tout compte fait.


De plus en plus d'outils d'administration sont réalisés en Python. Sans 
doute parce qu'il s'interface aisément avec Gtk/Qt/etc., ou qu'il est 
plus puissant en structure de donnée et en calcul ? Ou parce que la 
nouvelle génération ne connaît pas ou n'apprend pas Perl ? Je ne sais pas...


Pour moi, à mon très humble avis, Perl souffre de quelques défauts dont :

- Très vite illisible, ou impossible à maintenir. Quand on reprend le 
code de quelqu'un, la lecture de chaque ligne est un effort 
non-négligeable qui fatigue très vite. A plus forte raison si le 
programme est gros...


- Un syntaxe "bricolée" pour étendre les fonctionnalités du langage avec 
les années. La proportion de caractère "spéciaux" est plus que suspecte 
à mes yeux et est là uniquement pour aider l'interpréteur, au détriment 
du programmeur.


- Perl est limité à l'usage de "strings". Ceci est valable pour toutes 
les manipulations dans Perl. Les "hash" en Perl sont utiles comme 
extension du langage, mais sont beaucoup plus limités que 
l'implémentation en Python et l'on ne peut pas se créer un objet qui 
puisse être utilisé comme clef. De plus, toutes les valeurs numériques 
étant un "string", il est difficile de faire la différence entre float 
et int, de même que vouloir agir sur la précision d'une variable lors 
des calculs est assez pénible et surtout pas performant du tout. En 
plus, cette manière de faire ralentit l'exécution du code.


- Perl est intimement lié aux regexp. C'est sans doute un atout dans 
certains cas. Mais ça rend la lecture de codes Perl assez... pénible.


- Traitement des exceptions très perfectible, ce qui rend le debugging 
particulièrement difficile et ne favorise pas l'écriture de code fiable.


- Passage de paramètres comme le shell ou C; à la différence que l'on a 
pas de notion de signature et d'analyseur statique comme en C. C'est la 
porte ouverte à de nombreux bugs souvent difficile à trouver.


Perl est un langage qui a été conçu comme une extension du shell pour 
faciliter l'écriture de scripts pour l'administration système. Il permet 
de faire mieux que le shell, mais souffre des mêmes défauts. Il est plus 
performant car il n'a pas besoin de se reposer sur des commandes du 
système, donc pas de fork/exec; et c'est sans doute son gros avantage 
par rapport au shell. Mais dans la manipulation de structure de données 
complexes, ses limitations deviennent àvidentes et ses performances sont 
moins bonnes que Python (je ne parle même pas de calculs).


Perl permet sans doute d'écrire du code plus compact que Python pour 
manipuler des fichiers, mais c'est au détriment de la lisibilité. Or, 
dans le domaine de la maintenance. la notion de lisibilité devient 
capitale, et c'est sans doute cet aspect qui rebute les nouveaux venus 
dans l'IT. Aussi, dés que l'on quitte le mode du "traitement" de 
fichier, on quitte la zone de confort de Perl et ses limitations 
commencent à peser très vite. On retombe dans le même problème que la 
"sur-utilisation" du shell dont tu parlais dans ton mail.


Voilà, c'est très perso... Je ne suis pas objectif car j'ai détesté Perl 
dés le début et j'ai toujours réussi à en faire un minimum, me 
contentant de jongler entre le shell et des programmes C que j'écrivais 
lorsque les choses devenaient trop compliquées en shell (ou avaient 
besoin de performance). L'arrivée de Python m'a comblé en tant que 
programmeur et je vois bien que ce langage recouvre un peu les domaines 
où Perl fut pendant longtemps le seul pour résoudre un type de problème. 
Les avantages de Perl s'en sont trouvés remis en cause et ses 
limitations sans doute plus visibles.


Recommencer l'enseignement de Perl ? Pourquoi pas... mais à qui ? Sans 
doute pas à la nouvelle génération, baignée de concept antinomiques :-)


dc



___
gull mailing list
gull@forum.linux-gull.ch
http://forum.linux-gull.ch/mailman/listinfo/gull