L’emacsification du logiciel
(sockpuppet.org)- Grâce aux agents IA, il est désormais possible de créer en quelques heures des applications natives personnelles, ce qui déplace le logiciel vers un modèle de personnalisation à la Emacs
- MDV.app est un visualiseur Markdown pour macOS, avec recherche, indexation SQLite FTS, signets, table des matières et mémorisation de position implémentés en quelques heures
- Le problème des applications Electron qui embarquent chacune leur copie de Chromium et la difficulté du développement d’interfaces natives étaient importants, mais Claude maîtrise bien SwiftUI
- Comme dans la culture Emacs, on voit se multiplier des outils ultra-spécifiques qui résolvent les irritations individuelles, et la valeur des idées, des observations et des prompts augmente par rapport aux produits finis
- Le codage avec agent facilite l’ajout d’une bonne UI aux side projects et aux outils en terminal, et transforme la création d’interfaces natives en activité plaisante
Pourquoi j’ai créé moi-même un visualiseur Markdown
- En développement logiciel, Markdown était déjà une sorte de langue commune avant les LLM, et avec le retour des outils TUI à l’ère des agents, l’expérience consistant à faire défiler sans fin du Markdown dans le terminal est devenue encore plus pénible
- Côté visualiseurs Markdown en TUI, il existe glow de Charm et Markless créé par Josh ; Markless prend aussi en charge la navigation dans la table des matières, mais le terminal utilise généralement une police à chasse fixe, fatigante pour de longues lectures
- Sur macOS, il existe des éditeurs Markdown à interface graphique comme Obsidian, Typora et Bear, agréables à lire, mais ce sont tous des éditeurs ; dès qu’on ouvre un fichier
.md, l’environnement d’édition existant et la disposition des fenêtres s’en trouvent perturbés - Les visualiseurs Markdown de l’App Store paraissent crédibles au premier abord, mais à l’usage, on découvre qu’ils n’ont pas de recherche, qu’ils incluent des achats intégrés, ou qu’ils ne permettent pas de copier dans le presse-papiers le texte sélectionné
- En 2026, plutôt que de continuer à chercher un visualiseur acceptable, l’auteur a changé d’approche en jugeant qu’il était possible de générer avec un agent IA le visualiseur Markdown souhaité
MDV.app, créé avec Claude
- MDV.app a été réalisé en quelques heures jusqu’à atteindre un niveau supérieur à celui des visualiseurs Markdown spécialisés trouvés sur l’App Store, avec environ 30 minutes d’interaction réelle
- Un ancien MacBook a été préparé avec Xcode et git, l’environnement Claude a été configuré, et un travail préparatoire sur Swift et le design macOS avait commencé plusieurs semaines auparavant
- MDV n’est ni la meilleure application macOS ni un logiciel particulièrement exceptionnel, mais c’est un visualiseur Markdown dédié pour macOS largement suffisant, qui améliore nettement le confort au quotidien
- Les principales fonctions de MDV sont la sélection et copie de texte dans les documents, la recherche de chaînes fixes, l’indexation SQLite FTS de tous les fichiers Markdown d’un historique éditable, les signets au clavier et la navigation dans la table des matières
- Lorsqu’on passe d’un document à l’autre, l’application mémorise la position, la restaure après redémarrage, et fournit des thèmes de couleurs ainsi qu’une typographie agréable qui ouvrent immédiatement l’environnement de lecture voulu quand on clique sur un fichier
.md
Les limites d’Electron et l’évolution des interfaces natives
- À chaque réception d’un message Signal, l’écran scintillait, et cela ne s’arrêtait pas tant que l’application Signal n’était pas masquée explicitement, avec un clignotement subtil allant jusqu’à la migraine
- Ce phénomène vient du fait que Signal est une application Electron : elle ressemble à une application macOS native, mais repose en réalité sur une copie de Chromium qui affiche une page web cachée
- Presque toutes les applications UI sorties au cours des dix dernières années semblent embarquer chacune leur copie de Chromium, et Electron, sans être idéal, est resté une option suffisamment acceptable
- Créer une véritable interface native a historiquement été difficile, il était même ardu de trouver des profils moyens à qui confier ce travail, et les bons développeurs macOS natifs étaient rares
- Claude dépasse le simple remplacement d’un développeur SwiftUI moyen : il est perçu comme un développeur qui maîtrise réellement SwiftUI
Comment la culture Emacs déborde sur l’ensemble du logiciel
- MDV n’est pas tant un produit fini recommandé à l’installation qu’un objet dont on peut voler des idées pour faire mieux, comme un utilisateur d’Emacs regardant une configuration
.emacsbrillante - Dans la culture Emacs, les utilisateurs de longue date créent en elisp des applications qui résolvent des irritations personnelles initialement liées à l’édition de texte, et ces outils s’étendent au-delà de ce qu’il serait raisonnable d’attendre d’un éditeur de texte
- /r/emacs relève davantage d’une culture de la démonstration que d’une promotion de produits à la Product Hunt ; il existe des paquets elisp largement utilisés, mais à l’exception de Magit, chacun a tendance à les refaire dans une version qu’il juge plus brillante
- La faiblesse de la culture Emacs tenait au fait que, sauf Magit, les paquets étaient en général laids, lents, et porteurs d’une mauvaise expérience utilisateur qu’on ne découvrait souvent qu’après une longue exposition à elisp
- Les agents IA ont poussé cette culture hors d’Emacs, et dès lors qu’ils peuvent accéder à l’écran et aux entrées, ils deviennent capables de créer de façon fiable des interfaces natives ; celles-ci quittent alors le domaine des programmes emballés de manière professionnelle pour entrer dans celui de la personnalisation individuelle
Le potentiel des outils natifs personnels
- Le logiciel emacsifié sera en grande partie un logiciel personnel utile surtout à son créateur, et l’on verra se multiplier des outils oubliés, comme ces vieux programmes elisp restés dans
.emacs - Il arrivera parfois que certains de ces programmes franchissent cette frontière et deviennent assez utiles pour être installés par plusieurs personnes, mais même alors, l’essentiel ne sera pas forcément l’artefact distribué ni le code source
- Si l’agent a écrit tout le code SwiftUI, alors l’idée et l’observation selon lesquelles « on peut faire ce genre de chose et cela fonctionne bien » deviennent plus importantes qu’une lecture détaillée du code source
- Dans ce type de logiciel, les prompts peuvent avoir plus de valeur que le code source, et pour ceux qui ont l’habitude de mettre directement les mains dans le logiciel pour le faire tourner, tout devient programmable non seulement techniquement, mais aussi pratiquement
- Parler de « construire » un logiciel créé par agent semble surestimer l’effort fourni ; la sensation réelle se rapproche davantage d’une configuration sur une plateforme soudain bien plus configurable
- Les développeurs qui utilisent l’IA sont enfin en train d’achever des side projects aléatoires accumulés depuis des années
- Désormais, ces outils ultra-spécifiques ne se contentent plus d’aboutir : ils peuvent aussi avoir une UI agréable à utiliser, ce qui affaiblit une partie des raisons qui faisaient accepter auparavant l’interface maladroite d’Emacs
- Le potentiel d’amélioration beaucoup plus simple des applications terminal grandit, et des outils comme
iostat,iostatsur plusieurs hôtes, oubpftracepeuvent être rendus sous une forme plus facile à comprendre - La complexité que Brendan Gregg devait accepter pour les visualisations terminal de
bpftracen’a plus à être subie telle quelle, et il existe déjà un exemple réalisé directement - En tant que chercheur en vulnérabilités, l’auteur a trouvé intéressants les progrès du développement d’exploits fondé sur le codage avec agent au premier semestre 2026, mais pour la plupart des gens, ces évolutions inspiraient surtout de l’inquiétude ; en revanche, le fait que créer des interfaces natives soit devenu amusant relève presque d’une bonne nouvelle sans ambiguïté
- Il recommande de créer des outils excessivement spécifiques adaptés à ses propres problèmes, d’en profiter un moment, puis de les partager — ou mieux encore, de partager des captures d’écran et les prompts utilisés
1 commentaires
Commentaires sur Hacker News
Je pense qu’on peut désormais laisser les nerds se réapproprier des domaines qui sont devenus pour la plupart des logiciels spécialisés prépackagés : applis de podcasts, applis d’écoute musicale, lecteurs de flux, clients Bluesky, applis de notes, applis de signets/lecture différée sur desktop, chat et messagerie, suivi du temps, gestionnaires de recettes, etc.
Avec Claude, on peut largement obtenir un résultat meilleur que les alternatives. Ce ne sera peut-être pas la meilleure appli ni une appli compétitive à l’échelle mondiale, mais on peut créer une appli bien mieux adaptée à sa propre façon, particulière, de travailler
Music.app est pénible à utiliser, et Apple a déjà extrait les fonctionnalités de base dans MusicKit il y a longtemps. Le vrai produit, c’est maintenant MusicKit, donc je ne sais pas pourquoi on utilise encore Music.app, et c’est un changement nouveau
Une expérimentation en ce sens : https://github.com/dharmatech/9social
Le premier client a été écrit pour plan9, et il fallait faire ainsi pour garder l’honnêteté du design. Si ça tourne sur plan9/rc/acme, alors ça se tient
La démo vidéo est ici : https://youtu.be/q6qVnlCjcAI, et l’implémentation actuelle fait moins de 3000 lignes de code
Puisqu’on parle d’Emacs, 9social a été très inspiré par le projet Emacs Org Social : https://github.com/tanrax/org-social
C’est une interface inachevée, basée sur un tableur, pour saisir son temps. Je l’ai faite pour du conseil, mais je ne suis jamais allé jusqu’au stockage des données. Il y a un petit algorithme sympa qui peut gérer presque toutes les façons naturelles dont les gens saisissent leur temps ; je l’ai fait parce que je déteste que les time trackers existants forcent une saisie structurée : https://stackoverflow.com/a/49185071/59087
Gestionnaire de recettes : https://repo.autonoma.ca/repo/recipe-fiddle
À l’ère des LLM, il sera bien plus facile de classer les ingrédients et de formater le tout en TeX pour une publication PDF. L’idée de ce projet était de permettre de copier-coller presque tel quel une recette web ou un scan manuscrit pour que ce soit formaté automatiquement
Il n’y avait aucune appli sur F-Droid qui remplissait toutes ces conditions, donc j’ai simplement fabriqué moi-même un APK
Je pense qu’avec l’ère des LLM, produire du logiciel est devenu si facile que tout est devenu comme un fichier .emacs. Autrement dit, chaque personne se retrouve avec un patch de logiciel totalement personnel et personnalisable à l’infini
Comme le dit l’OP, il est devenu plus facile de fabriquer sa propre solution que d’installer ou d’apprendre l’existant
Lisp est aussi une bonne analogie. Une vieille critique des macros Lisp était que chaque programmeur finissait par transformer le langage en son propre dialecte privé, au point que plus personne d’autre ne pouvait le lire
Ça m’a aussi rappelé le texte de 2007 de Mark Tarver, « The Bipolar Lisp Programmer » : https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
Il parlait du « brilliant bipolar mind », ce qui rejoint de façon intéressante ce qu’on appelle souvent aujourd’hui, ironiquement ou non, la psychose IA
Dans le texte de Tarver https://www.marktarver.com/bipolar.html, il explique que le « throw-away design » de la communauté Lisp convient parfaitement au BBM. Lisp permet de bricoler quelque chose trop facilement, si bien que chacun produit sa propre solution et estime que c’est suffisant dès lors que ça lui revient à lui
En revanche, en C/C++, produire quelque chose de significatif est si difficile que cela devient un accomplissement, ce qui motive à documenter et à collaborer. Du point de vue d’un employeur, 10 personnes qui communiquent, documentent et travaillent ensemble sont plus attractives qu’un seul hacker Lisp difficile à remplacer
Quand la production devient facile, la consommation devient le goulot d’étranglement, et le partage devient difficile. Un fichier .emacs est personnel comme une empreinte digitale : on peut en reprendre des morceaux, mais on n’a pas envie d’utiliser celui de quelqu’un d’autre tel quel
Plus ces patchs deviennent personnalisés, plus il devient difficile pour les autres de les comprendre ou d’avoir envie de les utiliser. Il y a un coût cognitif, mais aussi une gêne comparable au fait de porter les vêtements d’autrui. Plutôt que de parler de psychose IA, on pourrait appeler ça un solipsisme IA
Dans le logiciel, la gestion de configuration devient la partie difficile. Comment partager et versionner la source ? Qu’est-ce que la source ? Le prompt ? L’OP finit lui aussi par pencher vers l’idée de partager des captures d’écran et des prompts plutôt que du code
Même sur Show HN, il a lancé un ballon d’essai en disant que puisque le code généré n’est plus vraiment la source, il faudrait partager les prompts, mais cela a suscité beaucoup de rejet chez ceux qui s’y connaissent : https://news.ycombinator.com/item?id=47213630
La pression que subit GitHub vient forcément aussi de cette évolution. On ne sait pas encore à quoi ressemblera son successeur, mais il finira par devenir nécessaire. Pour l’instant, on dirait encore le stade de la calèche sans chevaux
Ce qui importe encore davantage, c’est le travail d’équipe. Si tout le monde est BBM, ou si chacun de nous se retrouve avec une armée frénétique de BBM générant 24 h/24 uniquement pour lui, comment travaille-t-on ensemble ? Comment ces patchs communiquent-ils et interopèrent-ils ? Une équipe de solipsistes IA sonne comme une contradiction
Les équipes et startups à la pointe du développement piloté par IA et orienté agents doivent déjà être en train de vivre concrètement ce problème. C’est la question de savoir comment composer mon code généré et ton code généré. À cause de ces frictions, il est probable qu’on doive rendre une partie des gains de productivité du code généré
C’est dommage qu’on n’en parle pas davantage en public. Personne ne veut être le premier à se rasseoir pendant l’ovation obligatoire, mais si on fait comme si c’était un déjeuner gratuit sans inconvénients, la discussion devient ennuyeuse et l’évolution ralentit
Si ceux qui font le travail le plus sérieux et le plus avancé avec ces nouveaux outils ne parlent pas des inconvénients, alors les critiques ne resteront que du côté cynique qui considère que l’IA n’a aucune valeur pour le développement logiciel. Il semble plus difficile de parler de bugs en hausse ou de stagnation de productivité que d’extinction de l’humanité
J’aimerais savoir ce qui se passe réellement, comment les gens réagissent et comment cela évolue avec le temps. Je me dis que je devrais peut-être aller à des meetups
Un article connexe portait d’ailleurs le titre « Easier to Write, Harder to Read » : https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
Pourquoi lirais-je le produit d’une conversation précise avec un LLM ? Il suffit que je connaisse le sujet, et je peux avoir une meilleure conversation moi-même
Ces logiciels sont un peu pareils. Il peut y avoir un peu de goût personnel, mais l’important, dans la plupart des cas, ce sont les idées et la recette
Ce serait bien d’avoir un fil mensuel « Vibe HN »
Je serais curieux de voir une vidéo montrant qu’on peut fabriquer un WhatsApp sur mesure en moins de temps que cela. Et encore, ça ne commence même pas à traiter le problème d’attirer d’autres personnes vers une messagerie bricolée sur le moment
Maintenant, c’est plutôt : « je vais mettre ce ticket dans Claude, toi essaie avec Copilot et comparons les résultats » ou « je fais une PR avec mon résultat brouillon, et toi relis-la avec ton outil ». Honnêtement, cela paraît presque vide de sens et le pair programming est complètement mort
Qui a envie de regarder tourner plusieurs agents, corriger des problèmes dans différents worktrees et réparer des incohérences dans
agents.md?On pousse vers des pipelines cloud totalement autonomes, auto-opérés, mais la direction semble essayer discrètement de freiner. Il y a sans doute cette compréhension simple que le jour où l’on prouvera que ça peut réellement voler, certains perdront des positions confortables
UNIX n’était pas un produit, mais un environnement optimisé pour construire des outils et résoudre de vrais problèmes, et ces outils étaient écrits en C. Pendant ce temps-là, les BBM étaient sans doute occupés avec Lisp à Boston
C++ est une histoire complètement différente, et là il faut un IDE
Si Emacs a cette nature, c’est parce qu’il utilise Lisp. Cette tendance générale selon laquelle les programmeurs se mettent tous à tout fabriquer eux-mêmes a été observée avec Lisp, et on a appelé cela The Lisp Curse
C’est une malédiction parce que les programmeurs cessent de collaborer. Chacun devient un magicien enfermé dans sa propre tour, le progrès global s’arrête et une époque sombre s’installe
Oui, l’ère des LLM a bien permis de créer du logiciel personnel
Mais, franchement, le temps passé avec Emacs ne m’a pas appris à faire du logiciel personnel. Ma config Emacs était extrêmement fragile, et essayer de l’utiliser à la fois sur Windows et macOS relevait du cauchemar
Mon projet d’université était écrit sous la forme d’un mélange bizarre entre org-mode et je ne sais quel workflow pour produire de beaux fichiers LaTeX, et aujourd’hui je serais incapable d’expliquer comment le recompiler. Si je devais le refaire, je demanderais probablement à un LLM de le traduire directement en LaTeX
Dans ma vie, j’aimerais avoir le moins de maintenance possible, et tout fabriquer soi-même n’est pas toujours compatible avec cet objectif
J’ai en revanche déjà réécrit une application NETFX en Rust. Les 20 minutes d’installation m’agaçaient : https://github.com/bevan-philip/wlan-optimizer
Le travail quotidien d’un programmeur consiste à modifier le comportement de systèmes informatiques, qu’ils soient locaux, distants, cloud, embarqués, etc. Les exigences changent, le périmètre fluctue, l’espace des problèmes évolue, et la sédimentation est inévitable
Il faut donc continuer à s’adapter, et son propre plan de contrôle doit aussi suivre le changement. Le cœur du sujet, c’est l’automatisation. Tous les petits agacements peuvent et doivent être automatisés. Cela implique de remodeler sans cesse son workflow, donc de maintenir en continu ses outils, mais pas sous la forme d’une maintenance réactive et pénible
Être programmeur et ne pas vouloir fabriquer en continu du logiciel pour soi-même, c’est une illusion. C’est comme un cuisinier qui allume le feu au restaurant mais ne prendrait même pas un couteau chez lui
Emacs, c’est la cuisine personnelle du cuisinier. Il y a une maintenance réactive, comme réparer des pannes ou suivre les changements, et une maintenance générative, qui consiste à façonner ses outils à mesure que sa compréhension évolue. Un programmeur devrait détester la première et être attiré par la seconde
Emacs convient presque de manière unique à cette maintenance générative, parce que les outils et le travail y partagent le même tempérament
On se plaint souvent qu’Emacs « demande trop de travail de configuration », mais cela signifie généralement « je ne veux pas investir avant d’avoir reçu de la valeur ». Ce n’est pas une stratégie judicieuse à long terme. Il vaut mieux voir Emacs comme un outil universel qui réduit la charge totale de maintenance sur toute une carrière et toute une vie
Les configurations Emacs ou VIM sont de simples fichiers texte qu’on peut ouvrir avec un éditeur ordinaire et modifier selon ses besoins, en sachant où se trouve quoi. Ma config VIM a 20 ans, et il y a seulement 1 ou 2 ans que j’ai abandonné la gestion manuelle des paquets pour utiliser un gestionnaire de plugins
Il n’y a là ni gatekeeper ni dépendances
À l’inverse, la méthode actuelle exige soit de payer 20 à 200 dollars à une entreprise tierce, soit d’avoir un GPU assez puissant pour faire tourner tout ça en local, puis d’écrire des instructions dans un fichier texte et de les réviser sans fin jusqu’à obtenir ce qu’on veut
On ajoute ainsi soi-même des dépendances, et si l’ensemble devient trop emmêlé pour être relu humainement, cette dépendance deviendra une dépendance forte. Que ce soit un GPU coûteux ou l’envoi de données à une entreprise qui doit satisfaire ses actionnaires, cela revient au même
Il faut distinguer en quoi les deux choses diffèrent réellement, et quel est le coût véritable que nous payons
L’idée de logiciel personnel, c’est-à-dire écrire des programmes pour soi-même, était la vision originelle de l’informatique domestique dans les années 1960
Le PC n’avait pas été anticipé exactement sous cette forme, mais on imaginait que tout le monde aurait un terminal informatique chez soi et écrirait les programmes nécessaires à ses propres besoins. On pensait que programmer deviendrait suffisamment facile pour que n’importe qui puisse l’apprendre
Nous n’en sommes pas encore là, mais les LLM nous en rapprochent
L’idée est que des non-spécialistes puissent créer des logiciels intéressants dans des environnements de création bien conçus, composés d’éléments réutilisables et de métaphores faciles à comprendre. Il faudrait avoir retiré les couches de complexité accidentelle ou surconçue
Même dans cette vision, le logiciel demande un raisonnement logique rigoureux, mais la corvée qui consiste à traduire cette pensée en code exécutable serait bien moindre. Plus de cauchemars de toolchains ni de build systems
À la place, nous avons fabriqué des modèles trop puissants auxquels on fait réciter et recombiner des incantations complexes. Mais la complexité est toujours là, et elle reste opaque pour les non-spécialistes
Les LLM pourraient malgré tout aider à en retirer une partie. Il reste possible d’aller vers un monde où les logiciels générés par LLM sont faciles à comprendre et à modifier directement par les individus, et cela pourrait très bien compléter l’univers des LLM
Ce n’est pas une question de possibilité, mais de calendrier : au plus 10 ans, probablement bien moins. J’ai déjà des proches qui ne savent pas coder et qui font ce genre de choses
Cette informatique du futur est vraiment enthousiasmante, et incroyablement émancipatrice
Mon appli Swift actuelle fait 15 000 lignes, dont 5 000 de tests et 10 000 d’implémentation. Elle est presque terminée et fait maintenant ce dont j’ai besoin. Cela m’a pris 20 heures
Je n’avais jamais fait de Swift, donc si j’avais dû la faire moi-même, cela m’aurait probablement pris 500 heures
Comme la plupart d’entre nous sont paresseux, on n’ira probablement pas jusque-là, mais c’est quand même à considérer
Le concept même d’application va devenir beaucoup plus fluide
Si une appli est faite dans un langage dynamique, il n’y a aucune raison d’empêcher l’utilisateur de réécrire lui-même le code et d’ajouter des fonctionnalités entièrement nouvelles
Ce n’est pas directement lié au texte de l’article, mais je ne suis pas d’accord avec l’idée que le terminal, parce qu’il est presque toujours à chasse fixe, fatigue pour lire de longs textes. Personnellement, je trouve bien plus confortable de lire de longs textes en police monospace
L’auteur a mis le doigt sur un point intéressant. Les variables en jeu sont la difficulté à créer l’outil, la difficulté à le publier, son utilité pour les autres, la récompense sociale à le publier et l’incitation négative qu’est l’ajout de dépendances
Le degré de difficulté à trouver une solution existante augmente selon le coût qu’il y a pour quelqu’un à la fabriquer et pour quelqu’un à découvrir comment la publier. À l’inverse, plus c’est utile à la communauté, plus les gens en parlent, donc plus c’est facile à trouver
Si la difficulté de création et la difficulté de publication divergent fortement, surtout si la création est bien plus difficile, les gens ont tendance à construire pour eux-mêmes puis à oublier. Si la publication est facile, il y a moins de solutions en circulation
Si les deux sont faibles, et que l’utilité pour autrui et la récompense sociale dépassent le coût des dépendances, on obtient des situations à la leftpad. Beaucoup de paquets NPM combinent forte utilité, forte récompense et faible coût de dépendance
En Emacs Lisp, la difficulté de création était autrefois élevée, mais elle est désormais faible, et une fois la courbe d’apprentissage passée, la difficulté de publication l’est aussi. L’utilité, la récompense et le coût des dépendances ne sont élevés dans aucun sens
On se retrouve alors dans un scénario où l’on fabrique simplement l’outil avant même d’aller vérifier s’il existe déjà. VSCode ou l’ancien Eclipse étaient différents parce que le coût de publication y était élevé
Je sens qu’une personne plus jeune que moi va en faire un sujet de thèse et le publier dans le monde
Ce billet laisse entrevoir un changement à venir avec le code LLM, qui n’est pas encore réalisé. Ne pourrait-on pas désormais abandonner Electron/React Native, et laisser les LLM transformer Figma, les wireframes et les spécifications de comportement en vraies applis natives pour chaque plateforme ?
Pour une appli CRUD, avec une spécification d’API et des mockups d’UI, voire de simples captures d’écran d’une plateforme déjà implémentée, on peut déjà aller assez loin. Ce type de tâche bien défini correspond justement à ce que les LLM font bien. Les tests d’équivalence devraient aussi pouvoir être largement automatisés
Resterait-il encore des excuses du genre « on ajoutera peut-être Android un jour » ou « il n’y a pas assez d’utilisateurs Mac/Linux » ? Et serait-il encore défendable que, dans une appli iOS, des parcours peu utilisés comme la réinitialisation de mot de passe ouvrent simplement une WebView arbitraire ?
Même pour des applis contenant une logique non triviale sur l’appareil, les LLM ont montré un vrai potentiel pour les réécrire dans des langages à cross-compilation facile comme Go ou Rust
Pour le dire de façon plus provocante : à ce stade, pourquoi apprendre SwiftUI ? Pour la plupart des tâches, l’expertise SwiftUI relève un peu de la même catégorie que « très bien apprendre Microsoft Word »
Je respecte les gens qui y consacrent du temps, mais que l’on choisisse cette voie ou non, la différence sur le résultat final est proche du millimètre
Je ne pense pas cela de la programmation en général. Je dis simplement que, désormais, les raisons de se spécialiser dans certains langages sont devenues plus compliquées