Neammoins sur le long terme il devient tres difficile de mantenir un gros programme Perl....
Quand on l'a programmé soi-même et pour peu qu'on ait un style propre et cohérent, on peut encore s'en sortir assez bien.
Évidemment, ceux qui passent derrière peuvent avoir plus de mal, mais bon, si c'est parce qu'on s'est fait viré de son boulot, on ne considère peut-être plus ça comme un inconvénient. ;-)
Bon, j'admet volontiers que si je voulais développer un projet de grande ampleur, j'envisagerais Ruby ou Python (et j'aurais du mal à choisir lequel...).
mais IMHO c'est pareil pour Python
Pas pour les unilignes : des unilignes dans un langage qui définit les blocs par l'indentation, même si ce choix ne me paraît pas mauvais par ailleurs, ça pose tout-de-suite un problème conceptuel...
En fait, un des buts avoués du concepteur de Ruby était de faire un langage qu'on puisse utiliser en lieu et place de Perl, alors que ce n'est pas un objectif de Python.
Ça explique la validité de tes arguments portant sur le langage (la question de la large disponibilité ou pas, quant à elle, ne dépend pas du langage lui-même...).
Tu peux faire des trucs marrants juste avec la distrib d'origine:
Je n'en doute pas. J'ai essayé Ruby en faisant un petit truc et je l'ai trouvé globalement génial... mais d'un autre côté, il y a quelques détails qui me gênent bien :
* L'absence de destructeurs : un langage objet dans destructeurs, c'est un peu comme un langage objet sans héritage multiple. Je suis habitué à utiliser les destructeurs pour enregistrer l'état, finalliser des traitements, etc. et ça me gêne bien qu'il n'y en ait pas. La construction la plus proche que j'ai trouvée consiste à prévoir des constructeurs acceptant en paramètre une closure définissant le traitement à effectuer et assurant eux-mêmes après celui-ci les éventuelles finalisations ou enregistrements, mais ça ne me plaît pas... D'un autre côté, Perl passant lui aussi au garbage collector avec la prochaine version 6, je crains aussi un peu ce qui pourra lui arriver de ce côté-là...
* Les end : c'est verbeux et puis, alors que l'indentation permet tout-de-suite avec Python de vérifier que les blocs sont correctement délimités, et que pour Perl ou le C/C++ n'importe quel éditeur un peu potable surlignera pour cela les paires d'accolades qui vont ensemble, la même vérification impliquera pour Python un éditeur avec un mode spécifique assez sophistiqué.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: Différence avec Python ?
Posté par Arthur Accroc . En réponse à la dépêche Sortie de Ruby 1.8.2. Évalué à 1.
Quand on l'a programmé soi-même et pour peu qu'on ait un style propre et cohérent, on peut encore s'en sortir assez bien.
Évidemment, ceux qui passent derrière peuvent avoir plus de mal, mais bon, si c'est parce qu'on s'est fait viré de son boulot, on ne considère peut-être plus ça comme un inconvénient. ;-)
Bon, j'admet volontiers que si je voulais développer un projet de grande ampleur, j'envisagerais Ruby ou Python (et j'aurais du mal à choisir lequel...).
mais IMHO c'est pareil pour Python
Pas pour les unilignes : des unilignes dans un langage qui définit les blocs par l'indentation, même si ce choix ne me paraît pas mauvais par ailleurs, ça pose tout-de-suite un problème conceptuel...
En fait, un des buts avoués du concepteur de Ruby était de faire un langage qu'on puisse utiliser en lieu et place de Perl, alors que ce n'est pas un objectif de Python.
Ça explique la validité de tes arguments portant sur le langage (la question de la large disponibilité ou pas, quant à elle, ne dépend pas du langage lui-même...).
Tu peux faire des trucs marrants juste avec la distrib d'origine:
Je n'en doute pas. J'ai essayé Ruby en faisant un petit truc et je l'ai trouvé globalement génial... mais d'un autre côté, il y a quelques détails qui me gênent bien :
* L'absence de destructeurs : un langage objet dans destructeurs, c'est un peu comme un langage objet sans héritage multiple. Je suis habitué à utiliser les destructeurs pour enregistrer l'état, finalliser des traitements, etc. et ça me gêne bien qu'il n'y en ait pas. La construction la plus proche que j'ai trouvée consiste à prévoir des constructeurs acceptant en paramètre une closure définissant le traitement à effectuer et assurant eux-mêmes après celui-ci les éventuelles finalisations ou enregistrements, mais ça ne me plaît pas... D'un autre côté, Perl passant lui aussi au garbage collector avec la prochaine version 6, je crains aussi un peu ce qui pourra lui arriver de ce côté-là...
* Les end : c'est verbeux et puis, alors que l'indentation permet tout-de-suite avec Python de vérifier que les blocs sont correctement délimités, et que pour Perl ou le C/C++ n'importe quel éditeur un peu potable surlignera pour cela les paires d'accolades qui vont ensemble, la même vérification impliquera pour Python un éditeur avec un mode spécifique assez sophistiqué.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone