Plus compact, je veux bien — et encore, pas tant que ça dès que la fonction anonyme à appliquer n'est pas triviale et ne tient pas sur une ligne.
Plus lisible, honnêtement, je suis mitigé là-dessus. D'un point de vue scientifique, la lisibilité me semble être un sujet pas évident : il ne s'agit pas de compter le nombre de caractères ou de lignes, mais la vitesse avec laquelle on les comprend, qui dépend de beaucoup de facteurs, entre autres individuels. Comme cas extrême, les langages style APL comme J permettent d'écrire des fold et des map de façon plus concise que OCaml ou Haskell, et se vantent d'être plus lisibles et productifs avec suffisamment d'entraînement. Certains allergiques au scroll vont jusqu'à essayer d'APLiser du C et soutenir qu'il s'agit là d'un style avec une longue courbe d'apprentissage mais plus lisible et moins propice aux erreurs avec de l'entraînement (si, si, il y en a qui soutiennent ça).
Personnellement, je suis assez sceptique — j'ai pas d'avis tranché, car pas assez d'habitude avec ces langages extrêmement concis pour les fonctions d'ordre supérieur (et encore, j'ai passé quand même pas mal d'heure à m'amuser avec, car c'est sympa de pouvoir écrire des algos non triviaux interactivement en repl). En vrai, j'ai quand même l'impression que pour un logiciel « normal » (disons où tout ne s'emboîte pas à coup de fold/map et avec 90% de logique simple), c'est même pas significativement plus court. Donc on met tous quelque part la barre pour un optimum de densité du code pour une meilleure lisibilité, est-ce que ça penche plutôt vers le fold/map d'OCaml ou un range de Go, ou du code à la J, je pense que ça dépend des gens, mais sauf besoin spécifique, je parie que plus de monde pencherait pour un simple range à la Go (perso, je saurais pas trop dire).
[^] # Re: Fonctionnel vs Impératif
Posté par anaseto . En réponse au lien État des lieux des langages fonctionnels. Évalué à 2.
Plus compact, je veux bien — et encore, pas tant que ça dès que la fonction anonyme à appliquer n'est pas triviale et ne tient pas sur une ligne.
Plus lisible, honnêtement, je suis mitigé là-dessus. D'un point de vue scientifique, la lisibilité me semble être un sujet pas évident : il ne s'agit pas de compter le nombre de caractères ou de lignes, mais la vitesse avec laquelle on les comprend, qui dépend de beaucoup de facteurs, entre autres individuels. Comme cas extrême, les langages style APL comme J permettent d'écrire des fold et des map de façon plus concise que OCaml ou Haskell, et se vantent d'être plus lisibles et productifs avec suffisamment d'entraînement. Certains allergiques au scroll vont jusqu'à essayer d'APLiser du C et soutenir qu'il s'agit là d'un style avec une longue courbe d'apprentissage mais plus lisible et moins propice aux erreurs avec de l'entraînement (si, si, il y en a qui soutiennent ça).
Personnellement, je suis assez sceptique — j'ai pas d'avis tranché, car pas assez d'habitude avec ces langages extrêmement concis pour les fonctions d'ordre supérieur (et encore, j'ai passé quand même pas mal d'heure à m'amuser avec, car c'est sympa de pouvoir écrire des algos non triviaux interactivement en repl). En vrai, j'ai quand même l'impression que pour un logiciel « normal » (disons où tout ne s'emboîte pas à coup de fold/map et avec 90% de logique simple), c'est même pas significativement plus court. Donc on met tous quelque part la barre pour un optimum de densité du code pour une meilleure lisibilité, est-ce que ça penche plutôt vers le fold/map d'OCaml ou un range de Go, ou du code à la J, je pense que ça dépend des gens, mais sauf besoin spécifique, je parie que plus de monde pencherait pour un simple range à la Go (perso, je saurais pas trop dire).