La fin d'un long feuilleton et la rétrospective de quelques autres
Un historique de toutes nos réunions
-
Si le mois dernier, Laurent a évoqué le faible nombre
d'inscrits
à FPW-2010,
il évoque cette fois-ci le faible nombre de
présentations proposées.
Il y a de quoi
occuper à peine quatre heures. Même en faisant
durer la loterie, les organisateurs auront du
mal à occuper les deux journées.
Je propose de prévoir un hackathon
sur un sujet qui reste à déterminer.
L'avantage du hackathon, c'est que cela peut
facilement occuper plusieurs heures.
-
Jérôme demande pourquoi on appelle cette conférence
« les Journées Perl »
alors que Workshop
se traduit par « atelier ».
La réponse est que nous avons toujours parlé
des « Journées Perl » et que jusque-là
personne n'avait trouvé cela inadéquat.
Toujours est-il qu'en se basant sur le terme
« atelier », Jérôme a une idée assez
proche de la mienne : organiser un atelier
de programmation, à la découverte de certains
aspects de la programmation, comme les références
et les structures de données, la programmation
orientée objet et je ne sais plus quoi encore.
-
Jérôme fait une autre remarque sur la conférence.
Nous savons que cela aura lieu à
l'Université de Calais,
également appelée « Université du Littoral »
ou « Université de la Côte d'Opale »,
mais nulle part n'est indiquée l'adresse précise.
Je fais remarquer que j'ai vu quelque part une
carte de Calais mentionnant l'université.
[ C'est tout simplement la
carte Google
proposée par
Booking
dans les pages de réservation. Cela nécessite l'activation
de Javascript pour interagir avec la carte. Dans ces conditions,
en adaptant l'échelle et en déplaçant le point de vue vers
l'est, on trouve l'emplacement de l'université,
à quelques centaines de mètres de
l'hôtel Balladins.
D'accord, je ne sais pas à quel endroit il faut entrer
dans le campus,
mais j'espère le savoir en temps utile.
]
-
Laurent aura une semaine chargée en juin. Le lundi,
réunion sur IRC des Mongueurs de Perl. Mardi,
réunion sur IRC, mais cette fois pour OSDC.fr.
Mercredi, la réunion de Paris.PM
au Maldoror, jeudi déplacement de Paris
à Calais (avec, dans le cas de Laurent,
les T-shirts à trimbaler) et vendredi-samedi,
la conférence. Moi, c'est un peu pareil. Si
je ne suis pas concerné par OSDC.fr, en revanche
mon chef au boulot a fait passer un message
nous demandant de réserver la soirée du mardi.
-
Et puisque nous étions en train de parler de
OSDC.fr,
nous revenons sur un point soulevé
à l'issue de la conférence. Un participant à la conférence
s'est plaint de ce que, selon lui,
Java a fait l'objet au cours de la conférence
d'une campagne de dénigrement systématique.
Lorsque cette personne a émis ses récriminations
sur la liste Perl, il lui a été répondu
qu'elle aurait pu proposer un exposé
montrant l'intérêt de la programmation
en Java et qu'elle pourrait le faire
lors de la prochaine édition d'OSDC.fr.
-
En revanche, lors de la réunion, David nous
a fait une étude comparative de
PHP
et de Perl.
Et il sait de quoi il parle, car hélas pour lui,
son occupation présente l'amène à programmer en
PHP. Le premier point qu'il a cité, c'est le fait
qu'en Perl, toute instruction est une expression.
Vous pouvez par exemple écrire un bloc de plusieurs
instructions, encadré bien sûr par des accolades,
puis le faire précéder d'un do et
d'une affectation et le faire suivre d'un point-virgule.
Exemple :
#!/usr/bin/perl
my $fic = '0512.html';
my $nbl = do {
open my $f, $fic
or die "problème ouv $fic : $!";
1 while (<$f>);
$.;
};
print "nombre de lignes : $nbl\n";
Un autre exemple, assez voisin, concerne les
fonctions retournant une liste de valeurs.
La conversion de cette liste en tableau est
automatique, ce qui fait que l'on peut
indexer cette liste sans recourir à une variable
intermédiaire. Par exemple, pour obtenir l'heure
courante à la minute près,
#!/usr/bin/perl
printf "%02d:%02d\n", (localtime())[2, 1];
Impossible de faire cela de façon aussi simple
et succinte en PHP.
-
Une amélioration de Perl et PHP sur C, c'est
la possibilité de coder un littéral
chaîne de caractères contenant
des passages à la ligne. Le revers de la médaille
de cette puissante amélioration, c'est que si vous
oubliez la quote ou la double-quote fermante de votre
chaîne de caractères, il se produira une erreur de syntaxe
lors de l'apparition de la prochaine quote ou double-quote,
qui peut se trouver à plusieurs dizaines de lignes de là.
Lorsque cela se produit, le compilateur Perl envoie un
message pour l'erreur de syntaxe, puis ajoute un second
message d'erreur disant en substance :
Sans vouloir émettre une opinion péremptoire, j'ai l'impression
que cette erreur de syntaxe pourrait être liée au fait
qu'elle est précédée par une chaîne de caractères multi-ligne,
ce qui laisse supposer que le délimiteur fermant de cette chaîne
de caractères a pu être omis.
Mais dans PHP, rien de tel. C'est au pauvre programmeur
de deviner par lui-même qu'il s'agit d'une chaîne de caractères
sans délimiteur fermant et c'est également à lui d'identifier
ladite chaîne de caractères. Et ce cas de figure arrive
souvent à David, car il utilise un clavier américain,
où la simple-quote sert à composer les voyelles avec un accent aigu.
Donc, lorsque David presse la touche apostrophe sur son clavier,
son éditeur de texte attend la touche suivante pour
insérer un caractère. Si c'est un « e », l'éditeur
insère un « é » et si c'est un espace il insère
une apostrophe « ' ». Mais si c'est un caractère
autre qu'un espace ou une voyelle, l'apostrophe passe à la
trappe et le programme Perl ou PHP aura une erreur de syntaxe.
Pour en revenir à Perl, j'avoue
que j'avais trouvé très sympathique ce message d'erreur
supplémentaire la première fois où j'ai oublié un
délimiteur fermant pour une chaîne de caractères.
-
Un autre point que David évoque, c'est le fait qu'une
condition if (bool),
unless(bool)
ou else est toujours suivie d'un
bloc entre accolades et non pas, comme en C ou
en PHP, éventuellement d'une instruction isolée
délimitée par un simple point-virgule. Lorsque vous
utilisez une instruction simple, tout va bien jusqu'au
moment où vous vous apercevez que la situation est plus
complexe et qu'elle nécessite plusieurs instructions.
C'est alors que vous devez rajouter les accolades que
vous auriez pu écrire dès le début.
[ J'avoue que je ne vois pas vraiment d'avantage à
être obligé d'ajouter les accolades systématiquement.
Mon opinion est que c'est la rançon à payer pour d'autres
améliorations notables, je ne saurais pas dire lesquelles véritablement,
donc je ne me plains pas. ]
-
PHP n'a pas de véritable
débugueur.
Évidemment, il y
a le print habituel, mais lorsque l'on veut
quelque chose de plus puissant, avec des points
d'arrêt, des exécutions pas à pas et ainsi de suite,
il n'y a plus rien. Bon, d'un autre côté, David
estime que ce n'est pas
une bonne méthode que d'utiliser le débugueur
pour travailler sur son propre programme.
Néanmoins, comme je le fais remarquer, lorsque l'on
travaille sur le code de quelqu'un d'autre, c'est
parfois très pratique d'utiliser le débugueur.
Je l'ai constaté lorsque je me suis intéressé à
un comportement aberrant
du module calculant le lever et le coucher du soleil.
-
Un avantage notable de Perl, c'est l'expression des listes,
qu'il s'agisse pour alimenter un tableau, pour transmettre
des paramètres à un sous-programme ou pour introduire
une boucle. Il est possible de terminer la liste par une
virgule, pour être en mesure d'augmenter la liste ultérieurement
lorsque le besoin s'en fera sentir. Exemple, avec une boucle.
for (
'KAHEEEE',
'CHOMP GLORK GLURKLE CHOMP',
'FLIFFLE FLIF',
'DING DING DING DING DING DING DING DING DING DING DING DING DING DING',
'BREEBEEP',
'THOO DINK',
'FLIF FLAF FLIZAFF',
'KWAPP',
'WOOOSH',
'THWAK THWAK THWAK THWAK',
) {
say "Après ", int(2 + 10 * rand()), "minutes, on entendit ", $_;
}
Avec PHP, la virgule qui suit 'THWAK THWAK THWAK THWAK'
provoque une erreur de syntaxe. Alors qu'en Perl, elle est admise
et lorsque vous voudrez ajouter une nouvelle
onomatopée
il suffira d'insérer une nouvelle ligne sans toucher aux lignes
existantes. De même, pour changer l'ordre, quelques manipulations
élémentaires sur les lignes conviendront, y compris pour la première
et la dernière.
-
En fait, pour David, PHP a été développé sans ligne
directrice, à l'inverse de Perl dont la ligne
directrice a été établie par un linguiste.
Quand il voit le résultat obtenu, il a tendance
à penser que les core developpers
de PHP n'osent pas se regarder dans une glace.
-
Jérôme a des
problèmes
avec la dernière version de
Devel::Cover,
qu'il n'arrive pas à faire fonctionner. Hélas, je n'ai
pas retenu les détails.
-
Et un autre module qui nous donne des ennuis, c'est
Perl::Critic,
qui n'aime pas les if postfixes.
Je fais remarquer que cela ne m'étonne pas
que Perl::Critic
refuse les if postfixes,
car Perl Best Practices
les refuse également, sauf pour les ruptures de séquence
avec last, continue et redo.
-
À noter une confusion que je dissipe dans ce compte-rendu.
J'ai signalé lors de la réunion que cette règle sur les structures de contrôle
postfixes avait fait l'objet d'une polémique entre
Damian Conway et ses relecteurs. En fait non, c'est
l'utilisation de unless
qui a fait l'objet d'une polémique,
Damian rejetant cette structure de contrôle, alors
que la quasi-totalité de ses relecteurs y est
attachée.
HTML 5 - CSS v3
Mongueurs de Paris, le 28 janvier 2021
Copyright © The Paris Perl Mongers, 1999-2024