L'article est très (vraiment très) riche d'enseignement en tous genre. Mais je ne peux m’empêcher de considérer qu'il se conclut sur un démenti, au moins partiel, de l'idée générale qui le sous tend. Si j'ai bien compris celle-ci, la grande complexité des systèmes informatiques actuelles les rends très fragiles, plus personne ne maîtrisant l'ensemble de la chaîne. Effectivement, nous ne sommes plus à l'époque de Conté reproduisant de mémoire et de génie l'ensemble de la chaîne industrielle de son temps (du minerai au fusil). Mais doit-on pour autant considérer notre technologie comme fragile ? N'a-t-elle pas dans son étendu et sa diversité compensé — au moins partiellement — la résilience qu'elle a abandonné en gagnant en complexité ? La citation de Planck, me semble partiellement indiquer que oui : les anciennes générations (de génies) s'y sentent peut-être perdues (d'où l'article), mais les nouvelles font simplement vivre un nouvel eco-système ; pas nécessairement plus fragile ; mais certainement différent et complexe.
La complexité robuste est atteinte grâce à des boites noires qui obéissent à un modèle de comportement simple.
Peu importe le module, la couche logicielle, l’application, le système informatique, la voiture, la machine à laver, la prise électrique (le summum de la boîte noire) : toute leur complexité est “cachée” derrière une interface que l’utilisateur peu conceptualiser avec le minimum de mémoire de travail : il pourra alors se concentrer sur ce qu’il a à faire lui. La robustesse est atteinte par la très grande prévisibilité de l’interface proposée.
Or l’ergonomie générale en informatique, aussi bien celle destinée à l’utilisateur final (ihm graphique ou non) que celle destinée aux collègues (api), n’est pas au mieux de sa forme…
Une des causes est l’abandon de l’objectif de stabilité, et de normalisation le cas échéant, des interfaces. Cela devient un vrai gros problème car, dans le monde industriel (pas l’informatique moderne), il y a toujours un effort minimum de normalisation pour s’assurer que tous les acteurs d’un même domaine parlent la même langue, associée à un bagage technique commun. Il s’agit toujours d’une langue qui est une abstraction de la réalité. C’est la condition nécessaire du développement d’une expertise technique reconnue, au lieu des gate-keepers, instauration des monopole et marchés de niche.
Une autre cause, c’est le « pissage de code » sans effort de modélisation et conception en amont. C’est induit par le monde commercial/pro qui réclame de pondre du résultat facilement évaluable. Là où la conception c’est lâcher le clavier, poser le stylo et réfléchir. Difficile pour le manager pressé de savoir si son équipe est alors en train de se tourner les pouces ou pas… (avec toutes ces méthodes de travail typées « agiles », TDD, CI/CD, etc., où la primauté va à la production de “livrables” identifiables). Il fut un temps où l’informatique était encore influencée par le monde universitaire et ses méthodes académiques…
Enfin, nous avons de plus en plus affaire à des intégrateurs qui se prennent pour des codeurs. Avec des codes de plus en plus spécialisés, là où l’idée géniale de Posix, entre autres, c’est bien de produire des briques génériques dont les combinaisons exponentielle produisent des résultats spécifiques attendus (ce qui nécessite, encore une fois, un travail de modélisation et de conception). D’où de facto, les dépendances à rallonge…
J'ai failli m'arrêter au début de l'article. J'ai continué et je le regrette.
Alors que les choses étaient simples entre Makefile et éventuellement autoconf de M4, nous subissons maintenant cmake, ninja, meson, west, gradle et multitude d’autres infrastructures de compilation multiplateformes pour des langages qui tentent de remplacer le C avec des Rust ou Go, dont on ne peut espérer que le même échec que Ada quand leur utilisation est imposée [3]. Entre développeurs et utilisateurs de systèmes compatibles POSIX uniquement, le problème serait sûrement plus simple à résoudre.
Il me semble que l'auteur confond « simple » avec « ce que je connais » et préférerait n'être entouré que de gens qui pensent comme lui.
Nous pouvons commencer par nous interroger comment nous en sommes venus à programmer des ordinateurs généralistes numériques respectant l’algèbre de Bool, d’abord en fournissant les instructions à l’unité arithmétique et logique (ALU) sous forme d’opcodes déterminant la séquence de portes logiques suivie par les opérandes, et plus tard avec des langages plus abstraits que seront C, Bash, GNU Octave, Python… et j’en oublie de nombreux autres aussi éphémères qu’inutiles.
Beaucoup de mépris dans les propos de cet auteur, et pas une once d'analyse du pourquoi ces outils ont été créés, ni de quels problèmes ils voulaient résoudre. Et évidemment il ne risque pas non plus d'y avoir une tentative d'étude de l'échec de ces outil à résoudre lesdits problèmes.
pas une once d'analyse du pourquoi ces outils ont été créés, ni de quels problèmes ils voulaient résoudre.
il oppose compliqué et simple — ce en quoi il a raison — alors que ce qu'il présente est complexe, et demanderait un peu moins d'exploration du compliqué pour voir la logique simple à appliquer.
Moi, ce qui m'a fait sourire, c'est le passage sur Wordperfect que LibreOffice lit depuis longtemps (même StarOffice y arrivait…) le plus compliqué étant de retrouver une disquette 3,5" fonctionnelle…
Il me semble que l'auteur confond « simple » avec « ce que je connais » et préférerait n'être entouré que de gens qui pensent comme lui.
J'ai lu récemment un message de quelqu'un essayant de compiler cmake sur une machine des années 90. La compilation était en cours depuis 4 jours et n'était toujours pas terminée.
J'ai la même expérience avec WebKit (compile en environ une heure sur ma machine actuelle, mais sur un PC de 2014, c'est plutôt 2 jours).
On est pas vraiment dans la frugalité avec ce genre de projet.
(j'ai pas lu le reste de l'article, et les deux citations ne me donnent pas envie d'aller voir, mais il y a quand même peut-être une discussion sur le temps de compilation de cmake. Pour moi une solution est justement peut-être Rust qui compile beaucoup plus vite que C++…)
On est pas vraiment dans la frugalité avec ce genre de projet.
Oui là dessus je suis assez d'accord, mais je ne pense pas que ça se limite à la frugalité. CMake, Ninja et Rust sont des outils qui résolvent des problèmes. Ce ne sont pas juste de nouvelles versions plus jeunes et plus fraîches d'anciens outils. Et le domaine géré par WebKit est énorme. De plus CMake et WebKit sont tous les deux en C++, un langage qui ne manque pas d'opportunités pour faire les choses inefficacement même quand on a de l'expérience :)
Rust qui compile beaucoup plus vite que C++
Mmh t'es sûr de ça ? Jusqu'ici j'ai plutôt entendu l'inverse, ce qui est plutôt ce que j'imagine quand on voit Rust comme un C++ auquel on ajoute un borrow checker et d'autres outils :)
Le temps de compilation est-il une métrique pertinente ? Si webkit et cmake étaient réécrit en java, ça changerais fondamentalement les choses (le compilateur C1 de java est très rapide) ? Les temps de build viennent avec ce que l’on demande au compilateur. Les langages qui ont des macro sophistiquée comme les templates C++ ou des invariants sophistiqués comme le borrow checker). Je ne vois pas bien le rapport avec une fragilité du logiciel produit. Ou plutôt au contraire, ce temps que le compilateur passe à vérifier des propriétés sur le code c’est des erreurs en moins à l’exécution.
Plusieurs commentaires sur la seconde partie, le bazar vs la cathédrale :
Le bazar et la complexité ne sont pas lié avec le nombre de dépendances et on peut faire simple et ordonné, avec beaucoup de dépendances, seulement ce sera gros… ;
Si on estime la complexité via le nombre de dépendances, en listant les packages, ça va dépendre de la distribution, et Debian décide d'avoir une granularité plus fine, avec bien plus de package que d'autres distributions. Il aurait été préférable d'utiliser ldd avec pldd en fonction de l'usage qui est fait, en calculant la taille de la section code mappé en mémoire.
Si gcc-avr est un gros binaire static son explication ne tient pas…
Une cathédrale sert à très peu d'usage. Un bazar permet de faire bien plus de chose. Ce sont 2 choses sans rapport entre elles. Tout dépend toujours de ce que l'on veut faire, il y a bien des choses à reprocher à l'informatique d'aujourd'hui, mais compter le nombre de dépendances ne me convainc pas.
# Robustesse
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5 (+2/-0).
L'article est très (vraiment très) riche d'enseignement en tous genre. Mais je ne peux m’empêcher de considérer qu'il se conclut sur un démenti, au moins partiel, de l'idée générale qui le sous tend. Si j'ai bien compris celle-ci, la grande complexité des systèmes informatiques actuelles les rends très fragiles, plus personne ne maîtrisant l'ensemble de la chaîne. Effectivement, nous ne sommes plus à l'époque de Conté reproduisant de mémoire et de génie l'ensemble de la chaîne industrielle de son temps (du minerai au fusil). Mais doit-on pour autant considérer notre technologie comme fragile ? N'a-t-elle pas dans son étendu et sa diversité compensé — au moins partiellement — la résilience qu'elle a abandonné en gagnant en complexité ? La citation de Planck, me semble partiellement indiquer que oui : les anciennes générations (de génies) s'y sentent peut-être perdues (d'où l'article), mais les nouvelles font simplement vivre un nouvel eco-système ; pas nécessairement plus fragile ; mais certainement différent et complexe.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Robustesse
Posté par Nicolas (site web personnel) . Évalué à 10 (+10/-0).
Complexité ≠ Robustesse.
La complexité robuste est atteinte grâce à des boites noires qui obéissent à un modèle de comportement simple.
Peu importe le module, la couche logicielle, l’application, le système informatique, la voiture, la machine à laver, la prise électrique (le summum de la boîte noire) : toute leur complexité est “cachée” derrière une interface que l’utilisateur peu conceptualiser avec le minimum de mémoire de travail : il pourra alors se concentrer sur ce qu’il a à faire lui. La robustesse est atteinte par la très grande prévisibilité de l’interface proposée.
Or l’ergonomie générale en informatique, aussi bien celle destinée à l’utilisateur final (ihm graphique ou non) que celle destinée aux collègues (api), n’est pas au mieux de sa forme…
Une des causes est l’abandon de l’objectif de stabilité, et de normalisation le cas échéant, des interfaces. Cela devient un vrai gros problème car, dans le monde industriel (pas l’informatique moderne), il y a toujours un effort minimum de normalisation pour s’assurer que tous les acteurs d’un même domaine parlent la même langue, associée à un bagage technique commun. Il s’agit toujours d’une langue qui est une abstraction de la réalité. C’est la condition nécessaire du développement d’une expertise technique reconnue, au lieu des gate-keepers, instauration des monopole et marchés de niche.
Une autre cause, c’est le « pissage de code » sans effort de modélisation et conception en amont. C’est induit par le monde commercial/pro qui réclame de pondre du résultat facilement évaluable. Là où la conception c’est lâcher le clavier, poser le stylo et réfléchir. Difficile pour le manager pressé de savoir si son équipe est alors en train de se tourner les pouces ou pas… (avec toutes ces méthodes de travail typées « agiles », TDD, CI/CD, etc., où la primauté va à la production de “livrables” identifiables). Il fut un temps où l’informatique était encore influencée par le monde universitaire et ses méthodes académiques…
Enfin, nous avons de plus en plus affaire à des intégrateurs qui se prennent pour des codeurs. Avec des codes de plus en plus spécialisés, là où l’idée géniale de Posix, entre autres, c’est bien de produire des briques génériques dont les combinaisons exponentielle produisent des résultats spécifiques attendus (ce qui nécessite, encore une fois, un travail de modélisation et de conception). D’où de facto, les dépendances à rallonge…
# Est-ce un troll ?
Posté par Julien Jorge (site web personnel) . Évalué à 10 (+11/-1).
J'ai failli m'arrêter au début de l'article. J'ai continué et je le regrette.
Il me semble que l'auteur confond « simple » avec « ce que je connais » et préférerait n'être entouré que de gens qui pensent comme lui.
Beaucoup de mépris dans les propos de cet auteur, et pas une once d'analyse du pourquoi ces outils ont été créés, ni de quels problèmes ils voulaient résoudre. Et évidemment il ne risque pas non plus d'y avoir une tentative d'étude de l'échec de ces outil à résoudre lesdits problèmes.
[^] # Re: Est-ce un troll ?
Posté par BAud (site web personnel) . Évalué à 5 (+3/-0).
Non, c'est un Normalien :p
il oppose compliqué et simple — ce en quoi il a raison — alors que ce qu'il présente est complexe, et demanderait un peu moins d'exploration du compliqué pour voir la logique simple à appliquer.
Moi, ce qui m'a fait sourire, c'est le passage sur Wordperfect que LibreOffice lit depuis longtemps (même StarOffice y arrivait…) le plus compliqué étant de retrouver une disquette 3,5" fonctionnelle…
[^] # Re: Est-ce un troll ?
Posté par YBoy360 (site web personnel) . Évalué à 2 (+1/-1).
Normalien, pour l'informatique, bof … J'en connais qui passe 100 % de leur temps sur Reddit hein.
I use Arch BTW
[^] # Re: Est-ce un troll ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
J'ai lu récemment un message de quelqu'un essayant de compiler cmake sur une machine des années 90. La compilation était en cours depuis 4 jours et n'était toujours pas terminée.
J'ai la même expérience avec WebKit (compile en environ une heure sur ma machine actuelle, mais sur un PC de 2014, c'est plutôt 2 jours).
On est pas vraiment dans la frugalité avec ce genre de projet.
(j'ai pas lu le reste de l'article, et les deux citations ne me donnent pas envie d'aller voir, mais il y a quand même peut-être une discussion sur le temps de compilation de cmake. Pour moi une solution est justement peut-être Rust qui compile beaucoup plus vite que C++…)
[^] # Re: Est-ce un troll ?
Posté par Julien Jorge (site web personnel) . Évalué à 3 (+1/-0).
Oui là dessus je suis assez d'accord, mais je ne pense pas que ça se limite à la frugalité. CMake, Ninja et Rust sont des outils qui résolvent des problèmes. Ce ne sont pas juste de nouvelles versions plus jeunes et plus fraîches d'anciens outils. Et le domaine géré par WebKit est énorme. De plus CMake et WebKit sont tous les deux en C++, un langage qui ne manque pas d'opportunités pour faire les choses inefficacement même quand on a de l'expérience :)
Mmh t'es sûr de ça ? Jusqu'ici j'ai plutôt entendu l'inverse, ce qui est plutôt ce que j'imagine quand on voit Rust comme un C++ auquel on ajoute un borrow checker et d'autres outils :)
[^] # Re: Est-ce un troll ?
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Le temps de compilation est-il une métrique pertinente ? Si webkit et cmake étaient réécrit en java, ça changerais fondamentalement les choses (le compilateur C1 de java est très rapide) ? Les temps de build viennent avec ce que l’on demande au compilateur. Les langages qui ont des macro sophistiquée comme les templates C++ ou des invariants sophistiqués comme le borrow checker). Je ne vois pas bien le rapport avec une fragilité du logiciel produit. Ou plutôt au contraire, ce temps que le compilateur passe à vérifier des propriétés sur le code c’est des erreurs en moins à l’exécution.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Est-ce un troll ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+4/-0).
Je ne comprends pourquoi il mets Go dans le panier "compliquai".
go build, c'est quand même plus simple qu'un Makefile + autoconf + 42 utilitaires…Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Est-ce un troll ?
Posté par YBoy360 (site web personnel) . Évalué à 9 (+7/-0).
Tout est mieux et plus simple que les autotools. Même Gradle…
I use Arch BTW
# Bazar et cathédrale
Posté par YBoy360 (site web personnel) . Évalué à 6 (+4/-0).
Plusieurs commentaires sur la seconde partie, le bazar vs la cathédrale :
Si gcc-avr est un gros binaire static son explication ne tient pas…
Une cathédrale sert à très peu d'usage. Un bazar permet de faire bien plus de chose. Ce sont 2 choses sans rapport entre elles. Tout dépend toujours de ce que l'on veut faire, il y a bien des choses à reprocher à l'informatique d'aujourd'hui, mais compter le nombre de dépendances ne me convainc pas.
I use Arch BTW
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.