Discussion :

[Celelibi]

Bonjour,

Comme pour beaucoup de langages, il y a toujours quelqu'un qui vient demander "pourquoi utiliser le langage X alors que Y est plus puissant ?".
Et bien c'est pas tout à fait ma question.

Ma question serait plutôt : qu'est-ce-que perl à de plus que les autres langages ?
Je sais bien sûr que chaque langage à son utilisation ; mais qu'est-ce-qui peut ammener à choisir perl plutôt que python par exemple ?

Jusque là j'ai appris sans problèmes, le JavaScript, le PHP, le C bien que ne l'ayant jamais réellement appris, je sais faire des programmes simples.

Perl par contre me pose plus de soucis.
Notamment ceux-ci :
pourquoi avoir un if et un unless ?
Pourquoi un while et un until ?
Et puis il y a beaucoup de variables prédéfinis qui si-tu-les-connais-pas-tu-peux-pas-coder. Je veux parler par exemple de $_, $^, $|, $`, $', $/, $!, $*, $], $& (je sais pas si toutes existent, j'ai mis un peu au hasard).
Sans oublier tous ces trucs automatiques qui dépendent du contexte.
Par exemple le retour de l'exécution d'une regex sur une chaine de caractère.
Y'a aussi les paramètres de certaines fonctions qu'on peut ommetre quand il s'agit de $_.
Et aussi les parenthèses que l'on est pas obligé de mettre quand on appel une fonction.
Je pense par exemple à printf :
printf FILE "abc %s, foo %s bar", $a, $f, $b;
Il n'y a qu'un espace qui sépare le pointeur FILE du premier argument de la fonction printf ; et ça, ça me dérange.
Et sans oublier non plus les multiples syntaxes des différentes fonctions.
la fonction open a par exemple 5 syntaxes différentes :

open FILEHANDLE,EXPR
open FILEHANDLE,MODE,EXPR
open FILEHANDLE,MODE,EXPR,LIST
open FILEHANDLE,MODE,REFERENCE
open FILEHANDLE

Au millieu de tous ces "moins" du perl, j'ai du mal à voir les "plus".
Donc voilà, qu'est-ce-que le perl permet, que ne permettent pas les autres langages de scripting.

Étant sous linux, quand je dois créer un petit script, j'ai le choix entre bash, perl, python, php (et sûrement d'autres). Qu'est-ce-qui pourrait me pousser vers perl ?


Merci d'avance.

[djibril]

Bonjour,

Comme pour beaucoup de langages, il y a toujours quelqu'un qui vient demander "pourquoi utiliser le langage X alors que Y est plus puissant ?".
Et bien c'est pas tout à fait ma question.

Ma question serait plutôt : qu'est-ce-que perl à de plus que les autres langages ?
Je sais bien sûr que chaque langage à son utilisation ; mais qu'est-ce-qui peut ammener à choisir perl plutôt que python par exemple ?

Jusque là j'ai appris sans problèmes, le JavaScript, le PHP, le C bien que ne l'ayant jamais réellement appris, je sais faire des programmes simples.

bah tu lis la FAQ avec ces avantages et inconvenients.......

Perl par contre me pose plus de soucis.
Notamment ceux-ci :
pourquoi avoir un if et un unless ?

a toi de voir, tu peux ecrire ton programme en moins de lignes

Pourquoi un while et un until ?

comme la plus part des langage

Et puis il y a beaucoup de variables prédéfinis qui si-tu-les-connais-pas-tu-peux-pas-coder. Je veux parler par exemple de $_, $^, $|, $`, $', $/, $!, $*, $], $& (je sais pas si toutes existent, j'ai mis un peu au hasard).
Sans oublier tous ces trucs automatiques qui dépendent du contexte.

T'es pas obligé de les utiliser, mais elle te facilte encore plus la tache qd tu les maitrise

Je pense par exemple à printf :
printf FILE "abc %s, foo %s bar", $a, $f, $b;
Il n'y a qu'un espace qui sépare le pointeur FILE du premier argument de la fonction printf ; et ça, ça me dérange.

t'es pas obligé de coder ainsi, moi je prefere mettre des espaces et parenthese pour une meilleur visibilité du programme. T'as vraiment plusieurs maniere d'ecrire, d'ou la difficulté de lire le script de quelqu'un d'autre, mais bon, c'est aussi le cas en C, java, PHP, etc...

Et sans oublier non plus les multiples syntaxes des différentes fonctions.
la fonction open a par exemple 5 syntaxes différentes :

open FILEHANDLE,EXPR
open FILEHANDLE,MODE,EXPR
open FILEHANDLE,MODE,EXPR,LIST
open FILEHANDLE,MODE,REFERENCE
open FILEHANDLE

bah tant mieux, tu peux faire plus de trucs!!!

Au millieu de tous ces "moins" du perl, j'ai du mal à voir les "plus".
Donc voilà, qu'est-ce-que le perl permet, que ne permettent pas les autres langages de scripting.

Étant sous linux, quand je dois créer un petit script, j'ai le choix entre bash, perl, python, php (et sûrement d'autres). Qu'est-ce-qui pourrait me pousser vers perl ?

le traitement des chaines de caracteres, les regex, la multitudes de modules disponibles, bref, lis la FAQ et le post it.

Merci d'avance.

de rien

[2Eurocents]

Bonjour,

Comme il y a toujours plus dans plusieurs avis que dans un seul, je vais aussi répondre par le détail. Je vais te donner mon avis - qui ne retire rien à l'avis de djibril et qui, s'il est différent, motrera de simples différences de perception.

Ma question serait plutôt : qu'est-ce-que perl à de plus que les autres langages ?

Plein de choses !

- Une compatibilité et une portabilité "binaire". C'est un langage de script, donc interprété, donc portable, pourvu que l'on dispose de l'interpréteur sur notre plate-forme.
- Un degré de performance et de rapidité inégalé parmi les langages interprétés (proche du C compilé sur certains points).
- Une évolutivité et une modularité énorme, qui entraine une extensibilité du langage fabuleuse, grace notamment au réservoir de modules près à l'emploi que constitue le CPAN. Quelque soit le problème, s'il n'est pas totalement nouveau, il y a presque toujours une solution dans le CPAN.
- Une souplesse d'écriture et une versatilité sans pareilles. On dit toujours qu'en Perl, il y a plus d'une façon de le faire. Ainsi, chaque développeur peut choisir sa façon de coder en fonction de ce qui lui parle le mieux, ce qui est le plus efficace.

Je sais bien sûr que chaque langage à son utilisation ; mais qu'est-ce-qui peut ammener à choisir perl plutôt que python par exemple ?

Perl vs Python ... Si on voulait réveiller le troll, on dirait que Python est un langage rigide pour développeurs psycho-rigides, là où Perl est ouvert et permissif pour des programmeurs attentifs et tolérants.

Jusque là j'ai appris sans problèmes, le JavaScript, le PHP, le C bien que ne l'ayant jamais réellement appris, je sais faire des programmes simples.

Perl par contre me pose plus de soucis.

Je confesse que Perl m'a aussi posé des soucis ... plus par manque de bons documents d'apprentissage que par la difficulté du langage. J'ai du m'y reprendre à trois fois, à plusieurs années d'écart, pour m'y mettre pour de bon.

Ceci dit, PHP me pose encore de nombreux problèmes, dans ses versions 3 et 4, car il n'est pas assez consistant. La version 5 pallie ces défauts.

Notamment ceux-ci :
pourquoi avoir un if et un unless ?

Pour plus de souplesse.
Un unless est équivalent à un if not, mais beaucoup de développeurs n'aiment pas tester sur une négation, surtout quand elle porte sur une expression composée (avec des and et des or, et plein de parenthèses dans tous les sens).

Là, la structure unless apporte un sauf si supplémentaire, qui va complèter le si algorithmique.

Cette souplesse vient aussi du fait que Perl a été conçu initialement par Larry Wall, qui est linguiste de formation, pas informaticien. Du point de vue du linguiste, de nombreux idiomes de Perl sont tout à fait cohérents, même s'ils changent des habitudes des programmeurs d'autres langages.

Pourquoi un while et un until ?

Par souplesse, encore une fois ...

Et on ne va pas le reprocher à Perl, alors que de nombreux autres langages (à commencer par les BASICs, et jusqu'au C avec son while et son do/while) le font aussi.

Et puis, sémantiquement, les deux constructions sont distinctes. Dans l'une, on teste la condition a priori et dans l'autre, on la teste a posteriori.

Et puis il y a beaucoup de variables prédéfinis qui si-tu-les-connais-pas-tu-peux-pas-coder. Je veux parler par exemple de $_, $^, $|, $`, $', $/, $!, $*, $], $& (je sais pas si toutes existent, j'ai mis un peu au hasard).

Il est possible de s'en passer, et même souhaitable pour certaines d'entre elles ($`, $' et $& par exemple), mais ce n'est effectivement pas toujours facile.

Ceci dit, on en utilise que quelques unes, toujours les mêmes, et leur choix fait partie de la démarche d'apprentissage du langage. Le tout, c'est de savoir qu'il y en a plein et de savoir où chercher quand on risque d'en avoir besoin (man perlvar, par exemple)

Sans oublier tous ces trucs automatiques qui dépendent du contexte.

Encore une fois, il ne s'agit que d'une fonctionnalité apportée par la conception linguistique du langage. Il est possible de se passer de tout l'implicite de Perl et de tout spécifier explicitement.

Les programmes sont alors un peu plus lourds, moins élégants, mais il est vrai qu'il sont aussi beaucoup plus facile à appréhender alors par un débutant.

Par exemple le retour de l'exécution d'une regex sur une chaine de caractère.

Où est le problème avec ça ?

D'avantage dans l'explication que dans le concept, je crois ...

L'opérateur de mise en correspondance (match, opérateur =~) retourne une liste des motifs correspondants. Si on récupère bien cette liste dans une liste, on a les correspondances. Si on récupère cette liste dans un scalaire, on a le nombre de correspondance.

Cette différence de comportement est due au fonctionnement de l'évaluation des listes (en liste ou en scalaire), pas à l'opérateur =~.

Y'a aussi les paramètres de certaines fonctions qu'on peut ommetre quand il s'agit de $_.

Mais si cela pose problème, il reste possible de ne pas l'ommettre, voire de stocker $_ dans une variable qui nous est propre, pour ne plus avoir à supposer sur l'implicite.

Encore une fois, ces syntaxes ne sont que des raccourcis, des formes abrégées très pratiques, mais pas indispensables.

Et aussi les parenthèses que l'on est pas obligé de mettre quand on appel une fonction.
Je pense par exemple à printf :
printf FILE "abc %s, foo %s bar", $a, $f, $b;
Il n'y a qu'un espace qui sépare le pointeur FILE du premier argument de la fonction printf ; et ça, ça me dérange.

Les parenthèses, ce n'est pas un problème ... si tu veux les mettres, tu les mets, sinon, tant pis ...

Par contre, il est vrai que le print FILE "toto", "titi" est une réelle nuisance
du point de vue du séparateur des paramètres (le blanc au lieu de la virgule après le descripteur de fichiers). C'est la seule inconsistance que j'aie pu rencontrer dans Perl.

Et sans oublier non plus les multiples syntaxes des différentes fonctions.
la fonction open a par exemple 5 syntaxes différentes :

open FILEHANDLE,EXPR
open FILEHANDLE,MODE,EXPR
open FILEHANDLE,MODE,EXPR,LIST
open FILEHANDLE,MODE,REFERENCE
open FILEHANDLE

Certains langages "Modernes" se vantent de pouvoir avoir cette multiplicité ... Ils appellent ça la surcharge et considèrent que c'est une réelle souplesse de programmation

On peut en rajouter une couche, dans le sens de la multiplicité des syntaxes en rapellant que le nombre de paramètres d'un appel d'une fonction peut très fortement varier, pour peut que l'on mette certains de ces paramètres dans une liste, que l'on passe à la fonction ...

Les paramètres de fonctions sont toujours des listes de paramètres, finalement ...

Au millieu de tous ces "moins" du perl, j'ai du mal à voir les "plus".

C'est en connaissant ses faiblesse que l'on est le plus fort

Chacun de ces "moins" peut être un "plus" quand tu les connais et peut les utiliser à bon escient.

Tout cela fait partie de la démarche d'apprentissage du langage. Lors de l'apprentissage, tu poses toi-même les bornes de l'utilisation des différentes constructions, afin de pouvoir être efficace. Par la suite, tu peux repousser ces jalons en apprenant de nouvelles syntaxes et de nouvelles construction, mais cela ne remet pas en cause ton apprentissage premier.

Donc voilà, qu'est-ce-que le perl permet, que ne permettent pas les autres langages de scripting.

Étant sous linux, quand je dois créer un petit script, j'ai le choix entre bash, perl, python, php (et sûrement d'autres). Qu'est-ce-qui pourrait me pousser vers perl ?

On ne le "vend" pas comme tel, mais Perl est pour moi un des meilleurs outils de développement rapide. Un traitement de fichiers à faire, hop, 10 lignes de perl plus tard, c'est fait ...

Perl intègre, nativement, de nombreux outils qui sont externe à bash ... Quand certains de mes scripts bash se sont effondrés en performances à cause de nombreux appels à grep/awk/sed/tr/cut ou autres, une ré-écriture en PERL les a dopé au pot belge ! En plus, ils sont plus simples (plus d'enchainements de >, de |, de && et ||) et plus facile à maintenir.

Pour ce qui est de Python, ou de PHP, j'ai déjà exprimé une partie de mon point de vue, et ne souhaite pas en dire davantage pour ne pas faire ombrage aux forumeurs pratiquant ces langages - auxquels je reconnais volontiers des qualités : PHP est simple d'apprentissage, Python est très,très cohérent.


Après, PERL n'est pas forcément facile ... ça dépend de toi, et de l'effort que tu souhaites fournir pour t'y mettre.

Si tu y vas à reculons, parce qu'il faut le faire et c'est comme ça, ce n'est pas la peine (j'ai échoué pour ça les deux premières fois).

Si tu es curieux, ouvert et attentif, alors ça va être du gâteau


Je t'invite, aussi, à parcourir notre FAQ, ainsi que les documents de GLDavid sur le premier contact avec Perl ici, ici et la.

Tous ces documents sont très progressifs et devraient te permettre une autonomie assez rapide.


Bon courage.

[Jedai]

Comme mes deux prédécesseurs, je considère ces "moins" comme des "plus" puisqu'ils m'offrent plus de puissance, de liberté pour faire ce que je veux.


Il est effectivement très important de souligner que Perl a été conçu par un linguiste et que cela se retrouve dans sa structure : ce $_ que tu décrie joue exactement le même rôle que les pronoms dans les langages naturels : on l'évoque une fois, et ensuite on n'a plus besoin de rappeler explicitement ce sur quoi on travaille.
Pour un anglais (ou un anglophone correct), lire du Perl lui dit presque immédiatement ce qu'il va faire, de façon naturelle. D'où également la présence d'un "unless" beaucoup plus lisible pour un anglophone que le "if not" correspondant, etc...


Pour ce qui est des variables "bizarres", même si on peut les apprécier pour la puissance qu'elles procurent à bas coût quand on les connaît, on est pas obligé de souffrir (et de faire souffrir à un éventuel relecteur) leur noms étranges et abscons : on peut utiliser le module "English" pour qu'elles obtiennent des noms plus longs et lisibles. Je conseillerais l'emploi de ce module pour tout code un peu long et susceptible d'être réutilisé, pour un uniligne ou un script de dix lignes, les noms courts offrent une concision appréciable et peu nuisible à la lecture vu que ces scripts ne sont pas fait pour être relus ! (je soulignerais également que beaucoup de noms de ces variables apparaissent comme naturel à un scripteur shell/awk/sed). On peut également employer les modules "IO::*" qui offrent une interface objet pour les entrées/sorties, et donc des méthodes permettant d'émuler plus lisiblement certaines des variables spéciales.
Pour ce qui est de la syntaxe du "print", elle se rattache en fait à une vieille syntaxe dite "objet indirect" qui a depuis été abandonnée, mais conservée pour le print, je trouve personnellement qu'on s'y habitue très vite, mais si cela vous rebute tant, je vous invite encore une fois à utiliser les "IO::*" qui offrent une syntaxe objet plus classique.

Bon Perl et TIMTOWDI à tous !

(@ 2Eurocents > le "until" n'est pas un synonyme du do/while (dont Perl dispose également), mais se traduit par "jusqu'à ce que" et poursuit donc la boucle tant que sa condition est fausse, c'est donc le pendant du "unless" pour le "while". On le retrouve en C si mes souvenirs sont bons.)

--
Jedaï

[Jedai]

Quand à la multiplicité des formes pour une même fonction, c'est effectivement un argument de vente de tous les langages modernes (Java, C++, ...) qu'on appelle Polymorphisme. Ca permet en fait de regrouper dans une même fonction toutes les "fonctions" qui font presque la même chose. Sans le polymorphisme, tu a une multiplication de fonction qui font presque la même chose mais avec des listes de paramêtres légèrement différentes ( add_ints(), add_floats(), ... même en C on a du polymorphisme, plutôt appelé "surcharge" lorsqu'il s'agit d'opérateurs). Le polymorphisme est donc très appréciable dans la conception de bibliothèques en permettant d'offrir une interface plus réduite et plus cohérente.

Dans le cas du open() toutefois, certaines des formes ne sont là que par un soucis de compatibilité ascendante... Personellement, je n'emploie jamais la forme à deux arguments mais bien plutôt celle à trois arguments, qui offrent plus de possibilités, tout en supprimant un certain nombre de failles de sécurités et d'erreurs éventuelles.

Malheureusement, bien que j'eusse aimé pouvoir affirmer la perfection du langage Perl, je ne peux que constater ce que beaucoup ont constaté également : le poids du passé rend Perl5 plus lourd et moins puissant qu'il ne devrait l'être... Le système d'objet, bien qu'astucieux et très ouvert, est très peu pratique et souffre de nombreuses limitations qu'on ne contourne qu'au prix de contorsions douloureuses. Le système des références a brisé la cohérence du système de sigils ($, @, %) bien qu'ouvrant des voix radicalement nouvelles pour le langage. Et il y a d'autres problèmes...
Malgré tout cela, Perl reste mon langage préféré et je suis passé par le C, le C++, le Java, l'OCaMl et le Python pour en arriver là, je pense donc qu'il peut continuer à séduire bien des gens. Mais j'espère que Perl6 arrivera bientôt : Perl6 reste dans l'esprit du Perl tout en s'offrant une refonte totale, basé sur des RFCs sa syntaxe a été reprise à zéro pour offrir un langage plus cohérent, plus puissant, intégrant tous les progrès de la théorie des langages actuelle. De plus Perl6 tournera sur Parrot qui est un projet de VM (comme pour Java) à la conception moderne, dont les performances sont déjà très impressionantes et qui ambitionne de faire tourner la grande majorité des langages interprétés actuels (Python, Ruby...). Ce projet avance à grand pas et on peut déjà faire tourner du Perl6 à vitesse réduite sur une implémentation en Haskell : le Pugs. Pour expérimenter tout ça, aller voir du côté de PxPerl (qui d'ailleurs est mieux que ActivePerl pour Windows par certains côtés).
Rhaaa je le veux demain ce Perl6 !!!

--
Jedaï

[Celelibi]

En fait les autres langages que je connais, je les ai surtout appris en lisant le code des autres. Mais avec perl, au-delà de la multiplicité des façons de coder, il y a une multiplicité des syntaxes.

J'ai déjà tenté d'apprendre perl, j'ai déjà fait des petits prog, genre pour mettre un peu d'organisation dans mes 750Mo de log xchat, ou des petits scripts pour mon mrtg. Ou encore en ligne de commande avec le paramètre -exec de find.

Ce qu'il me manque surtout c'est la compréhension de la cohérence de ce langage. Car pour le moment pour moi ça ressemble plus à de l'apprentissage par coeur, chose que je me refuse à faire. Mais malheureusement quelque soit le langage peu de texte expliquent réellement la philosophie de ce langage.

Perl vs Python ... Si on voulait réveiller le troll, on dirait que Python est un langage rigide pour développeurs psycho-rigides, là où Perl est ouvert et permissif pour des programmeurs attentifs et tolérants.

Si j'ai choisi de mettre "perl" et et "python" dans la même phrase c'est pas par hasard.
J'ai lu et participé à beaucoup de troll perl/python : beaucoup de critiques, peu d'arguments (en même temps ça serait pas un troll sinon).
J'ai aussi fait exprès d'ammener la comparaison perl/python car ce sont deux langages concurrents qui jouent sur le même terrain. Ce sont deux langages de script, tous deux interprêtés (avec une phase de compilation), ils sont tous les deux intégrés par défaut à la majeur partie des distributions de linux, le code est facilement portable sous windows. Et presque tout ce qui est réalisable avec un langage est réalisable avec l'autre.


Maintenant je vais répondre à toutes vos réponses, mais dans l'ordre des sujets, et pas des personnes.


if/unless et while/until

comme la plus part des langage

Euhh non pas que je sache.
Le seul autre langage où j'ai rencontré cette structure, c'est le basic, avec ses do...loop while et do ... loop until.

Cette souplesse vient aussi du fait que Perl a été conçu initialement par Larry Wall, qui est linguiste de formation, pas informaticien.
[...]
Et puis, sémantiquement, les deux constructions sont distinctes. Dans l'une, on teste la condition a priori et dans l'autre, on la teste a posteriori.

1) Il est vrai qu'au niveau sémantique ça doit être plus cohérent.
2) Je parlais de while et non de do/while

Pour un anglais (ou un anglophone correct), lire du Perl lui dit presque immédiatement ce qu'il va faire, de façon naturelle. D'où également la présence d'un "unless" beaucoup plus lisible pour un anglophone que le "if not" correspondant, etc...

Moi je suis plutôt technophone.
C'est à dire que j'ai plutôt tendance à penser comme un ordinateur "pense". Donc deux syntaxes pour la même chose me parraissait absurde, alors que finalement ça ne l'est pas.


les variables $\, $!, $& etc...

T'es pas obligé de les utiliser, mais elle te facilte encore plus la tache qd tu les maitrise Laughing

Je ne suis certe pas obligé de les utiliser, mais je vais sûrement les rencontrer lors de la lecture d'un code un jour.

Larry Wall est un linguiste d'accord, mais même un anglophone, quand il vois $$ je doute fort qu'il le lise "process number", mais plutôt "lot of money".

retour des regex

Où est le problème avec ça ?
D'avantage dans l'explication que dans le concept, je crois ...

Le problème est que d'un point de vue informatique, je trouve absurde qu'une expression ait une valeur différente en fonction du contexte.

Cette différence de comportement est due au fonctionnement de l'évaluation des listes (en liste ou en scalaire), pas à l'opérateur =~.

Voilà qui éclairci un peu la chose.


ommission du paramètre $_

Mais si cela pose problème, il reste possible de ne pas l'ommettre, voire de stocker $_ dans une variable qui nous est propre, pour ne plus avoir à supposer sur l'implicite.

Le code n'est pas fait uniquement pour être écrit, il peut être aussi relu plusieurs mois après, et même par d'autres personnes.
Je ne suis certe pas obligé d'ommetre ce paramètre mais si certains codent comme ça, je serais bien ammené un jour à lire du code écrit de cette façon.


La syntaxe de printf

t'es pas obligé de coder ainsi, moi je prefere mettre des espaces et parenthese pour une meilleur visibilité du programme. T'as vraiment plusieurs maniere d'ecrire, d'ou la difficulté de lire le script de quelqu'un d'autre, mais bon, c'est aussi le cas en C, java, PHP, etc... Confused

Je ne suis certe, pas obliger de coder ainsi, mais encore une fois, le problème est surtout pour la lecture d'autres codes.
Remarquez qu'avec open, il y a bien une virgule après le descripteur de fichier.


Les multiples syntaxes de open

bah tant mieux, tu peux faire plus de trucs!!!

Cette réponse me semble un peu irréfléchie.
Prennons l'exemple des deux premières syntaxes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
       open FILEHANDLE,EXPR
       open FILEHANDLE,MODE,EXPR

Je ne vois pas trop ce qu'apporte la première syntaxe par rapport à la deuxième si ce n'est des failles potentielles. Car si j'ai bien compris, dans la première syntaxe le paramètre MODE est inclu dans EXPR.

Certains langages "Modernes" se vantent de pouvoir avoir cette multiplicité ... Ils appellent ça la surcharge et considèrent que c'est une réelle souplesse de programmation Wink

Oui d'accord, mais la plus part du temps ça sert à avoir une même fonction (en fait plusieurs fonction avec le même nom) que l'on peut appeller des arguments du type différents, notamment lorsque ce sont des structures.



En bref j'ai encore du chemin pour comprendre toute la cohérence de perl.

[Jedai]

Perl n'est pas cohérent, un point c'est tout !! Néanmoins ne me parle pas d'apprentissage par coeur, je n'en ai jamais été capable et pourtant je me complais dans l'emploi du Perl (même après avoir goûté et être resté attaché un temps au Python).
Je dirais que Perl a une certaine sensibilité artistique, un flou, qui le rendent mille fois plus intéressant à mes yeux qu'un python trop froid et rigide. Beaucoup de ses constructions sont "instinctives", mais on apprend souvent de nouvelles manières de faire les choses : plus élégantes, plus optimisées, etc... Il y a un noyau qui permet déjà de tout faire, et un grand nombre d'idiôme ou de méthodes qu'on apprend avec l'expérience.

Quand au problème de relecture, comme je te l'ai déjà dit, il y a un certain nombre de remèdes à appliquer, et s'il est certain qu'un gros code Perl écrit comme un porc est impossible à relire, un code respectant une présentation idoine (un minimum d'indentation, de commentaire "graphique" pour séparer les parties du fichier), bien découpé en modules, employant "strict", "warnings" et "English" et comportant des commentaires bien placés n'est pas plus difficile à lire que le code équivalent dans n'importe quel autre langage !

Perl a déjà servi à faire des gros projets, mais il est certain que cela demande une plus grande discipline que l'uniligne si l'on compte arriver à faire quelque chose, c'est ce que néglige souvent les débutants (dans tous les langages d'ailleurs...). Consulte un certain nombre de modules du CPAN et tu constateras qu'ils sont majoritairement lisibles (quand tu connais le domaine dans lequel ils travaillent).

--
Jedaï

[Jedai]

Je ne vois pas trop ce qu'apporte la première syntaxe par rapport à la deuxième si ce n'est des failles potentielles. Car si j'ai bien compris, dans la première syntaxe le paramètre MODE est inclu dans EXPR.

Tu as bien compris et si tu avais lu tout mon message tu aurais vu que j'adresse ce problème à la fin : cette première syntaxe est à proscrire et est une survivance des temps anciens de Perl, conservée pour la compatibilité ascendante.

Par contre cette syntaxe là est authentiquement différente :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

open FILEHANDLE,MODE,REFERENCE

Elle apporte d'autres possibilités.

--
Jedaï