Cet article est fade et les arguments sont mauvais. L'auteur a fait des choses très bien et publie dans un média impressionnant par ses connotations scientifiques, mais à part les anecdotes historiques qui sont toujours enrichissantes ça reste une râlerie moyenne d'un utilisateur aigri.
L'auteur râle parce qu'un paquet donné a trop de dépendances. En même temps il râle parce que certains codes sont copiés dans plein de paquets différents. C'est quoi la solution pour résoudre son deuxième problème ? Factoriser le code comme un paquet et en faire… une dépendance supplémentaire. Bonjour la contradiction.
L'écosystème logiciel est complexe. Il y a beaucoup de programmes différents, qui ont beaucoup de dépendances (pour éviter la redondance). Selon les sous-communautés, les organisations sociales, les moyens disponibles, les gens vont avoir un processus de développement structuré de façon plus ou moins rigide. Il n'y a pas une seule bonne manière de faire, mais des choses qui sont adaptées dans certaines situations et pas dans d'autres. Donc au final quand on regarde dans la nature sauvage on observe… un continuum d'états entre "la cathédrale" et "le bazaar" (modèles caricaturaux et extrêmes), avec tout au milieu. Structurer en cathédrale c'est bien pour certains usages, mais ça demande de l'énergie, et en pratique les projets évoluent en moindre effort et les gens font de leur mieux. Il est illusoire de penser qu'on pourrait magiquement, en râlant, faire passer tout le monde à un style particulier donné, ça ne résoudrait rien et ça n'est tout simplement pas la façon dont les choses se passent.
Des choses intéressantes ont été dites sur le "bloat" des logiciels modernes. Le projet STEPS du Viewpoint Research Institute, auquel participe notamment Alan Kay, essaie de concevoir le logiciel d'un ordinateur personnel en moins de 20 000 lignes de code. John Regehr dit des choses intéressantes sur la question ici (Can Simplicity Scale) et là (It's All About Interfaces). En comparaison, l'article de cette dépêche fait pâle figure, énumérant les jérémiades sans lien logique ou proposition constructive.
# Inepties
Posté par gasche . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 7.
Cet article est fade et les arguments sont mauvais. L'auteur a fait des choses très bien et publie dans un média impressionnant par ses connotations scientifiques, mais à part les anecdotes historiques qui sont toujours enrichissantes ça reste une râlerie moyenne d'un utilisateur aigri.
L'auteur râle parce qu'un paquet donné a trop de dépendances. En même temps il râle parce que certains codes sont copiés dans plein de paquets différents. C'est quoi la solution pour résoudre son deuxième problème ? Factoriser le code comme un paquet et en faire… une dépendance supplémentaire. Bonjour la contradiction.
L'écosystème logiciel est complexe. Il y a beaucoup de programmes différents, qui ont beaucoup de dépendances (pour éviter la redondance). Selon les sous-communautés, les organisations sociales, les moyens disponibles, les gens vont avoir un processus de développement structuré de façon plus ou moins rigide. Il n'y a pas une seule bonne manière de faire, mais des choses qui sont adaptées dans certaines situations et pas dans d'autres. Donc au final quand on regarde dans la nature sauvage on observe… un continuum d'états entre "la cathédrale" et "le bazaar" (modèles caricaturaux et extrêmes), avec tout au milieu. Structurer en cathédrale c'est bien pour certains usages, mais ça demande de l'énergie, et en pratique les projets évoluent en moindre effort et les gens font de leur mieux. Il est illusoire de penser qu'on pourrait magiquement, en râlant, faire passer tout le monde à un style particulier donné, ça ne résoudrait rien et ça n'est tout simplement pas la façon dont les choses se passent.
Des choses intéressantes ont été dites sur le "bloat" des logiciels modernes. Le projet STEPS du Viewpoint Research Institute, auquel participe notamment Alan Kay, essaie de concevoir le logiciel d'un ordinateur personnel en moins de 20 000 lignes de code. John Regehr dit des choses intéressantes sur la question ici (Can Simplicity Scale) et là (It's All About Interfaces). En comparaison, l'article de cette dépêche fait pâle figure, énumérant les jérémiades sans lien logique ou proposition constructive.