Ça serait beaucoup trop beau si « plus simple = mieux ». Mais c’est généralement faux.
Tout comme « moins de lignes c’est plus simple », d’ailleurs (bonjour Perl, mais pas que).
Parce que « mieux » n’est pas défini dans l’absolu. Par exemple, farbfeld est un excellent format en terme de complexité nécessaire pour le gérer, mais devient mauvais voire catastrophique quand on réfléchit en terme de consommation (mémoire, disque, réseau).
D’une manière générale, beaucoup d’algorithmes simples (et donc peu susceptibles de bugs) sont difficiles à utiliser en conditions réelles parce qu’ils ne sont pas efficaces : trop consommateurs en calcul, en mémoire de toute sorte, en entrées/sorties... Dès que l’on a besoin d’efficacité (et quelle que soit la définition exacte que l’on donne à cette notion d’efficacité), on se retrouve souvent à devoir ajouter de la complexité, et on doit rapidement lorgner vers des techniques qui sont tout sauf triviales : parallélisation, caches, etc.
PS : en terme d’interface, « simple à utiliser » est en réalité souvent « complexe à concevoir et à coder », à la fois à cause de la masse de travail à réaliser pour comprendre ce qu’est un une interface simple pour les utilisateurs et par les automatismes à mettre en place pour y arriver.
PPS : « Simple » dans la définition qui est donnée ici, c’est aussi se couper de cas d’usages légitimes. Par exemple, farbfeld est inutilisable pour qui a besoin de gérer des métadonnes d’images, des profils colorimétriques, etc.
Par contre, je croise souvent un vrai problème de complexité inutile, dans le sens où le code a été conçu et réalisé de façon complexe sans que cette complexité soit là pour répondre à un quelconque problème.
Cela dit, de mon expérience et en entreprise, la source de cette complexité inutile n’est pas tellement la cause de « hackers qui aiment les grandes quantités de code », mais plutôt de personnes qui ne comprennent pas ce qu’elles font et qui n’en ont rien à faire. Sans comprendre le but réel de leurs développements, ces personnes empilent les couches de modifications minimales et de bidouilles ad hoc qui transforment très vite tout code en bloat infâme. Les « complexités "intelligentes" inutiles » (suringéniérie) sont, de mon expérience, beaucoup plus rare et surtout en perte de vitesse (imaginez les classiques « Java pour EntrepriseTM » avec des Factory et tout dans tous les sens).
[^] # Des idées intéressantes, mais simplistes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien farbfeld : le format d'image le plus simple du monde. Évalué à 7. Dernière modification le 23 février 2024 à 10:04.
Ça serait beaucoup trop beau si « plus simple = mieux ». Mais c’est généralement faux.
Tout comme « moins de lignes c’est plus simple », d’ailleurs (bonjour Perl, mais pas que).
Parce que « mieux » n’est pas défini dans l’absolu. Par exemple, farbfeld est un excellent format en terme de complexité nécessaire pour le gérer, mais devient mauvais voire catastrophique quand on réfléchit en terme de consommation (mémoire, disque, réseau).
D’une manière générale, beaucoup d’algorithmes simples (et donc peu susceptibles de bugs) sont difficiles à utiliser en conditions réelles parce qu’ils ne sont pas efficaces : trop consommateurs en calcul, en mémoire de toute sorte, en entrées/sorties... Dès que l’on a besoin d’efficacité (et quelle que soit la définition exacte que l’on donne à cette notion d’efficacité), on se retrouve souvent à devoir ajouter de la complexité, et on doit rapidement lorgner vers des techniques qui sont tout sauf triviales : parallélisation, caches, etc.
PS : en terme d’interface, « simple à utiliser » est en réalité souvent « complexe à concevoir et à coder », à la fois à cause de la masse de travail à réaliser pour comprendre ce qu’est un une interface simple pour les utilisateurs et par les automatismes à mettre en place pour y arriver.
PPS : « Simple » dans la définition qui est donnée ici, c’est aussi se couper de cas d’usages légitimes. Par exemple, farbfeld est inutilisable pour qui a besoin de gérer des métadonnes d’images, des profils colorimétriques, etc.
Par contre, je croise souvent un vrai problème de complexité inutile, dans le sens où le code a été conçu et réalisé de façon complexe sans que cette complexité soit là pour répondre à un quelconque problème.
Cela dit, de mon expérience et en entreprise, la source de cette complexité inutile n’est pas tellement la cause de « hackers qui aiment les grandes quantités de code », mais plutôt de personnes qui ne comprennent pas ce qu’elles font et qui n’en ont rien à faire. Sans comprendre le but réel de leurs développements, ces personnes empilent les couches de modifications minimales et de bidouilles ad hoc qui transforment très vite tout code en bloat infâme. Les « complexités "intelligentes" inutiles » (suringéniérie) sont, de mon expérience, beaucoup plus rare et surtout en perte de vitesse (imaginez les classiques « Java pour EntrepriseTM » avec des Factory et tout dans tous les sens).
La connaissance libre : https://zestedesavoir.com