#robuste

Antidote au #culte_de_la_performance. La robustesse du vivant

https://pixelfed.zoo-logique.org/storage/m/_v2/578583396227231930/0bb057b62-db9a0d/8Q0O5CkrVPSQ/NLYoIoMU6l5Dlj14v6ADM3GBIp06Udn36ViOWaNr.png

Face aux bouleversements du monde en cours et à venir, le #développement_durable, entre géo-ingénierie contreproductive et tout-électrique mal pensé, crée de nombreux futurs obsolètes. Émergent alors les #contremodèles de la #décroissance et de la #sobriété_heureuse, nettement mieux alignés avec le monde qui vient. Mais la #frugalité peut-elle réellement mobiliser ? Ne risque-t-elle pas non plus de se réduire à d’autres formes d’#optimisation ? Et si, pour être sobre et durable, il fallait d’abord questionner une valeur nettement plus profonde : l’efficacité. Le monde très fluctuant qui vient appelle un changement de civilisation. Ce chemin demande surtout de valoriser nos points faibles et inverse toutes les recettes.

▻https://www.gallimard.fr/catalogue/antidote-au-culte-de-la-performance/9782073047342
#livre

J’ai aussi noté le bref passage sur l’ #incohérence qui est présente a tout les stades du vivant, comme une porte ouverte vers tous les possibles.

Une sorte de plaidoyer pour l’innovation telle qu’on la conçoit en ce moment, à base de fusées et d’IA.

Hum... dommage qu’il réalise des entretiens sur Thinkerview.

#robustesse !

mon point d’entrée
▻https://fr.wikipedia.org/wiki/Robustesse_(statistiques)
mais il y a aussi
▻https://fr.wikipedia.org/wiki/Robustesse_(ingénierie)
et
▻https://fr.wikipedia.org/wiki/Robustesse_(évolution)

et en anglais, s’y ajoutent la robustesse en informatique, en économie et en optimisation pour un concept qui est fondamentalement le même…

Classiquement, dans les enseignements qu’optimiser à outrance aboutit à des optimums « pointus » et qu’il est souvent préférable de s’en tenir à des choix sous-optimaux mais robustes…

le gars donne aussi l’histoire du mot ingénieur : ça date du XVIe, à l’époque ça voulait dire : celui qui fait des machines de guerre - p.ex. catapultes, forteresses ; le tout orienté vers la performance, bien entendu.

bonne nouvelle : les même savoirs et techniques peuvent être orientés vers la robustesse ; il donne l’exemple de TCP/IP (justement designé par des militaires pour la robustesse).

#résilience #force & #robustesse (et plus bas : #html #xhtml #W3C)

Les premiers navigateurs acceptaient n’importe quoi, donc les webmestres ont pris l’habitude d’écrire du HTML sans faire attention à la syntaxe

On peut penser que en partie cela qui a contribué au succès de la plateforme ; on pouvait bricoler, c’était très tolérant, et marrant. Si les premiers navigateurs avaient été très très chiants, il n’y aurait peut-être pas eu autant de webmestres… voire plus du tout, si une autre techno plus cool avait pris le dessus. C’est une des leçons du succès de facebook ou tumblr : bien plus faciles à utiliser qu’un hébergement perso + FTP.

Et aucune autorité (et certainement pas le W3C, dans ce cas, où l’IETF pour les protocoles réseau) ne peut décider autrement, elles n’ont ni le pouvoir, ni l’envie.

Bien sûr qu’elles en ont eu l’envie : XHTML était l’exemple type, notamment quand il a été décidé qu’un navigateur lisant une page servie en XHTML, devrait afficher un message d’erreur incompréhensible à la moindre imperfection technique.

De ce point de vue, le passage à HTML5 a signé la déroute totale de cette volonté de contrôle (justement dénoncée par @arno il y a quelques centaines d’années®), et le retour à la raison pragmatique.

=> “W3C Go Home”
►http://www.uzine.net/article1979.html

@fil est donc l’exemple typique de l’utilisateur qui a abusé du soi-disant « principe de robustesse » pour être libéral à la fois dans ce qu’il reçoit (peut-être, mais plus probablement, du fait du lazy programming, cela plantera) et libéral dans ce qu’il envoie (a.k.a. j’envoie n’importe quoi et bonne chance aux autres).

@x_cli libre j’ai passé un nombre d’heures assez conséquent à essayer de ne pas tomber dans l’ornière que tu décris, et à reprogrammer tous les machins pas bien standards de #SPIP pour produire un résultat conforme… Si j’ai échoué, je t’en prie, envoie tes sarcasmes.

Mon argument ici est que, si on avait suivi la règle d’airain du « ça plante si c’est pas du XML bien formé » proposée par XHTML, on aurait moins de choses sur le net car on aurait découragé bon nombre d’amateurs. Je me réjouis que HTML5 ait balayé tout ça.

@fil Tant qu’on parle d’HTML, tout va bien, au pire, ça fait juste un site moche. Mais au final, un site moche parce qu’on a codé comme un pied n’est-il pas une forme à peine plus subtile du bon vieux message d’erreur rouge « code de merde » ?

Je ne connais pas ton oeuvre, mais une chose est certaine : coder proprement est dans la règle de robustesse (envoi strict). C’est accepter n’importe quoi qui fait débat (être libéral ou non, accepter les erreurs accidentelles).

Coder comme un mal-propre et envoyer n’importe quoi, c’est juste être mauvais et nocif/dangereux pour l’écosystème.
De ce fait, oui tout le monde devrait valider ses envois (pages HTML) avec un validateur strict comme celui du W3C (ou équivalent suivant le contexte).

Simple question pratique : s’il n’y a pas de message d’erreur bloquant et interdisant de faire n’importe quoi, alors où est la chance d’apprendre qu’on fait les choses mal et de s’améliorer ? En ce sens, je suis partisan de n’accepter que ce qui est parfait en entrée, afin de tirer le niveau vers le haut et non vers le bas. Et mon dieu ce qu’il est bas, le niveau de nos développeurs moyens.

Très rigolo, le texte d’@arno cité par @Fil, avec notamment la charge contre le Web de données (« je ne veux pas qu’on réutilise mon contenu »).

Je pense surtout que le débat n’a pas trop de sens aujourd’hui. J’avais cité HTML comme un exemple historique. Aujourd’hui, ce débat spécifique est dépassé car peu de gens (à part @Fil) font de l’HTML à la main (même moi, j’ai arrêté).

Mais oui, on pourrait très bien avoir de bons outils à visée pédagogique, expliquant par un signal discret que la page n’est pas conforme. Ca permettrait aux gens d’apprendre.

Il y a des sites moches codés proprement, et des sites jolis avec du code de merde, ça n’a absolument rien à voir.

L’autre jour, pour la petite anecdote, j’étais à un atelier du W3C, où des slides (traitant d’accessibilité !), étaient diffusées en petits caractères rouges sur un fond blanc… Selon ton bon conseil, j’aurais dû me lever et interdire au conférencier de continuer à nous parler ? Lui mettre un coup de latte dans les tibias ?

Pour moi l’important avec le Web est que tout un chacun puisse s’exprimer. Décider de mettre à plat un site pour des raisons techniques soi-disant supérieures, c’était aller à l’encontre de cet objectif, et in fine réserver l’expression aux gens qui maîtrisent l’outil, des gens comme toi quoi.

@stephane ton site programmatique est valide, bravo, mais si on suit les liens de la marge, on voit rapidement des pages faites à la main et qui ne passent pas la validation. Et bien : on les voit. Tant mieux !

L’argument « je ne veux pas qu’on réutilise mon contenu » a autant de sens que d’interdire le clic droit sur les images avec du javascript. Séparer les données du contenu est juste la même bonne vielle pratique de design logiciel qu’on appelle MVC et qui exporte le côté V au consommateur (et qui a de multiples avantages, à commencer par pouvoir se passer de refaire toute l’interface M->V lorsqu’on porte un site sur mobile).

Sinon, je suis d’accord que peu de gens font du HTML à la main. En revanche, beaucoup de développeurs web le font, à commencer par ceux qui sont spécialisés dans le DOM, le javascript, et l’actionscript si complexes qu’on en arrive à créer un nouveau métier (les développeurs coté-clients). Et ces développeurs là, vu que c’est leur métier, n’ont aucune raison de ne pas se manger des messages d’insultes de la part d’un compilo, tout comme le fait n’importe compilateur de n’importe quel langage système, afin de s’améliorer et faire des programmes corrects (qu’ils sont payés pour faire).

Un dernier mot en réponse à @x_cli, ça ne me semble pas une bonne pratique de mélanger les tests et les situations de fonctionnement réel.

@stephane : on ne dit plus robustesse de nos jours, on dit #antifragile. ▻http://www.lesbelleslettres.com/livre/?GCOI=22510100181870

On ne peut pas vraiment remettre en cause le principe sur le constat que certains mauvais élèves ne l’appliquent pas (en n’étant pas rigooureux eux-mêmes). Comme tous principes, c’est un but à viser, et il reste tout à fait valable à mon avis. Très peu de gens dans l’industrie (informatique, télécoms) mettent en application ce précepte, en particulier en France. Il y a des raisons culturelles à cela, je pense.

@x_cli :

Et ces développeurs là, vu que c’est leur métier, n’ont aucune raison de ne pas se manger des messages d’insultes de la part d’un compilo, tout comme le fait n’importe compilateur de n’importe quel langage système, afin de s’améliorer et faire des programmes corrects (qu’ils sont payés pour faire).

Dans un monde théorique, je veux bien, le problème est qu’il n’y a pas de compilateur (ou plutôt interpréteur) unique du html (et surtout du css et du javascript), donc les développeurs web auront plutôt tendance à développer jusqu’à ce que « ça marche » sur les navigateurs cibles et non pour le pur respect de normes. Notons il est vrai que les différences entre navigateurs se sont considérablement réduites mais on n’est pas encore au stade où respecter les normes du W3C suffirait a ne pas tester chaque rendu de chaque navigateur, sans compter que tout le monde n’a pas la dernière version installée sur sa machine. Quoiqu’il en soit, les normes introduites par XHTML étaient inutilement complexes à mon sens et le HTML5 a tout de même simplifié les choses.

Personnellement j’aurais un autre point de vue face à son principe, à son application plus ou moins heureuse, et la conclusion que j’entrevois.

A mon sens ce principe est excellent pour les protocoles réseau (je ne vois aucun contre-exemple mais quelqu’un peut toujours en trouver un).

En revanche dans le domaine de l’applicatif, (e.g. html cité par Stephane Bortzmeyer) il conviendrait d’être effectivement moins libéral pour ce que l’on reçoit.

La différence est de nature et aussi d’objectif.

Nature :

un protocole de communication contrairement à une application n’est pas un but en soit, il faut pouvoir echanger des données pour pouvoir aller plus loin vers le service rendu ou à rendre.

Combinatoire de contact (ou « promiscuité »)

dans le réseau la combinatoire des implémentations différentes est moindre que coté applicatif.

Coté applicatif le nombre et la diversité de connexion est beaucoup plus large,

voila pourquoi selon moi il faut une certaine rigueur dans la réception pour assurer un fonctionnement correct.

enfin c’est ce que je pense humblement et partage non moins humblement...