Quand à Ruby, à part le tout objet (qui a aussi ses inconvénients amha), je ne vois pas trop l'intéret par rapport à perl pour l'utilisation que j'en ai.
Avantages:
- 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).
- 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.
- 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.
- 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].
- tu peux redéfinir les opérateurs, c'est pratique, surtout pour l'opérateur de comparaison qui sert à faire des tris.
- 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.)
Inconvénients.
- Ruby on Rails, ça déchire des ours, et ça aurait été vraiment difficile à coder en Perl.
Inconvénients:
- C'est plus lent que perl, donc si ton usage principal est d'analyser des logs, par exemple, ça risque de ne pas être rentable.
- Il y a un peu moins de libs, même si j'ai presque toujours trouvé ce dont j'avais besoin tout prêt dans debian. Par contre, c'est vraiment simple de faire des extensions Ruby à partir d'une lib en C.
- Pas de "use strict" pour t'obliger à être rigoureux, même si on doit pouvoir bidouiller un truc similaire.
[^] # Re: Alternative au perl
Posté par Yusei (Mastodon) . En réponse au journal Script LCL. Évalué à 5.
Avantages:
- 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).
- 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.
- 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.
- 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].
- tu peux redéfinir les opérateurs, c'est pratique, surtout pour l'opérateur de comparaison qui sert à faire des tris.
- 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.)
Inconvénients.
- Ruby on Rails, ça déchire des ours, et ça aurait été vraiment difficile à coder en Perl.
Inconvénients:
- C'est plus lent que perl, donc si ton usage principal est d'analyser des logs, par exemple, ça risque de ne pas être rentable.
- Il y a un peu moins de libs, même si j'ai presque toujours trouvé ce dont j'avais besoin tout prêt dans debian. Par contre, c'est vraiment simple de faire des extensions Ruby à partir d'une lib en C.
- Pas de "use strict" pour t'obliger à être rigoureux, même si on doit pouvoir bidouiller un truc similaire.