- c'est un langage fonctionnel, en plus d'être objet, et ça permet certaines constructions élégantes, par exemple récupérer la valeur de retour d'un "case" (équivalent du switch de C, en mieux).
C'est vrai, le switch case en perl n'existe pas en tant que tel. On peut aussi dire qu'on se debrouille tres bien sans :D
- les itérateurs, c'est vachement mieux que toutes les variantes de foreach. Je suppose qu'on doit pouvoir en ajouter à Perl, mais c'est bien quand tous les objets énumérables les ont d'office.
Moi, j'ai jamais aime les iterateurs, ca m'embrouille l'esprit, je n'arrive pas a "visualiser" ce qui se passe derriere. J'ai l'impression qu'on veut me masquer l'aspect "boucle" de la chose. Alors qu'un bon vieux foreach, ca te prend 2 lignes de plus que ton iterateur, je ne vois pas le probleme. Mais bon, ca c'est purement subjectif
- tu peux rajouter ou redéfinir des méthodes d'objets existants quand tu veux, là où en Perl tu devrais définir une fonction d'enrobage. Je prend un exemple à la con: si tu décides que tu veux logger toutes les connexions effectuées via http, il te suffit de redéfinir la méthode de connexion de la classe Net::HTTP (ou quelque chose du style) au début de ton script, et tu n'as rien à faire d'autre.
Inconvenient : ton Net::HTTP peut se retrouver dissemine dans tout ton code, apres, vazyleon pour retrouver la methode que tu veux. J'ai bon ? :D
- tu n'as pas besoin de mémoriser si ta variable est un array, un hash, un ensemble, un graphe, un arbre... pour savoir comment prendre un élément dedans, tu fais juste variable[identifiant].
Chacun son truc, moi j'aime les langages qui sont un minimum typés, ca m'interdit de faire des conneries genre vouloir acceder a la valeur d'un element d'une hash table alors que je suis dans un contexte de string. Ca me parait une contrainte importante. Encore une fois, c'est subjectif.
- tu peux redéfinir les opérateurs, c'est pratique, surtout pour l'opérateur de comparaison qui sert à faire des tris.
Je crois que perl6 devrait ajouter ce genre de fonctionnalites.
Pour ton exemple cela dit :
@articles = sort {$b cmp $a} @files;
- le controle d'accès des méthodes, ça a du bon pour les gros projets. (La philosophie de perl c'est: on n'exécute pas une fonction privée, pas parce que c'est impossible mais parce que ce n'est pas poli. En ruby c'est pas possible.)
Vrai. Y'a des moyens d'interdire reellement l'execution d'une fonction donnee, mais ca reste plus ou moins de la bidouille. C'est bien un element dommageable pour perl :)
- Ruby on Rails, ça déchire des ours, et ça aurait été vraiment difficile à coder en Perl.
C'est pas dit hein :D
Cela dit, justifier de la pertinence d'un langage par une application en particulier, je trouve ca mediocre comme argument :) Si je veux developper un module qui fait, disons, des acces a un annuaire LDAP, je m'en fiche royalement que RoR dechire des ours. Je veux que le langage que je vais utiliser me permette de faire mon script de maniere efficace, rapide, et qui reponde a mes attentes. RoR a beau etre un framework de dev web vachement classe, hype, a la mode et tout, il n'empeche que c'est pas ca qui va me faire developper un truc en Ruby. A la rigueur un truc pour le web, si je veux utiliser un framework et que le langage me plait. Mais c'est tout :)
[^] # Re: Alternative au perl
Posté par iznogoud . En réponse au journal Script LCL. Évalué à 1.
C'est vrai, le switch case en perl n'existe pas en tant que tel. On peut aussi dire qu'on se debrouille tres bien sans :D
- les itérateurs, c'est vachement mieux que toutes les variantes de foreach. Je suppose qu'on doit pouvoir en ajouter à Perl, mais c'est bien quand tous les objets énumérables les ont d'office.
Moi, j'ai jamais aime les iterateurs, ca m'embrouille l'esprit, je n'arrive pas a "visualiser" ce qui se passe derriere. J'ai l'impression qu'on veut me masquer l'aspect "boucle" de la chose. Alors qu'un bon vieux foreach, ca te prend 2 lignes de plus que ton iterateur, je ne vois pas le probleme. Mais bon, ca c'est purement subjectif
- tu peux rajouter ou redéfinir des méthodes d'objets existants quand tu veux, là où en Perl tu devrais définir une fonction d'enrobage. Je prend un exemple à la con: si tu décides que tu veux logger toutes les connexions effectuées via http, il te suffit de redéfinir la méthode de connexion de la classe Net::HTTP (ou quelque chose du style) au début de ton script, et tu n'as rien à faire d'autre.
Inconvenient : ton Net::HTTP peut se retrouver dissemine dans tout ton code, apres, vazyleon pour retrouver la methode que tu veux. J'ai bon ? :D
- tu n'as pas besoin de mémoriser si ta variable est un array, un hash, un ensemble, un graphe, un arbre... pour savoir comment prendre un élément dedans, tu fais juste variable[identifiant].
Chacun son truc, moi j'aime les langages qui sont un minimum typés, ca m'interdit de faire des conneries genre vouloir acceder a la valeur d'un element d'une hash table alors que je suis dans un contexte de string. Ca me parait une contrainte importante. Encore une fois, c'est subjectif.
- tu peux redéfinir les opérateurs, c'est pratique, surtout pour l'opérateur de comparaison qui sert à faire des tris.
Je crois que perl6 devrait ajouter ce genre de fonctionnalites.
Pour ton exemple cela dit :
- le controle d'accès des méthodes, ça a du bon pour les gros projets. (La philosophie de perl c'est: on n'exécute pas une fonction privée, pas parce que c'est impossible mais parce que ce n'est pas poli. En ruby c'est pas possible.)
Vrai. Y'a des moyens d'interdire reellement l'execution d'une fonction donnee, mais ca reste plus ou moins de la bidouille. C'est bien un element dommageable pour perl :)
- Ruby on Rails, ça déchire des ours, et ça aurait été vraiment difficile à coder en Perl.
C'est pas dit hein :D
Cela dit, justifier de la pertinence d'un langage par une application en particulier, je trouve ca mediocre comme argument :) Si je veux developper un module qui fait, disons, des acces a un annuaire LDAP, je m'en fiche royalement que RoR dechire des ours. Je veux que le langage que je vais utiliser me permette de faire mon script de maniere efficace, rapide, et qui reponde a mes attentes. RoR a beau etre un framework de dev web vachement classe, hype, a la mode et tout, il n'empeche que c'est pas ca qui va me faire developper un truc en Ruby. A la rigueur un truc pour le web, si je veux utiliser un framework et que le langage me plait. Mais c'est tout :)