Dans un projet avec plusieurs developpeur de niveau differents et d'horizon differents (c'est ce qui arrive le plus souvent, tu auras rarement un ensemble de developpeurs expert en perl ), je n'utiliserai pas le perl, car sa syntaxe n'est pas assez deterministe.
Je n'utiliserais pas Perl si plusieurs développeurs ne le connait pas. Ou alors il y aurait une partie du projet en Perl, avec un ou deux experts en Perl, le reste dans un autre langage. (en général c'est aussi une bonne idée de séparer bas et haut niveau avec des langages adaptés).
Car ce langage leur donnera trop de liberté syntaxique au détriment de la clarté que je recherche. Les niveaux des developpeurs étant hétérogènes, j'aurai trop peur de perdre du temps sur des faux problèmes.
Ce sont des contraintes que tu ajoutes (faible niveau de compétence), ça n'a rien à voir avec le langage puisque lui-même n'est pas plus difficile que d'autres : seulement si tu embauches un développeur Java pour le faire faire du Perl, c'est sûr que ça va poser problème. Prend un développeur Perl, quitte à payer la formation. Si ce n'est pas possible c'est une considération matérielle indépendante du langage.
Si pour toi, un bête incrémenteur 'index' dans une boucle for est inutile, je ne sais pas quoi te dire.
Tu n'as pas d'arguments justifiant sa présence ? Parce que je ne parle que des cas où il est effectivement inutile.
La boucle for est un élément clef dans l'algorithmique. Essaie de faire l'exemple suivant avec des foreach je vais bien me marrer.
Je ne comprends pas que tu programmes (apparemment avec pas mal d'expérience) en faisant autant d'erreurs de logique dans notre discussion : il y a des tonnes de cas où on va garder un for classique, évidemment ! Il ne faut pas être extrémiste : je parle bien de n'utiliser des notations plus claires que lorsqu'elles sont possibles, effectivement plus claires, ou aident à comprendre. Il n'est évidemment pas question de chercher à transformer tout for en foreach. Il est appréciable de le faire quand on parcourt un conteneur et que l'on n'a pas besoin de l'indice ou d'un itérateur, par exemple. J'espère que tu vois en quoi ton exemple n'apporte rien : bien sûr que souvent, il faut garder la forme avec index explicite ! Parfois, mais pas tout le temps. Une grande expressivité aide à employer la tournure la plus parlante, la plus compréhensible.
[^] # Re: Java c'est bien !
Posté par M. Vandemar . En réponse au journal Java c'est bien !. Évalué à 1.
Je n'utiliserais pas Perl si plusieurs développeurs ne le connait pas. Ou alors il y aurait une partie du projet en Perl, avec un ou deux experts en Perl, le reste dans un autre langage. (en général c'est aussi une bonne idée de séparer bas et haut niveau avec des langages adaptés).
Car ce langage leur donnera trop de liberté syntaxique au détriment de la clarté que je recherche. Les niveaux des developpeurs étant hétérogènes, j'aurai trop peur de perdre du temps sur des faux problèmes.
Ce sont des contraintes que tu ajoutes (faible niveau de compétence), ça n'a rien à voir avec le langage puisque lui-même n'est pas plus difficile que d'autres : seulement si tu embauches un développeur Java pour le faire faire du Perl, c'est sûr que ça va poser problème. Prend un développeur Perl, quitte à payer la formation. Si ce n'est pas possible c'est une considération matérielle indépendante du langage.
Si pour toi, un bête incrémenteur 'index' dans une boucle for est inutile, je ne sais pas quoi te dire.
Tu n'as pas d'arguments justifiant sa présence ? Parce que je ne parle que des cas où il est effectivement inutile.
La boucle for est un élément clef dans l'algorithmique. Essaie de faire l'exemple suivant avec des foreach je vais bien me marrer.
Je ne comprends pas que tu programmes (apparemment avec pas mal d'expérience) en faisant autant d'erreurs de logique dans notre discussion : il y a des tonnes de cas où on va garder un for classique, évidemment ! Il ne faut pas être extrémiste : je parle bien de n'utiliser des notations plus claires que lorsqu'elles sont possibles, effectivement plus claires, ou aident à comprendre. Il n'est évidemment pas question de chercher à transformer tout for en foreach. Il est appréciable de le faire quand on parcourt un conteneur et que l'on n'a pas besoin de l'indice ou d'un itérateur, par exemple. J'espère que tu vois en quoi ton exemple n'apporte rien : bien sûr que souvent, il faut garder la forme avec index explicite ! Parfois, mais pas tout le temps. Une grande expressivité aide à employer la tournure la plus parlante, la plus compréhensible.