Discussion:Perl (langage)

Je me suis permis de retirer un ajout partial fait à la citation du post USENET sur fr.comp.lang.perl http://groups.google.fr/group/fr.comp.lang.perl/msg/f8e35176b2448bbb où ce meme " résumé de perl " est exposé . J'en suis certes l'auteur sur USENET mais en aucun cas, je suis celui qui a fait l'insertion sur wikipédia ( cf au thread pour vérification ).

Stefp Je pense que l'article Perl ressemble au café du commerce à cause de la section pour et contre. Par ailleurs, trop de trivia et peu d'infos utiles. Maddingue et moi modifions progressivement l'article. Nous voulons laisser le lecteur juger pour lui-même des pour et des contre.

La section pour et contre devrait à terme disparaître.

On peut par contre rajouter qq liens vers des avis pour et contre correctement motivés.

D'autre part, l'article est alourdi par beaucoup de trivia qui peut être déplacé dans une section idoine.

Opinions

Perl suscite de forts sentiments aussi bien chez ses partisans que chez ses détracteurs.

Pour

Les programmeurs qui aiment Perl font typiquement référence à sa puissance, son caractère explicite et sa facilité d'utilisation. Perl offre une infrastructure pour la plupart des tâches courantes de programmation, telles que les chaînes et le traîtement des listes. D'autres tâches, telles que la gestion de la mémoire, sont prises en charge automatiquement et en toute transparence. Les programmeurs issus d'autres langages que Perl trouvent souvent que tous les problèmes auxquels ils s'étaient trouvés confrontés par le passé ne surviennent plus avec Perl. Ainsi Larry Wall le résuma :

Quelle est la sonorité de Perl ? N'est-ce pas le son d'un mur contre lequel les gens ont cessé de se taper la tête ?

En sus de ces bénéfices pratiques, un certain nombre de programmeurs semblent tout simplement apprécier de travailler avec Perl. Les premiers numéros de The Perl Journal comportaient une page intitulée « Qu'est-ce que Perl ? », qui concluait ainsi :

Perl est amusant. En ces jours de jargon d'auto-satisfécit, de standards imprévisibles et conflictuels, et de systèmes propriétaires qui découragent toute volonté de voir plus loin que le bout de son nez, les gens ont oublié que la programmation est supposée être amusante. Je ne veux pas dire par là la satisfaction de voir nos beaux programmes fonctionner comme ils le devraient, mais l'acte littéraire d'écriture créative qui constitue ces programmes. Avec Perl, le voyage est aussi agréable que la destination…

Quelles que soient les raisons, il existe clairement une vaste communauté de personnes passionnées par Perl, ce que démontrent les milliers de modules qui constituent le CPAN, et les centaines de propositions formelles qui ont été proposées comme RFC pour Perl 6.

Contre

• Les puristes moyens de l'OO ne considèrent pas Perl comme un « vrai » langage objet.
• Les puristes stricts, eux, ne considèrent aucun langage autre que Smalltalk ou Common Lisp, où tout est objet, comme « vrais » langages objet.

Une des plaintes récurrentes est la laideur de Perl. En particulier, son usage prodigue de la ponctuation qui laisse certaines personnes au bord du chemin. Le code source de Perl est parfois comparé à du bruit blanc.

Dans The Python Paradox, Paul Graham le reconnait mais apporte également une réponse :

Lorsque l'on parle d'un code source particulièrement laid, les gens penseront bien sûr à Perl. Mais la laideur superficielle de Perl n'est pas ce que à quoi je pensais. La vraie laideur n'est pas une syntaxe difficilement lisible, mais d'avoir à développer des programmes à partir de mauvais concepts. Perl peut ressembler à un personnage de cartoon adepte des jurons, mais dans certains cas il surpasse Python sur le plan des concepts.

Une autre critique est que Perl est excessivement complexe et compact, et que ceci conduit à un code à écriture seule, dans le sens où il serait virtuellement impossible à comprendre après avoir été écrit. Il est bien entendu possible d'écrire du code obscur dans n'importe quel langage, mais Perl comporte peut-être plus de constructions linguistiques condensées et complexes pour exacerber ce problème. Perl supporte beaucoup de fonctionnalités nécessaires à une rétro-compatibilité, et pour les situations où la maintenance du code n'est pas un enjeu, telles que pour les programmes qui sont entrés directement depuis la ligne de commande.

La liberté de style qui sied à certains programmeurs Perl concerne et rebute certains autres. Par exemple, le modèle objet de Perl 5 n'impose pas la sécurité des données : l'accès aux données privées est seulement restreint par convention, et non par le langage lui-même. Un objet créé en un lieu donné peut facilement être modifié ailleurs : il n'y a ainsi pas une seule et unique place où son état est définitivement établi. Il existe des techniques pour pallier ce manque, mais elles ne sont issues du langage lui-même et peu utilisées. Néanmoins, les développeurs de Perl 6 ont indiqué leur intention de règler cette situation.

A un tout autre niveau, un des premiers ingénieurs Unix des Bell Labs a exprimé sa surprise que n'importe qui soit en mesure de développer des applications dans un langage pour lequel aucune specification n'ait été publié. Toutefois, une spécification publiée ne serait pas d'une grande utilité si l'on considère qu'il n'existe pas plusieurs implémentations du langage Perl, comme ce peut être le cas avec C ou C++.

Perl, comme n'importe quel langage de script fondé sur le typage dynamique est plus gourmand en processeur et en mémoire qu'un langage à typage statique. Cela est dû à la gestion de métadonnées qui subsiste lors de la phase d'exécution. Le support du typage statique par Perl 6 permettra de lever ce problème.

Certains, enfin, objectent sur le fait que le code source des programmes en Perl soit généralement visible par les utilisateurs (ce qui est un avantage ou un inconvénient commun à tous les langages interprétés). Information douteuse si l'on en croit l'assertion selon laquelle, la majorité des langages "interprétés" (au moins le PHP, le Python et le Perl) sont en fait précompilés en bytecode, ce dernier étant finalement interprété par une machine virtuelle.

Folklore (sans aspect péjoratif)

Rejoignant le langage C sur ce point, les compétitions de code impénétrable sont aussi une composante majeure de la culture Perl. Les scripts JAPH (Just Another Perl Hacker, signifiant Rien d'autre qu'un autre hacker Perl) sont aussi typiques (voir [1]), tout comme les tournois de Golf (voir http://perlgolf.sourceforge.net/ ) où il s'agit de réaliser une tâche avec un programme le plus court possible.

Il a été écrit que PHP (un autre langage de script) veut dire People Hate Perl.

Perl est un des seuls (comme Prolog) langages informatiques permettant de faire de la poésie qui se compile.

Un résumé de Perl publié sur Usenet

« Perl part du principe que l'on a des noms et que l'on y associe des descriptions. Si on a besoin d'un nom, on l'ajoute et puis voilà : c'est réglé on n'en parle plus. Et pour la grammaire, c'est pareil.

« Tout le problème pour l'informaticien est que Perl aborde la programmation comme un enfant aborderait le langage :

« Quand l'enfant montre un ballon, on ne lui dit pas : « Ceci est une boule creuse dont l'écorce est composée de dérivés du pétrole raffinés par les industries pétrochimiques et moulé par une usine en Chine où le gouvernement surveille l'Internet, et qu'il a une masse 1kg, et sur la Lune son poids est moindre que sur Terre en raison de la loi de la gravitation découverte par Newton, qui a donné son nom à l'unité de poids en question. »

« Voilà ce que l'on apprend aux informaticiens, voilà ce que l'on demande à un langage de programmation : on décrit uniquement – ou au moins majoritairement.

« Voilà ce que Perl épargne à ses utilisateurs. »

Questions

on trouve dans l'article, on trouve hashage ou hash comme équivalent de tableau associatif. Tout d'abord ne devrait-on pas écrire hachage au lieu de hashage. D'autre part, l'équivalence tableau associatif/hachage est fausse au sens strict (cf par ex. wikipedia) : il faudrait au moins préciser que c'est par abus de langage ... (et, a verifier, dire que cela vient de l'implantation, dans l'interprete perl, des tableaux associatifs par des tables de hachage). Dtcube (d) 12 mai 2008 à 01:52 (CEST)

Neutralisation, références souhaitées et mise en forme

J'ai pris le temps de relire entièrement l'article, j'ai normalement supprimé tous les passages d'ordre "publicitaire". Par contre j'ai laissé les évocations des souhaits et/ou buts des développeurs du langage, j'ai juste ajouté à chaque fois "Référence souhaitée" (ces information sur la philosophie derrière le langage sont intéressantes à mon sens mais nécessite des sources solides).

J'ai remarqué de nombreux liens externes à la lecture de l'article, j'en ai passé un en référence, pour les autres je ne sais pas trop.

De manière plus générale, pour finir, il y a beaucoup de points intéressants dans cet article, mais il me semble que ça pêche un peu au niveau de la structure et que pour plusieurs parties on se résume à une énumération de caractéristiques du langage. N'étant pas un spécialiste, j'ai du mal à voir toujours le lien entre les éléments avancés et la section par exemple ; mais n'étant pas un spécialiste, je ne me suis pas permis d'y toucher (sauf dans un cas) :)

--Myos (discuter) 30 août 2013 à 03:25 (CEST)

chomp

Dans la page d'homonymie sur chomp , j'ai cité la fonction chomp de Perl.Discussion utilisateur:Romanc19s (discuter) 15 novembre 2014 à 11:52 (CET)