Quoi qu’il arrive, l’écosystème logiciel est complexe. Une amélioration des pratiques ne modifiera cette complexité qu’à la marge. Exemple, si tu veux faire un logiciel qui manipule la loi, ben tu te fades la complexité de la loi, et elle ne dépend pas des pratiques logicielles, elle est intrinsèque.
On peut cependant observer qu’un outillage puissant est important pour débusquer et/ou se débarrasser des bugs des programmes C - ou l’utilisation de meilleurs langages comme Rust qui permettent d’en éviter certains. Mais il faut construire un Rust.
La thèse de l’article c’est que la complexité des spec des logiciels qu’on veut écrire dépasse la capacité d’un être humain à l’appréhender. On peut être tenté de résoudre ça de manière « pratique » en limitant la complexité des programmes à quelque chose de gérable, en faisant des programmes « simples », mais c’est reporter la complexité (intrinsèque) à un niveau « supérieur » (l’interaction entre ces briques). Et c’est pas dit qu’on puisse tout le temps ramener par de simple pratique cette « complexité de niveau supérieure » à quelque chose de gérable facilement. Du coup, des outils et des pratiques pour gérer ça sont utiles.
Cela dit je suis pas certains qu’on puisse séparer outil et pratiques si facilement (non seulement on crée des outils pour s’aider à travailler de la manière qu’on veut, ex. git par Linus, mais aussi les pratiques découlent des outils qu’on utilise (ex. les design pattern ne s’implémentent pas de la même manière dans différents langages).
[^] # Re: Bof mouais pfff
Posté par thoasm . En réponse au journal [liens] Mais juste un. Évalué à 5.
Quoi qu’il arrive, l’écosystème logiciel est complexe. Une amélioration des pratiques ne modifiera cette complexité qu’à la marge. Exemple, si tu veux faire un logiciel qui manipule la loi, ben tu te fades la complexité de la loi, et elle ne dépend pas des pratiques logicielles, elle est intrinsèque.
On peut cependant observer qu’un outillage puissant est important pour débusquer et/ou se débarrasser des bugs des programmes C - ou l’utilisation de meilleurs langages comme Rust qui permettent d’en éviter certains. Mais il faut construire un Rust.
La thèse de l’article c’est que la complexité des spec des logiciels qu’on veut écrire dépasse la capacité d’un être humain à l’appréhender. On peut être tenté de résoudre ça de manière « pratique » en limitant la complexité des programmes à quelque chose de gérable, en faisant des programmes « simples », mais c’est reporter la complexité (intrinsèque) à un niveau « supérieur » (l’interaction entre ces briques). Et c’est pas dit qu’on puisse tout le temps ramener par de simple pratique cette « complexité de niveau supérieure » à quelque chose de gérable facilement. Du coup, des outils et des pratiques pour gérer ça sont utiles.
Cela dit je suis pas certains qu’on puisse séparer outil et pratiques si facilement (non seulement on crée des outils pour s’aider à travailler de la manière qu’on veut, ex. git par Linus, mais aussi les pratiques découlent des outils qu’on utilise (ex. les design pattern ne s’implémentent pas de la même manière dans différents langages).