Personnellement, je trouve que le langage Go est une assez bonne application du principe de Pareto : avec 20% de complexité/fonctionnalités ont obtient 80% d'expressivité.
Personnellement, j'ai rarement l'impression de souffrir d'un manque d'expressivité flagrant en programmant en Go, et pourtant je connais bien OCaml/Perl/Tcl et j'ai aussi fait du Haskell et du Lisp qui sont des langages très expressifs. La vérité, c'est que 95% du code qu'on écrit est en général plutôt trivial et n'utilise pas significativement des fonctionnalités plus avancées que celles trouvées dans Go (une boucle for ou un map ou un fold, dans 95% des cas, ça représente une charge cognitive plus ou moins identique). Pour le 5% restant (je dirais souvent moins, mais bon), qu'on fasse de façon plus ou moins élégante et verbeuse, n'a finalement que rarement de l'importance. Oui, manipuler un AST ou écrire certains algorithmes particuliers est plus facile en OCaml/Haskell, et oui, faire du SQLite avec Tcl est plus fluide, ainsi que faire des petits scripts pour manipuler des chaînes est plus rapide en Perl, mais au final, ces choses représentent rarement une partie significative d'un programme fini (il y a des exceptions, j'ai utilisé Tcl pour faire programme de flashcards, par exemple, car c'était à 90% des requêtes SQL, mais ça reste un petit programme).
Bref, toutes ces guerres pour dire que tel ou tel langage généraliste est plus ou moins expressif et/ou offre le meilleur de l'OO, du fonctionnel ou autre me laissent assez froid, car sauf aller vers le bas niveau (genre C), c'est rarement le manque de fonctionnalités du langage en soi qui va influencer significativement la productivité.
Par contre, 20% de complexité dans le langage plutôt que 100%, ça a beaucoup d'avantages : ça simplifie le compilateur (donc les temps de compilation, la création d'outils pour analyser le code, etc.); ça rend le langage plus facile à apprendre, ce qui est déjà bien en soi mais, en plus, attire une communauté plus intéressée par le résultat (ce que doit faire le programme final), plutôt que le cheminement (l'élégance du code et le perfectionnement de soi). La philosophie d'une communauté est quelque chose qui au final se voit partout, dans l'API des diverses bibliothèques, dans la documentation (faite pour le commun des mortels), etc., et ce sont des choses a priori que peu dépendantes du langage en soi et qui, pourtant, semblent être en pratique très influencées, du fait du public attiré et des divergences au niveau de ses objectifs.
# Principe de Pareto
Posté par anaseto . En réponse au journal Les 7 étapes pour devenir un programmeur Go.. Évalué à 6.
Personnellement, je trouve que le langage Go est une assez bonne application du principe de Pareto : avec 20% de complexité/fonctionnalités ont obtient 80% d'expressivité.
Personnellement, j'ai rarement l'impression de souffrir d'un manque d'expressivité flagrant en programmant en Go, et pourtant je connais bien OCaml/Perl/Tcl et j'ai aussi fait du Haskell et du Lisp qui sont des langages très expressifs. La vérité, c'est que 95% du code qu'on écrit est en général plutôt trivial et n'utilise pas significativement des fonctionnalités plus avancées que celles trouvées dans Go (une boucle for ou un
mapou unfold, dans 95% des cas, ça représente une charge cognitive plus ou moins identique). Pour le 5% restant (je dirais souvent moins, mais bon), qu'on fasse de façon plus ou moins élégante et verbeuse, n'a finalement que rarement de l'importance. Oui, manipuler un AST ou écrire certains algorithmes particuliers est plus facile en OCaml/Haskell, et oui, faire du SQLite avec Tcl est plus fluide, ainsi que faire des petits scripts pour manipuler des chaînes est plus rapide en Perl, mais au final, ces choses représentent rarement une partie significative d'un programme fini (il y a des exceptions, j'ai utilisé Tcl pour faire programme de flashcards, par exemple, car c'était à 90% des requêtes SQL, mais ça reste un petit programme).Bref, toutes ces guerres pour dire que tel ou tel langage généraliste est plus ou moins expressif et/ou offre le meilleur de l'OO, du fonctionnel ou autre me laissent assez froid, car sauf aller vers le bas niveau (genre C), c'est rarement le manque de fonctionnalités du langage en soi qui va influencer significativement la productivité.
Par contre, 20% de complexité dans le langage plutôt que 100%, ça a beaucoup d'avantages : ça simplifie le compilateur (donc les temps de compilation, la création d'outils pour analyser le code, etc.); ça rend le langage plus facile à apprendre, ce qui est déjà bien en soi mais, en plus, attire une communauté plus intéressée par le résultat (ce que doit faire le programme final), plutôt que le cheminement (l'élégance du code et le perfectionnement de soi). La philosophie d'une communauté est quelque chose qui au final se voit partout, dans l'API des diverses bibliothèques, dans la documentation (faite pour le commun des mortels), etc., et ce sont des choses a priori que peu dépendantes du langage en soi et qui, pourtant, semblent être en pratique très influencées, du fait du public attiré et des divergences au niveau de ses objectifs.