- Bien plus de systèmes qu’on ne l’imagine peuvent fonctionner correctement sur du matériel ancien
- Si une véritable optimisation logicielle est mise en œuvre, il est très probable que cette efficacité puisse être atteinte
- Les signaux de prix du marché liés à des ressources informatiques rares incitent à améliorer l’efficacité logicielle
- Il existe un besoin de faire évoluer les produits existants en microservices basés sur des interpréteurs vers une architecture monolithique construite en code natif
- À l’inverse, sans ressources de calcul très bon marché et extensibles, le développement de nouveaux produits innovants risque de devenir beaucoup plus rare
1 commentaires
Avis Hacker News
On peut soutenir que le marché vend aussi bien des logiciels bogués et inefficaces que des logiciels parfaits, et que l’un des deux est simplement le moins cher à produire ; cela ressemble à l’histoire du « marché des lemons » : le marché traite tous les produits comme s’ils étaient de haute qualité, alors qu’en réalité on sacrifie la qualité pour réduire les coûts. Comme les acheteurs ne peuvent pas distinguer avant l’achat un produit de haute qualité d’un produit médiocre, la demande devient artificiellement similaire pour les deux ; c’est un effet d’asymétrie d’information. Ce phénomène existe déjà, et devient de plus en plus réel avec l’IA : les utilisateurs ne savent pas faire la différence entre une application de machine learning sophistiquée et un lave-linge simplement étiqueté « IA ». Le label IA suffit à créer une prime de prix, donc les utilisateurs paient trop cher leur lave-linge. Faire payer un mauvais logiciel parce que l’acheteur croit qu’il a été « conçu et écrit par des experts » relève fondamentalement de la même logique. Presque tous les logiciels sont écrits à des niveaux IC1-3, et dans la plupart des entreprises, le QA devient à lui seul le seul indicateur d’amélioration de la qualité. Parfois, des stagiaires récitent l’incantation « LGTM » en espérant une amélioration, mais en pratique c’est même rare
J’ai essayé de créer une startup logicielle différenciée par la qualité, persuadé que si le produit était meilleur les gens le remarqueraient et que cela réussirait. En réalité, non. Nous avons grandi, mais trop lentement, au point d’épuiser les fonds avant même d’atteindre la rentabilité. Ce que j’en ai retenu, c’est qu’un coût plus faible, et donc une qualité plus faible, devient un avantage concurrentiel sur un marché concurrentiel. On me le disait déjà à l’université, mais cette expérience me l’a fait ressentir jusque dans les os. C’est ce qui explique pourquoi tout tend vers la médiocrité sur le marché, et pourquoi plus quelque chose devient populaire, plus sa haute qualité se dégrade. Plus un produit change d’échelle, plus la pression pour réduire les coûts augmente. Les gens veulent acheter moins cher, donc quelqu’un finit par réduire les coûts — donc la qualité — pour proposer moins cher. Les entreprises ne paient que le strict minimum pour survivre et faire du profit. Bien sûr, il y a parfois des exceptions, mais au final tout glisse vers une réduction progressive des coûts. Il doit bien y avoir un nom pour ce phénomène ; c’est un peu différent du marché des lemons. Le marché ne s’effondre pas, mais il produit partout une médiocrité stable
Il y a une objection à l’idée que le « marché » vend tous les produits comme s’ils étaient de haute qualité. Ici, la définition de « haute qualité » est cruciale. On dirait que faible performance = faible qualité, mais en réalité, pour des applications jugées peu performantes comme Teams, Slack ou Jira, il existe des concurrents bien plus rapides. Pourtant, si l’on demande à un utilisateur de choisir Weechat à la place de Slack — interface terminal, pas de visioconférence, pas d’emoji — la plupart jugeront le premier de moins bonne qualité. La performance n’est qu’une fonctionnalité parmi d’autres. Le succès initial de Chrome, par exemple, venait de sa rapidité, et les développeurs Python migrent aussi vers uv/ruff pour des gains de performance. Mais si Slack démarrait en 10 ms au lieu de 5 secondes, la plupart des utilisateurs s’en soucieraient peu
Je ne suis pas d’accord avec l’idée que les logiciels inefficaces s’expliquent par une structure de marché des lemons. Cela ne vaut que s’il y a asymétrie d’information. Dans la plupart des cas, les gens se moquent de quelques bugs et veulent surtout un prix plus bas. Si l’on compare avec un processus très rigoureux de QA et de relecture du code par plusieurs ingénieurs, le coût parle de lui-même. À petite échelle, j’ai développé un logiciel pour une petite librairie : je l’ai fait rapidement, sans facturer très cher. Ce n’était pas parfait, mais je corrigeais les problèmes dès qu’ils apparaissaient, et le client savait qu’il faisait une bonne affaire, donc il était satisfait
J’ai utilisé d’horribles portails RH, notes de frais, suivi du temps et assurances dans de grandes entreprises. C’était tellement mauvais que je me demandais vraiment si la personne qui avait signé le contrat avait seulement utilisé le produit. Si mon équipe présentait à des clients un produit rempli de bugs et d’un cauchemar d’UI, ce serait immédiatement un savon, une rétrogradation, voire un motif de licenciement
Le fond du fait que le marché achète bien des « logiciels bogués et inefficaces », c’est que le marché achète du <i>support</i>. Cela vaut aussi pour Google ou les entreprises pauvres en support humain. Le « support » prend de nombreuses formes — documentation, vidéos, billets de blog, personnes qui aident, prise en charge de mon environnement (système d’exploitation, navigateur, etc.), prise en charge de ce que je veux accomplir, etc. Ce qui permet même au pire ERP de survivre, c’est au final la présence de vraies personnes. L’existence ou non du support détermine la ligne de vie du produit. Pour qu’une petite équipe gagne la bataille, il est plus malin de réduire le « besoin de support » et d’apporter le support sur d’autres dimensions. La manière la plus simple est d’ajouter des humains, puis de bien communiquer ses points forts. Chaque type de support est évalué différemment ; c’est comme code open source vs code propriétaire : beaucoup préfèrent le propriétaire s’il y a plus de support, plutôt que du code
Une des grandes raisons pour lesquelles j’aime faire mes courses chez Costco, c’est qu’ils ne vendent généralement pas de la camelote. Leur filtre ne correspond pas toujours à mes critères, mais c’est quand même un filtre de qualité significatif
Même si les utilisateurs pouvaient prendre leurs décisions sur la base de la qualité logicielle et de la performance, si je regarde ma liste d’apps ouvertes, aucune ne peut être remplacée simplement parce qu’une autre est plus performante. Par exemple, Docker, iterm2, WhatsApp : je les utilise chacun pour des raisons précises. Même s’il existait une solution plus rapide, je ne pourrais pas forcément changer. Le simple fait qu’un logiciel réponde à mes besoins dès le départ est un facteur plus important que la performance
99 % des logiciels sont écrits sans tenir compte de la performance. Même sur HN, il existe souvent une tendance à considérer l’optimisation des performances comme taboue. Même des ingénieurs de niveau L4/5 ou plus manquent souvent d’intuition en matière de performance. D’un point de vue business aussi, tant que le matériel peut exécuter le logiciel, on ne se soucie pas d’efficacité. Et même quand ce n’est plus le cas, la priorité est encore d’ajouter du matériel
La structure actuelle du marché est telle que les logiciels bogués et inefficaces dominent parce qu’on peut toujours acheter du matériel pour les faire tourner. Les logiciels se gonflent jusqu’à remplir la capacité du matériel — la loi du « Andy gives, Bill takes away ». Il n’y a donc aucune incitation à produire un logiciel lean et de haute qualité. Mais si un jour on vivait dans un monde où il serait impossible d’obtenir des puces de pointe (par exemple en cas de crise géopolitique, destruction massive d’usines, etc.), alors les logiciels économes en ressources prendraient une grande valeur économique — les logiciels boursouflés ne pourraient tout simplement plus s’exécuter. Carmack dit que dans une telle situation, la marge d’optimisation est suffisamment grande pour qu’on puisse malgré tout faire tourner les logiciels sur des puces anciennes
Un logiciel bien conçu est facile à remplacer. À l’inverse, un amas de spaghetti code rempli de bugs, personne n’a envie d’y toucher, donc il reste pour toujours. Si l’on s’en tient à une pure lecture évolutionniste, c’est le mauvais logiciel qui finit par dominer
Si le marché de l’occasion automobile est un marché des lemons, c’est parce qu’il est difficile de distinguer une voiture bien entretenue d’une voiture proche de la panne. Mais cela ne s’applique pas au marché du neuf, où tout est strictement contrôlé. Le logiciel est toujours vendu neuf. De même que la qualité des voitures a augmenté au fil des décennies, on pourrait améliorer la qualité des logiciels : n’autoriser la vente qu’au-delà d’un certain standard, imposer des rappels en cas de bugs graves, sanctionner la vente délibérée de produits défectueux. C’est ainsi que fonctionnent toutes les autres industries
Avec le Web 2.0, le « bêta perpétuel » et le modèle SaaS, la tolérance des utilisateurs a elle aussi changé. Microsoft a inculqué sur plusieurs générations l’idée que « les logiciels sont forcément cassés ». À force de s’habituer à de mauvais logiciels, tout le monde a fini par moins percevoir la valeur des bons logiciels
J’ai effectivement acheté ce lave-linge avec le sticker IA. Le marketing m’a fait rire, mais le prix était raisonnable, donc je l’ai pris
Je pense qu’il est peut-être seulement question des failles de sécurité. Si Excel ou Photoshop étaient remplis de problèmes de performance ou d’autres bugs, les gens arrêteraient vite de les utiliser. Mais la sécurité, l’utilisateur ne la perçoit pas avant qu’un problème survienne, et même s’il se fait pirater, il ne sait pas forcément pourquoi. Les développeurs n’ont donc pas d’incitation. Pour les performances, une fois un certain seuil atteint, on hésite à investir davantage de ressources dans l’optimisation ; c’est la loi des rendements décroissants
Même si les utilisateurs ne distinguent pas la sophistication de l’IA d’un simple « lave-linge IA » de façade, une bonne IA pourrait justement aider les utilisateurs à surmonter eux-mêmes cette asymétrie d’information. Dès lors qu’on dispose d’un moyen de choisir une bonne IA, le problème peut se résoudre
Je ne pense pas que produire « le logiciel le moins cher » soit forcément moins coûteux. Au niveau startup, du bricolage peut coûter moins cher, mais à grande échelle cela finit au contraire par coûter davantage. Même les compagnies aériennes retirent une olive pour gratter sur les coûts ; alors pourquoi ne serait-il pas efficace de faire optimiser les développeurs ? Nous ajoutons seulement de nouvelles fonctionnalités, mais au final les utilisateurs ressentent surtout que chaque mise à jour ralentit tout. À l’inverse, quand ça accélère, ils applaudissent. Les ingénieurs se comportent comme des MBA et répètent qu’« il n’y a pas de valeur » ; pourtant, la « valeur » d’une correction de bug est très subjective. Le travail des ingénieurs, c’est de corriger les bugs. La marque compte aussi, mais les grandes marques actuelles ignorent leur capital de marque. Sans doute parce que les consommateurs changent peu, mais même en changeant on n’obtient souvent qu’une nouvelle UI à apprendre en plus (même Apple n’est plus intuitif)
Le monde actuel pourrait probablement tourner sur du matériel ancien, mais comme les CPU et le hardware deviennent de toute façon toujours plus rapides, il n’y a pas vraiment de raison de rendre le code plus efficace
Le problème d’asymétrie d’information peut être surmonté avec les produits FOSS ou propriétaires à « source partagée ». En regardant directement le code, on peut voir s’il est globalement de bonne qualité. Même sans trouver de bug concret, on peut juger s’il existe une culture de développement consciencieuse à partir de la longueur des fonctions, des commentaires, du naming, etc. Franchement, quand on voit des schémas de base de données catastrophiques dans des produits propriétaires chers, on n’a pas confiance
Un mauvais logiciel coûte plus cher à produire — et à maintenir — sur le long terme
C’est pour cela qu’on dit que la marque joue le rôle de gardienne de la qualité
De la même façon que la loi interdit de vendre des aliments toxiques, périmés ou bourrés d’additifs créant une dépendance, il devrait y avoir une régulation du logiciel. Mais jusqu’au RGPD, la régulation était presque insignifiante, et même aujourd’hui les violations restent monnaie courante
Depuis 1980, la puissance de calcul a augmenté d’environ 1000 fois. Si l’on estime à 5 % la perte de performance due aux vérifications dynamiques des bornes de tableaux (et en réalité c’est probablement bien moins), alors même avec ces vérifications nous aurions quand même eu des ordinateurs 950 fois plus rapides. Si l’on retournait en 1980 pour demander de choisir entre « un ordinateur 950 fois plus rapide avec moins de bugs et un débogage plus facile » et « un ordinateur 1000 fois plus rapide mais toujours plein de bugs et plus difficile à déboguer », la plupart choisiraient probablement le 950x. Mais au final, nous avons choisi le 1000x. Personnellement, je pense que les partisans du 1000x ont gâché la situation
Sauf que cette performance 1000x n’a pas été dépensée dans les vérifications de bornes, mais dans des couches infinies d’abstraction et d’inefficacité
J’ai déjà forcé un fournisseur à faire tourner son logiciel lent et bogué sur un Sparc 20. Résultat : ils l’ont optimisé, et cela a servi de base à leur réussite commerciale. L’optimisation est un avantage concurrentiel
Cela n’est vrai que si l’on prend 1980 comme point de départ. Dans une vidéo récente, le résumé était : « les ordinateurs d’aujourd’hui ne sont pas tellement plus rapides que ceux d’il y a 20 ans, sauf si l’on optimise spécialement pour le constater ». L’auteur négligeait les optimisations de compilateur et autres, mais l’idée était que le gain réel de performance a été bien plus modeste qu’on ne l’imagine, à peine un facteur 2 sur 15 ans
Dire que les vérifications de bornes coûtent seulement 5 % suppose des algorithmes très simples. Tous ne le sont pas. Selon le nombre d’opérations, introduire ces vérifications peut multiplier le coût par 3 ou 4. Pour certains usages, les imposer ferait perdre toute compétitivité au langage. Dans la plupart des cas, cela n’a pas d’importance, mais il serait souhaitable d’avoir un mode sûr et un mode général distincts
Si l’on ne pense qu’aux vérifications de bornes, le coût est faible, mais le surcoût des langages sûrs dans leur ensemble est bien plus élevé. Les langages à GC peuvent multiplier l’usage mémoire par plusieurs fois
Il ne faut pas oublier la loi des grands nombres. Une perte de 5 % sur un système isolé n’est pas dramatique, mais si cette perte s’accumule sur tout l’environnement informatique mondial, l’impact devient énorme
Je suis d’accord avec la nature humaine qui privilégie les gains à court terme, mais les vérifications dynamiques de bornes ne résolvent pas à elles seules les problèmes de sécurité. La solution ultime n’existe pas encore
La raison fondamentale pour laquelle nous en sommes là, c’est que nous sommes liés au navigateur
La première réponse est en fait la bonne : le simple fait que le C reste massivement utilisé montre bien que le problème fondamental est une absence d’efficacité dans les couches inférieures de la pile
Le chiffre de « 5 % » paraît douteux. On ne sait pas sur quelle base le coût a été calculé. J’aimerais savoir si vérifier à chaque insertion dans un tableau ne ferait pas en réalité plus que doubler le coût
La plupart des langages de programmation actuels prennent déjà en charge par défaut la vérification des bornes de tableaux
Cela me rappelle l’époque où Node.js venait d’arriver : relier le code client et serveur était un énorme avantage, mais aujourd’hui c’est devenu un cauchemar de sécurité. Les langages minimaux avec peu de base de code ont aussi leurs avantages
Si l’on avait compris plus tôt qu’une seule chaîne peut contenir des données de l’ordre du gigaoctet, les chaînes terminées par NUL auraient peut-être disparu, et tout le monde aurait moins souffert
Les 1000Xers qui profitent réellement d’un produit 1000 fois plus rapide sont au contraire une infime minorité ; les logiciels desktop que voit l’utilisateur moyen restent lents
En réalité, c’est plutôt 100 000x plus rapide : juste l’horloge, c’est 1000x ; les cœurs, 10x ; les instructions elles-mêmes, via AVX et autres, encore 10x ; architecturalement, on est plutôt à 1 à 2 millions de fois plus rapide. Et pourtant, cela ne se ressent pas
Je cite Robert Barton, qui qualifiait ce genre de personnes de « grands prêtres d’un culte ignoble »
Depuis 1980, oui c’est rapide ; mais si l’on regarde depuis 2005, c’est plutôt un gain d’environ 5x
Horloge 2000x, IPC via SIMD et autres jusqu’à 80x, plus les cœurs : au final on est bien à 1 ou 2 millions de fois plus rapide. Pourtant, la plupart des programmes sont écrits par des gens qui pensent simplement « si ça fonctionne, alors c’est cette vitesse-là ». Très peu réfléchissent vraiment à l’optimisation, y compris parmi les utilisateurs de HN
En 2001, on aurait dû prendre un CPU à 1 GHz comme référence d’exécution pour les logiciels de base. Mon expérience de l’IA a aussi été très décevante. J’attendais d’un LLM qu’il sache au moins faire correctement de la transformation de langage, de l’optimisation de code, etc., mais en réalité ce n’est pas le cas. J’ai même demandé à une IA de porter du code Unix
sedvers un langage JVM ; au-delà des choses élémentaires, elle échouait totalement dès qu’on montait au niveau intermédiaire. Au fond, toute cette dynamique vise davantage à « réduire les emplois » qu’à améliorer la qualité logicielle. L’IA va produire encore plus de mauvais logicielsC’est exactement JavaScript, et l’avenir de l’utilisateur
En travaillant chez Google (et Facebook), j’ai bien vu à quel point le matériel était bon marché et à quel point l’optimisation du code n’avait le plus souvent pas de valeur. Il y a déjà plus de dix ans, chez Google, la gestion des ressources des datacenters était indispensable et chaque projet avait un budget. On comparait les coûts relatifs des ressources — CPU, HDD, flash, etc. — en les échangeant les unes contre les autres. Même si la flash coûtait 20 fois plus cher que le disque, elle était souvent moins chère en pratique si l’on tenait compte du vrai goulot d’étranglement. Ces ressources étaient aussi converties en temps d’ingénieur logiciel (1 SWE = 1 année-personne). Si une optimisation ne permettait pas d’économiser plus de 5000 cœurs CPU, elle coûtait plus cher qu’elle ne rapportait. L’optimisation n’avait de sens que pour de très gros projets ; pour le reste, le code était remplacé si vite qu’optimiser ne servait à rien. Et du point de vue de l’utilisabilité Web, l’interface à la souris est extrêmement inefficace ; les terminaux textuels d’il y a 30 ou 40 ans étaient bien plus efficaces. J’espérais que « le Web se standardiserait et passerait à l’étape suivante », mais cela n’est pas arrivé. On a toujours un nouveau framework chaque semaine, et on réimplémente même les mêmes scrollbars sans compatibilité matérielle. Je ne sais pas comment résoudre ce problème
À mon avis, c’est un raisonnement qui ne vaut que dans les entreprises où le coût d’ingénierie est élevé, avec de grosses marges et de multiples projets. Dès qu’une entreprise a un peu de marge, il vaut mieux affecter des ingénieurs à l’optimisation. En pratique, chaque entreprise copie simplement Google, prend des décisions sans rapport avec sa propre logique économique, et cela explique beaucoup de problèmes
Moi aussi je viens de Google. Google parle surtout d’optimisation de l’usage CPU, mais en réalité deux choses étaient énormément mises en avant : la latence et le taux global d’utilisation des serveurs. Les deux étaient des KPI majeurs pour les organisations supérieures, donc on y consacrait énormément de ressources d’ingénierie. Plus on a de machines, moins on veut les laisser inactives, et pour les activités sensibles à la latence, on essaie de gagner ne serait-ce que quelques millisecondes
Le raisonnement de Google tient précisément parce que le coût par cœur y est élevé. Pour la grande majorité des entreprises ordinaires, cela ne s’applique pas du tout. C’est un modèle qui ne fonctionne qu’à l’échelle de Facebook/Google/Netflix et consorts
Si Google a conçu de meilleurs formats de compression et de sérialisation binaire, c’était aussi pour améliorer sa propre rentabilité
En lisant le titre de l’article, je pensais que Carmack critiquait l’optimisation logicielle sur matériel peu puissant. En fait, pas du tout : il parle d’une expérience de pensée où le progrès matériel s’arrête, et conclut que « sans informatique bon marché et facilement extensible, il y a moins de produits innovants »
C’est lié au fil posté hier
Concernant cette conclusion — « sans informatique bon marché et extensible, l’innovation diminue » — en réalité nous n’avons presque plus eu d’innovation depuis le smartphone, et comme le capital dépend uniquement des progrès matériels, les nouveaux produits finissent par ne plus être fondamentalement différents des précédents
Personnellement, je ne suis pas d’accord avec cette thèse. Même si le développement de fonctionnalités s’arrêtait un temps, l’innovation reviendrait après une phase de préparation suffisante. Il y aurait un creux, mais pas une baisse durable
L’idée clé, c’est que le « bloat » n’est pas un simple gaspillage : c’est un gain de productivité du développement motivé économiquement. Accroître la productivité avec des langages moins complexes permet d’embaucher plus de monde et de réduire les coûts
Si l’on pouvait prolonger de 5 ou 10 ans la durée de vie du matériel au lieu d’organiser son obsolescence, on réduirait énormément les déchets électroniques, l’usage de minéraux rares et les émissions de gaz à effet de serre. Mais le marché du logiciel ne supporte pas le coût de ces externalités. Après la sortie, tester, corriger et itérer coûte bien moins cher qu’une conception de long terme. Une partie de l’industrie du jeu a trouvé la formule « haute performance + revenus », mais ce n’est pas largement répandu. Les logiciels enterprise et grand public se préoccupent moins des performances que du seuil de tolérance des utilisateurs ; ils visent juste le minimum requis. À cause de l’ajout continu de nouvelles fonctionnalités et du changement permanent, il est difficile d’accorder de l’attention à la performance, et les budgets gardent une marge pour les taux d’erreur. Contrairement à une sortie dans un état relativement « prêt », la complexité et le risque de changement sont beaucoup plus grands
Depuis plus de dix ans, nous faisons tourner l’intégralité du moteur d’appariement d’une place de marché sur un seul thread. Pour ce qui est du traitement sérialisé des ordres, la puissance de calcul n’a pas augmenté si vite que ça. À moins de viser plusieurs millions de TPS, il n’est même pas nécessaire de passer à un cluster. Au contraire, on peut simplifier la conception et tout faire tenir sur une seule machine
C’est vraiment frustrant. Beaucoup d’architectes système ont complexifié les systèmes juste pour laisser leur empreinte personnelle, et n’ont produit au passage qu’une nouvelle classe de problèmes. Le design initial suffisait déjà à couvrir la plupart des besoins, et avec la puissance de calcul locale actuelle, une seule machine suffit très bien dans bien des cas
Je me demande pourquoi on ne peut pas paralléliser l’appariement des ordres — est-ce qu’en appliquant une réduction de log similaire à un tri cela deviendrait possible ? Ou bien est-ce parce qu’en dehors du tri, il y a finalement peu d’autres calculs dans le processus de matching ?
Pour un traitement simple, un seul thread suffit ; mais si chaque transaction demande des calculs complexes, ce n’est plus possible. Cela dit, je manque de connaissances métier pour voir quel type de traitement serait réellement aussi complexe
Si les outils de développement avaient continué à progresser, on pourrait encore créer facilement des GUI totalement natives comme à l’époque des RAD, alors qu’aujourd’hui c’est Electron qui domine. On se retrouve avec plusieurs navigateurs Web installés, chacun étant une variante de Chromium
Au fond, c’est une question économique d’allocation des ressources : faut-il faire passer le temps des développeurs à optimiser le logiciel, ou à créer de nouvelles fonctionnalités ? Si la seconde option rapporte davantage, c’est elle qui sera choisie. Inversement, si l’optimisation importe plus, le comportement changera en conséquence
Je suis d’accord pour dire que c’est une question économique, mais au fond c’est aussi un cas où les entreprises logicielles externalisent leurs effets négatifs sur l’ensemble de la société. Elles ne se soucient pas de la consommation d’énergie supplémentaire, du gaspillage ou de l’augmentation des déchets électroniques
C’est une structure où l’on refourgue la dette technique et financière aux autres, tout en produisant énormément de déchets. Dans beaucoup de cas, l’optimisation n’aura peut-être pas d’intérêt concret, mais la pratique consistant à ajouter simplement des serveurs reste regrettable
Dire que « l’ajout de fonctionnalités est plus important » dépend des cas. Personnellement, je n’utilise presque aucune des nouvelles fonctions récentes de macOS, Windows ou Android ; je valorise davantage un environnement efficace et la sécurité. Pour les logiciels de design aussi, j’attends plus des gains d’efficacité que de nouvelles fonctions. Il m’arrive même de vouloir retrouver Illustrator/Photoshop d’il y a 10 ans. Dans les logiciels de musique, de nouvelles fonctions peuvent certes répondre à de vrais besoins, mais si elles nuisent à l’efficacité elles sont malvenues. Pour l’édition de code, VSCode me suffit largement, et j’aimerais surtout qu’il devienne plus rapide et plus léger
Dans ma vie, l’efficacité est très importante. Par exemple, quand je vais à la cuisine chercher quelque chose, j’emporte toujours aussi des déchets ou de la vaisselle pour éviter un second trajet. Le logiciel, c’est pareil. Mais entre « passer du temps d’ingénieur coûteux à optimiser » et « ajouter de la RAM ou d’autres ressources », la seconde option est presque toujours moins chère. Ce n’est que lorsque le problème devient assez gros que l’optimisation devient rentable. Le marché finit par arbitrer ce qui est préférable. Si les gains liés à l’ajout de matériel diminuent, alors on basculera vers l’optimisation. On n’en est pas encore là parce que la loi de Moore n’a pas encore complètement touché sa limite
Au fond, c’est une question de demande. Si les consommateurs accordaient plus d’importance à des logiciels plus rapides, ils accepteraient de payer plus cher ; mais en réalité, même si les performances sont moins bonnes, ils choisissent souvent l’option moins chère
C’est exactement la définition de l’enshitification
Les applis Electron suscitent beaucoup de plaintes sur les performances, mais c’est l’innovation clé qui a rendu un environnement de travail supportable sur laptop Linux. Par exemple, on peut rejoindre facilement une réunion Teams sans rien installer. Tout le monde peut regretter l’optimisation du code de Winamp, mais en pratique l’accessibilité des applis Electron est commode
En jouant récemment à Balatro, j’ai eu cette impression : c’est encore un jeu qui ne fait que des calculs simples et des graphismes simples, qui aurait probablement pu tourner sur du matériel des années 90 (Pentium II + 3dfx), et pourtant sa configuration minimale continue de monter. Je suis frappé par le fait qu’il demande des spécifications excessives, au point de sembler fait seulement pour des laptops récents