L’abstraction logicielle détruit-elle la civilisation ? (2021)

• L’idée défendue par Jonathan Blow selon laquelle « l’abstraction affaiblit les capacités indispensables de maintenance logicielle » est pertinente du point de vue de la transmission des connaissances, mais une grande partie des exemples invoqués interprète mal l’histoire et le contexte
• Les débats sur les « five nines », le logiciel robuste, le ralentissement du progrès technique et la baisse de productivité reposent souvent sur une confusion entre appareils grand public et systèmes à haute disponibilité, ou sur des exemples choisis de manière sélective
• L’inquiétude autour de la perte des connaissances bas niveau est en partie fondée, mais le C, l’assembleur, Rust, le portage de systèmes d’exploitation, l’enseignement des compilateurs et l’activité open source restent des voies de maintien des compétences systèmes
• Les abstractions comme les systèmes d’exploitation, les systèmes de fichiers, le réseau, le multitâche ou les frameworks augmentent la complexité, mais elles permettent aussi d’absorber l’évolution du matériel et les attentes des utilisateurs tout en améliorant la portabilité, la productivité et l’accessibilité à la création
• Plus que l’abstraction elle-même, les risques majeurs viennent du churn permanent, des plateformes verrouillées, de la publicité, des trackers, de la télémétrie, ainsi que de l’érosion de la vie privée et des libertés ; il faut néanmoins préserver la base technique nécessaire pour maintenir les systèmes critiques

---

Position de départ sur la thèse de Blow

• La conférence de Jonathan Blow soutient que les abstractions logicielles entraînent une perte des connaissances de programmation bas niveau, ce qui pourrait à terme empêcher la maintenance de logiciels essentiels et mener à un effondrement de la civilisation
• L’auteur dit partager l’importance de la transmission des connaissances, mais estime que des affirmations de cette ampleur exigent des exemples exacts et un contexte historique rigoureux
• Son objection principale est que les exemples de Blow reposent largement sur des malentendus, des cas choisis de façon sélective et des preuves anecdotiques, tout en laissant de côté une partie de l’histoire de l’informatique

Débat sur les « five nines » et la robustesse

• Blow affirme qu’autrefois on vendait des systèmes informatiques avec l’argument des « five nines », c’est-à-dire 99,999 % de disponibilité, alors que les ordinateurs portables actuels n’atteignent pas ce niveau
• Il est exact que les five nines correspondent à environ 5 minutes d’interruption par an, mais l’idée que cette métrique servait à vendre des laptops grand public ou des traitements de texte est jugée fausse
  • Les five nines s’appliquent généralement à des domaines comme les centraux d’urgence de type 911, les systèmes hospitaliers ou le traitement des transactions financières
  • Ils s’accompagnent souvent de contrats de long terme définissant précisément les situations exclues du calcul de l’indisponibilité
  • Des entreprises comme IBM et Amazon vendent toujours ce type de systèmes et de services
• L’affirmation selon laquelle aucun logiciel robuste n’aurait été produit depuis des décennies connaît aussi des contre-exemples
  • Un iPhone peut fonctionner pendant des semaines ou des mois sans redémarrage
  • Des serveurs de fichiers et d’impression Novell ont connu des temps de fonctionnement de 16 ans
  • Des machines Unix, Windows, VMS et des systèmes clés en main comme IBM i sont également cités comme exemples de disponibilité de longue durée

Réponse sur le progrès technique et la productivité

• L’idée que « les entreprises technologiques ne poussent plus vraiment la technologie » est partiellement admise, mais les sociétés privilégiant l’argent ont toujours existé
• Même des domaines « ennuyeux » comme les systèmes de fichiers, les serveurs web, les bases de données ou les langages de programmation continuent d’être développés et améliorés
• Les couches d’abstraction, de virtualisation et de conteneurisation que Blow n’apprécie pas continuent elles aussi d’être améliorées au prix d’efforts considérables ; le simple fait de ne pas les aimer n’en fait pas l’absence de progrès technique
• L’idée que la productivité des employés de Facebook serait proche de zéro repose sur l’hypothèse que le produit de Facebook se réduit aux fonctions visibles d’une plateforme sociale
  • Les employés de l’entreprise Facebook occupent des rôles très variés : juridique, comptabilité, design graphique, administration système, recherche, RH, management intermédiaire, etc.
  • L’entreprise possède aussi d’autres activités comme Instagram, WhatsApp ou Oculus VR
  • Le véritable produit de Facebook est une plateforme de diffusion publicitaire, et la collecte de données personnelles pour les transformer en publicité ciblée ne se voit pas forcément dans les fonctionnalités utilisateur, mais se reflète dans le chiffre d’affaires

Les connaissances bas niveau et les deux faces de l’abstraction

• L’auteur reconnaît qu’un grand nombre de programmeurs préfèrent des environnements où ils n’ont pas à manipuler l’allocation mémoire et les pointeurs
• Il considère comme problématiques les surcouches d’abstraction excessives, comme le fait de rendre un blog simple avec des frameworks JavaScript inutiles ou de distribuer des applications desktop lentes tournant dans un navigateur embarqué
• Il note toutefois qu’il est possible qu’il y ait aujourd’hui davantage de personnes capables de manier le C, ainsi qu’un plus grand volume de code en C et en assembleur qu’autrefois
  • Linux et NetBSD continuent d’être portés vers une grande variété de cibles proches d’un CPU
  • Rust se concentre sur la robustesse tout en donnant accès aux pointeurs et à la gestion mémoire
  • Harvard CS50 traite publiquement de sujets comme l’agencement mémoire, les pointeurs, malloc() et free()
• Le garbage collection et la programmation fonctionnelle ne sont pas de nouvelles abstractions
  • Lisp proposait déjà les deux à la fin des années 1950
  • Lisp est utilisé même dans des environnements « hardcore » comme le Jet Propulsion Lab de la NASA
• COBOL, absent de la conférence de Blow, joue pourtant encore un rôle crucial dans le niveau actuel de civilisation en tant que langage de haut niveau à la base des infrastructures bancaires et financières

Le cas du « Unix en 3 semaines » de Ken Thompson

• Le fait que Ken Thompson ait créé en trois semaines un assembleur, un éditeur et un noyau de base pour Unix est présenté comme une réalisation remarquable
• Mais on ignore à quel point ce logiciel était robuste à ce stade, convivial ou riche en fonctionnalités
• Les conditions de travail d’alors et celles des développeurs actuels diffèrent fortement
  • La documentation, les revues de code, les daily standups, le tri du backlog, les user stories, les tests unitaires, les exigences client, les A/B tests, les messages de commit et les standards de codage d’entreprise s’ajoutent aujourd’hui au développement
  • Un open space interrompu en permanence peut aussi être très différent d’un environnement de travail individuel à la Bell Labs
• Le seul exemple de Thompson ne prouve pas que l’ensemble des programmeurs d’autrefois étaient plus productifs
  • Thompson a aussi participé à Multics, célèbre pour ses retards
  • De grands projets comme IBM OS/360 ont eux aussi accumulé les retards, et Frederick P. Brooks s’est appuyé sur cette expérience pour écrire en 1975 The Mythical Man-month

Évolution du logiciel et attentes des utilisateurs

• L’auteur estime que les ordinateurs sont globalement plus robustes qu’il y a plusieurs décennies, et que les programmeurs sont au moins aussi productifs qu’autrefois
• Il admet toutefois que, dans certains cas, commencer un projet est devenu plus complexe, ce qui peut réduire la productivité initiale
• Les utilisateurs modernes ne veulent pas apprendre la notation RPN pour faire une opération simple, ni écrire des directives troff pour produire un flyer
• Les interfaces pratiques et les fonctionnalités avancées augmentent la complexité et le temps de développement, indépendamment de l’abstraction
• Le cas d’un ancien Amiga OS qui plante pendant une copie de fichiers et corrompt une partition de disque dur montre que les anciens systèmes n’étaient pas nécessairement plus stables
  • Les OS modernes pour ordinateurs domestiques disposent de la protection mémoire et de systèmes de fichiers journalisés, ce qui rend ce type de problème bien plus rare
  • Windows 10 Home a ses défauts, mais inclut aussi ce genre de progrès

Les affirmations du type « avant, on pouvait simplement le faire »

• Copier un programme et l’exécuter

  • Copier un programme d’un ordinateur à un autre et l’exécuter reste possible dès lors que l’architecture cible et les conditions de compilation sont les mêmes
  • Un binaire à liaison statique de slack-term, compilé en Go, a par exemple fonctionné sur plusieurs Raspberry Pi
  • Cela dit, pour retrouver une époque où les programmes autonomes étaient la norme, il faut remonter aux temps du C64 ou du PC/XT ; même Deluxe Paint IV sur Amiga dépendait de plusieurs fichiers auxiliaires et de bibliothèques de fonctions tierces
  • Certains jeux Amiga utilisaient des disquettes chargées piste par piste en contournant le système de fichiers, une sorte de conteneur d’époque, mais avec l’inconvénient d’empêcher l’installation sur disque dur et le multitâche

• L’idée que le code tourne tant que le CPU est le même

  • En théorie, il est possible de charger du code machine en mémoire et de le lancer en positionnant le compteur ordinal si le CPU est identique
  • Mais pour des tâches concrètes comme afficher des graphismes, jouer du son, gérer les entrées ou écrire sur disque, les différences matérielles deviennent un obstacle majeur
  • Les micro-ordinateurs domestiques basés sur Z80 partageaient parfois le même CPU, tout en restant difficiles à porter à cause de périphériques différents
  • À l’inverse, des programmes écrits à un niveau d’abstraction plus élevé, comme en Basic, pouvaient souvent être plus facilement portables entre machines
  • Avec l’arrivée d’une gamme desktop Apple basée sur ARM, s’appuyer sur l’abstraction plutôt que coller directement au métal peut réduire le coût de portage vers un nouveau CPU

• Système d’exploitation et accès au matériel

  • Un système d’exploitation ne se contente pas de retirer des capacités au CPU ; il ajoute aussi des fonctionnalités comme le système de fichiers, le réseau et le multitâche
  • Un utilisateur qui doit faire tourner un jeu en même temps que d’autres logiciels, comme un streamer Twitch, a besoin d’un multitâche capable de répartir les ressources matérielles de façon gérée et prévisible
  • Une partie des logiciels Amiga et Atari accédait directement au matériel et à la mémoire au lieu de respecter les spécifications et abstractions fournies par le constructeur ; de petites évolutions, comme davantage de mémoire ou un disque dur, pouvaient alors suffire à les casser
  • Les logiciels écrits dans le respect des spécifications et des abstractions pouvaient continuer à être vendus malgré les changements matériels

• Graphismes, programmes non signés et LSP

  • Il est toujours possible de dessiner des pixels à l’écran dans de nombreux langages, et même le Mode 13h passait par le VGA BIOS, c’est-à-dire une première couche d’abstraction matérielle
  • Du code dépendant d’un matériel VGA précis n’était pas portable, alors qu’un programme graphique s’appuyant sur les abstractions de Windows pouvait fonctionner de Hercules jusqu’au true-color XGA
  • Il reste également possible d’exécuter des programmes non signés ; l’auteur cite par exemple le cas de WordGrinder compilé manuellement
  • Une partie des plaintes de Blow vise moins l’abstraction elle-même que le verrouillage croissant des systèmes par les fournisseurs matériels et logiciels, avec une réduction des droits utilisateurs
  • Sur le Language Server Protocol, l’auteur se dit globalement d’accord avec Blow, tout en notant que le LSP résout davantage de problèmes que le simple « cliquer sur une méthode pour aller à sa définition »

Jeux, performances et multitâche

• De nombreuses applications modernes de productivité présentent des problèmes de performances et une latence de saisie importante
• L’abstraction en est une cause partielle, mais le problème principal tient davantage à du mauvais code et à un mauvais choix d’outils pour la tâche visée
• Des programmes reposant sur la même plateforme et le même toolkit d’interface peuvent offrir des performances perçues très différentes sur une même machine
• Le problème évoqué par Blow sur un jeu qui restaure mal sa résolution après un Alt-Tab est jugé pénible et mérite d’être corrigé
• Mais les jeux DOS d’autrefois étaient plus simples aussi parce qu’ils n’avaient pas à se soucier des autres processus
  • Sous Windows 3.1, pour jouer à Doom, il fallait enregistrer son travail, fermer les programmes, quitter Windows, puis lancer le jeu
  • Sur Amiga aussi, de nombreux jeux démarraient depuis une disquette en monopolisant totalement la machine, sans toujours revenir proprement à l’OS
• L’auteur estime qu’aujourd’hui, même imparfait, le multitâche dans les jeux progresse par rapport au passé

Perte de connaissances et vitesse du changement

• Blow considère qu’un savoir comme la gestion des sprites dans Unity se transforme en savoir de surface plutôt qu’en compréhension profonde
• L’auteur lui donne raison sur un point : la vitesse de changement du logiciel et du matériel modernes est souvent trop élevée pour être suivie de façon vraiment utile
• Mais cela relève moins de l’abstraction en elle-même que de la cohérence dans le temps et du modèle de distribution logicielle
• Un rythme de livraison toutes les quatre semaines peut empêcher les utilisateurs d’obtenir une expérience stable
• Des changements fréquents d’interface obligent les utilisateurs à se battre avec des détails qui bougent sans cesse au lieu d’accomplir leur travail réel

La complexité est un problème créé par l’humain

• Blow soutient que si l’on décide de réduire la complexité, on peut le faire, et que beaucoup s’imaginent à tort qu’ajouter de l’abstraction fait gagner du temps
• Utilisé correctement pour le bon usage, un framework peut être d’une grande aide pour un développeur web
• En même temps, l’auteur reste sceptique face à l’idée de tout faire dans le navigateur, du traitement de texte aux jeux, ou de migrer immédiatement vers chaque nouveau framework à la mode
• La complexité logicielle n’est pas seulement un problème de programmeurs ; elle est aussi produite par le marché et l’organisation du travail
  • Politique interne, réunions inutiles, logiciels absurdes de suivi du temps, délais imposés de l’extérieur, demandes clients pénibles, décisions managériales étranges, estimation de plannings sur des exigences abstraites, débogage de code legacy : tout cela influe sur les choix des développeurs
• La complexité est un problème créé par l’humain, et réduire la complexité au travail pourrait, à long terme, réduire aussi celle des logiciels

Jeunes développeurs et capacité à créer des moteurs

• L’affirmation de Blow selon laquelle les jeunes développeurs de jeux n’auraient jamais écrit leur propre moteur et que cette capacité pourrait bientôt être oubliée collectivement relève d’une logique de pente glissante
• La majorité des personnes possédant un C64, un Amiga ou un PC 286 ne sont jamais devenues développeurs bas niveau, et beaucoup ne sont jamais devenues programmeurs du tout
• Les abstractions et les moteurs de jeu prêts à l’emploi permettent de créer sans maîtriser la gestion mémoire bas niveau, les pointeurs ou les algorithmes
• Les enfants d’aujourd’hui veulent fabriquer des jeux comparables à ceux de type AAA vendus en magasin, et les attentes envers les jeux modernes sont bien plus élevées qu’à l’époque du C64 ou de l’Amiga
• Les voies d’apprentissage des techniques bas niveau existent toujours
  • Linux attire de jeunes développeurs via la communauté open source et suscite l’intérêt pour des langages systèmes comme Rust, C et C++
  • dwm est un gestionnaire de fenêtres configuré en modifiant directement son code source en C
  • Il existe de jeunes développeurs utilisant le C et l’assembleur Z80, des personnes qui construisent une distribution Linux depuis zéro, d’autres qui fabriquent leur propre matériel, ainsi que des développeurs C faisant tourner des OS de recherche sur du matériel moderne
  • Les cursus d’informatique et de génie électrique continuent d’enseigner les bases comme le C, l’assembleur et la conception de compilateurs
  • L’accès aux outils de programmation, à la documentation, aux vidéos éducatives et à des ressources comme MIT OpenCourseWare est moins coûteux et meilleur qu’autrefois

Jugement final : des problèmes plus graves que l’abstraction

• La conclusion de Blow s’apparente à une forme de survivalisme appliqué à la technologie, et l’auteur dit comprendre l’analogie selon laquelle il faut des gens capables d’allumer un feu lorsqu’il y a une panne d’électricité
• La société dépend de la capacité à faire tourner certains programmes presque en permanence
  • En cas d’échec, les conséquences peuvent être graves, comme l’effondrement de l’économie mondiale ou la défaillance d’un système national de santé
  • Une part croissante des archives historiques et contemporaines est stockée sous forme numérique, et il faut qu’elles restent accessibles dans le futur
• La complexité est fragile, l’abstraction peut créer une ignorance nuisible, et il n’est pas nécessaire d’avoir un shadow DOM pour afficher un blog simple, ni une coque de navigateur pour un client IRC avec images
• Mais le churn artificiel et permanent est lui aussi une cause majeure de fragilité
  • Le développement « Agile » vise en théorie à éviter la livraison de choses non terminées ou non testées, mais dans la pratique il entraîne souvent une succession continue de versions inachevées
  • Les systèmes de publicité, de tracking et de télémétrie fonctionnent en pratique comme des portes dérobées conçues dès l’origine, et ajoutent de la vulnérabilité ainsi qu’un sentiment d’insécurité
• Le plus grand problème du monde numérique concerne la vie privée et la liberté
• Si l’on ne peut plus interagir directement avec le matériel, ce n’est peut-être pas parce que l’on a choisi l’abstraction, mais parce qu’il ne reste plus que des plateformes de plus en plus verrouillées et contrôlées à distance

[GN⁺]

Avis sur Hacker News

• J’enseigne à Montana State un cours sur les systèmes qui va des transistors jusqu’aux vrais systèmes informatiques, et au début du cours certains étudiants ne savent même pas vraiment ce qu’est un système de fichiers.
  Blow se trompe sur certains détails, mais je pense que pour les étudiants en filières techniques, il faudrait sérieusement envisager dès le lycée une formation de type NAND-to-Tetris.
  J’utilise des modèles « dépassés » comme le Little Man Computer ou de simples émulateurs MIPS visuels ; ils ne sont pas réalistes, mais ils donnent une idée de notre point de départ, avec une complexité compréhensible par le commun des mortels.
  Quand je vois les manuels d’architecture 64 bits recommandés aujourd’hui, ça me fait juste rire ; relier la technologie à ses racines est un problème difficile.

  • Les notions de fichier et de système de fichiers sont utiles même aux utilisateurs ordinaires d’ordinateurs qui ne s’intéressent pas au fonctionnement interne.
    Le problème, c’est que les systèmes d’exploitation mobiles et les éditeurs de logiciels cherchent autant que possible à transformer les données des utilisateurs en jardins clos à l’intérieur des apps.
    Même quand on travaille déjà avec des fichiers, ils vous obligent à « importer » les données existantes dans leur propre stockage, puis à « exporter » ou « partager » manuellement les modifications sous forme de nouvelle copie.
  • Je suis moi-même plutôt un vieux râleur, mais j’ai renoncé à avoir des attentes envers la génération actuelle des « étudiants ».
    Je fais un master en génie industriel à Montana State, et je côtoie tous les jours des doctorants incapables de faire une simple dérivée partielle.
    Le semestre dernier, dans un cours de maths de niveau 400, il y avait même un étudiant qui ne savait pas additionner deux matrices.
    Qu’un étudiant de dernière année en informatique ne connaisse pas les systèmes de fichiers est étrange, mais comparé aux absurdités que j’ai vues ici, cela paraît presque anodin.
    L’ambiance est très différente de celle de ma première expérience universitaire dans les années 2000, ce qui est déprimant, mais du coup je suis plutôt confiant pour le marché de l’emploi au printemps prochain.
  • Cela dépend de la spécialité. L’informatique, le génie informatique et l’électronique sont des domaines différents.
    Malgré son nom, l’informatique n’est pas l’étude des ordinateurs eux-mêmes ; même si l’ordinateur est un outil indispensable, le cœur du domaine est l’abstraction des domaines, la modélisation par les langages et leurs applications.
    De même qu’un astronome doit savoir utiliser un télescope autant que nécessaire, un informaticien doit savoir utiliser un ordinateur autant que nécessaire.
    Mettre l’ordinateur au centre de l’univers et en faire le point de départ de l’informatique est une grave erreur, et historiquement une source de beaucoup de confusion.
    Même la programmation « bas niveau » reste au fond de l’abstraction et du langage ; on se contente d’utiliser le langage d’un dispositif de calcul pour simuler l’abstraction du domaine dont on parle.
  • J’ai appris l’architecture des ordinateurs avec MIPS à l’époque où MIPS était utilisé dans de vrais produits ; c’était très bien à l’époque, et ça l’est encore aujourd’hui.
    Pendant mon temps libre, je décompile de l’assembleur MIPS, et pour les petites fonctions je peux les retranscrire à la main en code C correspondant, sans autre outil.
  • Le fait d’enseigner touche directement à l’idée selon laquelle « l’information transmise entre les générations se dilue ».
    Mais elle ne se dilue pas vraiment. C’est parce qu’il existe l’enseignement, les livres et les ordinateurs qu’on n’a pas besoin d’appeler les enseignants des bardes.
    Au final, ce n’est qu’un autre billet de blog à propos d’un billet de blog, et je ne sais pas à quel point ces blogueurs sont « importants », mais ça sent le blog fait pour alimenter les blogs.

• Quand un vieux développeur web critique l’abstraction, il vise les développeurs React ; quand un développeur Python la critique, il vise les vieux développeurs web ; quand un développeur d’applications C++ la critique, il vise les développeurs Python.
  Les développeurs firmware visent les développeurs d’applications, et les ingénieurs électriciens visent les développeurs firmware.
  Tracer la limite de l’abstraction excessive au niveau de ce qu’on connaît soi-même, puis appeler tout ce qui vient après « ce qui tue la civilisation », c’est quand même une posture assez remarquable.

  • Exactement. C’est à peu près du même niveau que les absurdités du genre « la chimie, c’est de la physique appliquée, et la physique, c’est des maths appliquées, donc les maths sont au-dessus de tout ».

• Il y a beaucoup de bons points, et comme j’ai vu cette présentation, je pense que la critique est importante.
  Cela dit, Blow a raison quand il dit qu’on ne peut pas « juste dessiner des pixels à l’écran ».
  Je travaille comme programmeur de moteur de jeu dans un studio de taille moyenne, et il devient très difficile de recruter des gens capables de travailler sur le code graphique.
  Les API de la génération de DX12 exigent des programmeurs un niveau énormément plus élevé que la génération précédente, DX11, et faire quoi que ce soit avec ces API est en soi un gros chantier.
  Microsoft avait même reconnu qu’apprendre DX12 sans expérience préalable des API graphiques était extrêmement difficile, mais je n’arrive plus à retrouver cette citation dans la documentation.
  L’objection selon laquelle « ces API sont destinées aux développeurs qui veulent pousser les cartes graphiques dans leurs retranchements et faire des optimisations très bas niveau » est en partie juste, mais elles sont désormais devenues le standard de l’industrie, et elles sont quasiment impossibles à enseigner à quelqu’un sans expérience préalable.
  Si rien ne change, le vivier de candidats recrutables continuera de se réduire.

  • En voyant la présentation de Blow, j’ai compris que je n’étais pas fou de trouver frustrant que des choses élémentaires soient devenues absurdement difficiles.
    Quand on crée une application logicielle, même dessiner un simple bouton à l’écran est devenu tellement compliqué que la plupart des gens utilisent simplement des progressive web apps 100 fois plus lentes que ce qu’il serait possible d’atteindre.
    En 2025, est-ce que le meilleur choix pour une application GUI est vraiment Java Swing et Qt ?
  • Je suis d’accord sur le fond, mais DX12 est allé dans la direction opposée à l’abstraction. C’est une API de bien plus bas niveau qu’OpenGL, qui est très abstraite.
  • Ou alors on pourrait voir revenir le « développeur junior en formation ».
  • Ce qu’il faut surtout améliorer, c’est la formation et la documentation autour de ces nouvelles API.
    Il existe de grands concepts qui relient l’ensemble, mais ils sont à peine suggérés dans la documentation ; on ne les apprend qu’en assistant à des sessions de formation ou en discutant avec quelqu’un qui les connaît déjà.

• Je pense que le JavaScript côté serveur et des choses comme React ont vraiment mis le bazar dans le développement logiciel web, au regard de ce qu’ils font réellement.
  Parmi les jeunes d’aujourd’hui, certains ne savent même pas que ce qui est rendu dans le navigateur, c’est du HTML. Ils pensent que le navigateur rend React lui-même.
  Et en plus, le CEO de Vercel a sorti une énormité absolue en disant qu’il considérait React comme le noyau Linux du développement.

  • C’est une affirmation étrange, mais il l’a réellement dite.
    https://news.ycombinator.com/item?id=42824720
    Je suis là depuis assez longtemps pour me souvenir de l’époque de vanilla js, jQuery, Knockout et Angular 1, et même alors, la confusion de base a toujours existé.
    React, et parfois même JSX tout seul, peut être utilisé de façon raisonnable.
    Je blâme plutôt les outils financés par le capital-risque comme Vercel, Next, Apollo et Prisma, ainsi que les influenceurs du développement web payés pour remplir le Web de cochonneries.
    À bien y penser, tout dans la fabrication de logiciels est devenu hypertrophié, des tableaux Notion jusqu’aux choix de bases de données douteux.
  • Je suis d’accord pour dire qu’il est effrayant de voir autant de jeunes développeurs incapables de programmer sans React.
    Mais, en tant que personne capable de travailler correctement sans bibliothèque, j’aimerais ajouter que le DOM est l’une des pires API jamais inventées par l’humanité, et que la « programmation réactive » est un modèle supérieur aux anciennes façons de faire.
    NextJS a annulé des années d’améliorations des outils et il est beaucoup plus lent que Vite.
    Avec NextJS généré statiquement, une page sans aucune interaction télécharge 100 Ko de JavaScript pour ne rien faire.
    Facebook essaie de résoudre avec un « compilateur » pour React quelque chose qui devrait simplement consister à ne pas re-rendre inutilement les composants par défaut.
    Comparé à Preact, qui peut le remplacer presque tel quel, React est énorme, et cela montre à quel point Facebook s’en moque.
  • Ironiquement, dire que « ce que le navigateur rend, c’est du HTML » est faux, et ceux qui pensent que le navigateur rend React ont plutôt raison.
    HTML est un format de sérialisation, et le navigateur l’utilise pour construire un DOM en mémoire.
    React ne sérialise rien en HTML ; il rend directement dans le DOM.
    Le fait que cette affirmation, bien que fausse, ait reçu beaucoup de votes montre bien que ce fil a un côté « vieux qui crie sur les nuages ».
  • Dans le contexte de la modification du DOM avec JavaScript, je ne sais pas ce que signifie « le navigateur rend du HTML ».
    D’après ma compréhension, HTML est l’entrée du navigateur, que celui-ci transforme en DOM avant de passer au dessin à l’écran, à la gestion des entrées, etc.
    Cette différence est importante : React ou les bibliothèques JavaScript de type DOM virtuel ne produisent pas du HTML, mais des instructions de manipulation du DOM en JavaScript.
  • Il me semble que le cœur de React, justement, est de ne pas fonctionner du tout si JavaScript n’est pas activé, et de créer un tel bazar que Facebook puisse y dissimuler efficacement ses propres comportements malveillants.
    Il y a beaucoup de bonnes choses dans les critiques de Blow, mais je pense qu’il passe à côté du fait que beaucoup de régressions ne viennent pas d’une dérive générationnelle ou de l’entropie de l’information, mais de la malveillance flagrante des personnes qui prennent les décisions.

• Blow pointe souvent des choses vraiment excellentes à propos du développement, et il se trompe aussi complètement très souvent.
  Il a accompli beaucoup de choses et a des idées qui valent la peine d’être écoutées, mais il y a aussi beaucoup de sottises présentées de façon indiscernable du reste.
  Le discours sur l’effondrement de la civilisation m’a fortement semblé faire partie de ces sottises, et même après l’avoir écouté deux fois, je l’ai en grande partie ignoré.
  Je suis reconnaissant à l’article original d’en proposer une réfutation plus fondée sur des principes.
  Je trouve que Casey Muratori imite Blow, mais sans même réussir à reproduire correctement ses bons côtés.

  • Blow travaille sur un jeu depuis presque 10 ans, et en plus un jeu pour lequel il n’avait même pas besoin de réinventer la machine.
    Muratori n’a même pas terminé le jeu qu’il a commencé il y a 10 ans.
    À l’inverse, avec les moteurs de jeu modernes, y compris des choses comme Raylib, on peut obtenir des résultats assez convaincants même lors d’une game jam de week-end ; et un jeu de Sokoban comme celui de Blow pourrait probablement être réalisé en environ six mois, surtout avec une équipe d’une dizaine de personnes.
  • Je serais curieux de savoir avec quoi, précisément, tu n’es pas d’accord chez Casey Muratori.
    J’ai vu une partie de son contenu et, sur les sujets que je connais, il m’a semblé humble mais avec des opinions claires ; je pense aussi qu’il a très bien mené Handmade Hero.
  • L’argument central de Muratori me semble être que les logiciels modernes sont lents, et là-dessus je pense qu’il a raison à 100 %.
    Le temps que Jira met à afficher un ticket, le temps que Slack met à changer de salon, ou le fait que VSCode n’arrive pas à suivre une vitesse de frappe ordinaire, c’est vraiment délirant.
  • Je me demande si c’est vraiment le cas.
    Il semble surtout lancer de grandes critiques générales, puis disparaître de nouveau pour ne rien faire.
    Il est difficile de dire qu’il a accompli quelque chose de remarquable ; je dirais qu’il a fait un travail correct.
    Il n’a sorti que deux jeux, qui ressemblent davantage à des puzzles qu’à des jeux. Une fois terminés, il n’y a presque aucune raison d’y rejouer.
    Braid est correct, et The Witness ressemble simplement à Flow.
    Depuis, cela fait 10 ans qu’il développe un langage de programmation, qu’il ne publie pas au motif qu’il « n’est pas encore terminé ».
    On dirait qu’après avoir gagné de l’argent par chance, il se voit comme bien plus talentueux qu’il ne l’est réellement.

• L’environnement logiciel moderne a clairement beaucoup de problèmes, et je pense que l’excès d’abstraction en fait partie.
  Mais l’extrême opposé est mauvais aussi, et il y a une tendance à trop idéaliser le passé.
  Les plantages et les redémarrages étaient aussi un problème ; des systèmes comme l’Amiga avaient des problèmes de compatibilité entre versions matérielles, et même les systèmes qui privilégiaient la compatibilité n’étaient pas exempts d’incompatibilités.
  Même sur Windows 11, qui est le système moderne le plus instable, mon ordinateur est bien plus stable que n’importe quel ordinateur que j’utilisais avant 2010, et il peut aussi exécuter des logiciels pour Windows 95.
  Un ordinateur utilisable au quotidien vaut mieux qu’un ordinateur qui ne l’est pas.

• Toutes les simplifications ne sont pas des abstractions, et toutes les abstractions ne sont pas non plus des simplifications
  Mais il arrive souvent qu’une abstraction naisse de la recherche de simplification
  Je ne pense pas que l’abstraction tue le logiciel ou la civilisation, mais les mauvaises abstractions créées au nom d’une simplification à court terme réduisent la flexibilité, l’agilité et l’accessibilité
  Quand on regarde le sucre syntaxique de presque tous les langages, il arrive un moment où la simplification locale obtenue dans telle nuance particulière ne justifie plus l’augmentation de la complexité de l’outil dans son ensemble
  Dans les langages à la syntaxe abondante, si les gens se trompent, ce n’est pas à cause d’un élément précis, mais parce que le simple fait d’utiliser l’outil pour résoudre correctement des problèmes complexes devient difficile
  La complexité que async et les coroutines ajoutent à mon expérience dans Kotlin lorsqu’il s’agit de manipuler du code « ressemblant à des threads » est totalement différente de la façon dont Elixir/Erlang traite le même type de problème
  Les deux offrent une abstraction et une simplification pour le vieux problème du calcul parallèle et asynchrone, mais le premier multiplie des couches de simplicité pour recréer quelque chose de complexe, tandis que le second ressemble plutôt à une abstraction vraiment simple qui fonctionne, tout simplement

• L’auteur semble appartenir à une génération plus jeune, et a donc apparemment raté l’argument de Blow sans le comprendre
  Ironiquement, son texte lui-même ressemble à l’un des exemples dont parlait Blow
  C’est un peu comme dire que Figma est en train de ruiner le monde du design à une échelle sans précédent en normalisant la mauvaise UX, la mauvaise UI et la mauvaise gestion produit propres à Figma, puis recevoir en retour des réactions de jeunes designers perplexes pour qui tout va bien
  Ce savoir existe parce qu’on a grandi dans cet environnement, eux non, et il n’est pas facile non plus d’apprendre ailleurs ce qui relève de la culture et de l’expérience

  • Donc l’objection revient finalement à dire : « il est jeune et inexpérimenté, donc il a tort » ? Peut-être, mais il manque précisément ce qui serait faux
    Cette attaque ad hominem n’apporte rien à la discussion
  • Peux-tu expliquer davantage en quoi Figma ruine le monde du design ?
  • Quel est, selon toi, le point que l’auteur a manqué ?
  • Je n’ai absolument pas l’impression que l’auteur appartienne à une génération plus jeune. Le reste n’est pas vrai non plus
  • L’argument de Blow a été correctement réfuté, donc pas besoin de parler d’âge, mais l’auteur a probablement au moins la quarantaine bien entamée. L’Amiga était populaire à la fin des années 80
    Contrairement à l’affirmation selon laquelle « l’idée que le logiciel progresse est manifestement fausse », j’utilise encore souvent mes ordinateurs Amiga, que j’adore
    Il y a quelques semaines, alors que je copiais des fichiers sur un disque dur Amiga, l’ordinateur a soudainement planté, non pas parce que j’avais fait une erreur, mais parce que les systèmes d’exploitation des vieux ordinateurs familiaux n’étaient pas particulièrement stables
    Résultat : la partition du disque dur a été endommagée, le système d’exploitation n’a pas pu revalider le système de fichiers, et je n’ai finalement pas eu d’autre choix que de reformater la partition
    Je ne connais pas bien le design, mais je peux voir que l’affirmation sur Figma est complètement fausse, tout comme celle de Blow
    C’est la nostalgie qui parle. Les interfaces utilisateur ont toujours comporté beaucoup de choses mal fichues, tout comme les logiciels, et tout le reste
    On ne retient que les qualités des meilleurs exemples du passé, et on oublie les cochonneries, ainsi que les échecs de choses pourtant bien conçues

• Le problème, ce sont les abstractions qui n’ont pas été pensées en profondeur
  Beaucoup d’abstractions portent clairement la marque d’un premier brouillon ou d’un premier essai, mais à cause du culte de la vitesse et de l’arrogance de l’industrie tech, elles sont publiées telles quelles avant d’avoir été affinées plusieurs fois
  Quand ce genre d’abstraction devient une partie d’un projet populaire, les autres la copient par mimétisme sous le drapeau flou des « bonnes pratiques »
  Répétez ce processus pendant 10 à 20 ans et vous obtenez un gigantesque bazar
  Pire encore, dans une société paradoxalement sur-socialisée par la technologie, le consensus social consistant à ne pas vouloir être démasqué comme « imposteur » continue de propager des solutions pas encore mûres
  J’aime cette présentation de Jonathan Blow et je la revois au moins une fois par an. À mon avis, il ne dit pas des choses polémiques : beaucoup de développeurs se mettent en colère ou se sentent visés parce qu’au fond d’eux-mêmes ils savent qu’ils ne livrent pas le meilleur travail possible et ne guident pas correctement les jeunes générations
  Nous sommes arrivés à une culture où la quête de nouveauté est quotidienne et parfois même célébrée
  Autrefois, les solutions suffisamment examinées constituaient la norme culturelle ; aujourd’hui, c’est le nouveau qui est devenu la norme, indépendamment de sa qualité réelle
  On peut disséquer indéfiniment les détails de l’argument de Blow, mais les preuves sont partout, bien en face de nous
  Et sur un horizon temporel suffisamment long, cela peut mener à un effondrement de la civilisation ; à voir la quantité de choses cassées dans le monde, on peut même considérer que c’est déjà en train de se produire

• C’est dommage qu’il faille démonter aussi minutieusement une thèse bancale
  L’empiriste pur est aussi éloigné de la réalité que le théoricien pur, et Blow fabrique un argumentaire parce qu’il correspond à son expérience, en ne choisissant que les exemples qui collent à ses griefs et en présentant des exceptions comme des règles