De mon point de vue c’est pas tant une question d’idiome (encore que, ça l’est un peu), mais surtout une façon d’exprimer le code façon beaucoup plus robuste et concise.
La version for loop force le lecteur à garder en tête l’input, garder un œil sur la logique d’incrémentation et traduire le if/append en semantique haut niveau.
Tu peux aussi avoir des blagues, genre modifications concurrentes sur le tableau, ou autre effet de bords qui viennent foutre la grouille.
T’es obligé de transformer en compilateur pour d’abord comprendre ce que ça fait en pratique, et c’est dur de savoir ce que le programmeur voulait faire en premier lieu.
La version « fonctionnelle » supprime le bruit, se lit beaucoup plus facilement et surtout, communique l’intention de façon beaucoup plus claire. Je peux scanner le code et immédiatement voir que la liste est filtrée 2 fois.
Ah, et ça évite (ou tout du moins, réduit considérablement) les risques d’effets de bords.
Le runtime peut aussi décider de paralléliser le code s’il le veut/peut (non pas que je connaisse un seul language qui fait ça, mais il me semble que swift travaille dessus).
En gros, la logique de 99% de ces boucles for sont du genre « pour chaque élément, applique cette opération sur l’element », ce qui n’est absolument pas ce qu’exprime une boucle for «fait tourner ce bout de code compliqué de 0 à infinité de fois ». La version fonctionnelle est beaucoup plus proche de la réalité.
Ca ouvre aussi la porte à l’évaluation paresseuse. Les streams Java typiquement font ça, tu peux construire ton stream et rien ne se passe tant que t’essayes pas de le collecter.
Et là, perso, je me dis qu'utiliser des indices dans les boucles répond au problème de l'itération depuis 1792, et n'importe quel programmeur de n'importe quel langage peut comprendre une telle boucle.
Mouais. On pourrait dire la même chose à propos du if/else et des jumps assembleurs. Ou du c orienté objet. Ça marche, effectivement, c’est juste que la semantique n’est pas la.
[^] # Re: Python
Posté par groumly . En réponse au journal Découvrir Docker, Python, LLVM et Emscripten. Évalué à 2.
De mon point de vue c’est pas tant une question d’idiome (encore que, ça l’est un peu), mais surtout une façon d’exprimer le code façon beaucoup plus robuste et concise.
La version for loop force le lecteur à garder en tête l’input, garder un œil sur la logique d’incrémentation et traduire le if/append en semantique haut niveau.
Tu peux aussi avoir des blagues, genre modifications concurrentes sur le tableau, ou autre effet de bords qui viennent foutre la grouille.
T’es obligé de transformer en compilateur pour d’abord comprendre ce que ça fait en pratique, et c’est dur de savoir ce que le programmeur voulait faire en premier lieu.
La version « fonctionnelle » supprime le bruit, se lit beaucoup plus facilement et surtout, communique l’intention de façon beaucoup plus claire. Je peux scanner le code et immédiatement voir que la liste est filtrée 2 fois.
Ah, et ça évite (ou tout du moins, réduit considérablement) les risques d’effets de bords.
Le runtime peut aussi décider de paralléliser le code s’il le veut/peut (non pas que je connaisse un seul language qui fait ça, mais il me semble que swift travaille dessus).
En gros, la logique de 99% de ces boucles for sont du genre « pour chaque élément, applique cette opération sur l’element », ce qui n’est absolument pas ce qu’exprime une boucle for «fait tourner ce bout de code compliqué de 0 à infinité de fois ». La version fonctionnelle est beaucoup plus proche de la réalité.
Ca ouvre aussi la porte à l’évaluation paresseuse. Les streams Java typiquement font ça, tu peux construire ton stream et rien ne se passe tant que t’essayes pas de le collecter.
Mouais. On pourrait dire la même chose à propos du if/else et des jumps assembleurs. Ou du c orienté objet. Ça marche, effectivement, c’est juste que la semantique n’est pas la.