<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=""><div class=""><br class=""></div><div class=""><div class=""><div class=""><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 9 mars 2018 à 10:04, Marc SCHAEFER <<a href="mailto:schaefer@alphanet.ch" class="">schaefer@alphanet.ch</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello,<br class=""><br class="">Perl laisse le choix, par exemple le code suivant:<br class=""><br class=""> $ cat a.pl <br class=""> #! /usr/bin/perl<br class=""><br class=""> my $data = "toto";<br class=""><br class=""><br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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, <u class="">si ça devient auto-évident qu’il faudrait toujours utiliser my</u>.</div><div><br class=""></div><div>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?</div></div></div></div></body></html>