La crise du logiciel
(wryl.tech)- L’expression « software crisis », apparue lors de la conférence NATO Software Engineering de 1968, est devenue moins courante, mais le poids créé par la complexité du logiciel et l’abstraction demeure
- Dans sa conférence du Turing Award en 1972, Edsger Dijkstra estimait que les performances et la complexité du matériel avaient fortement augmenté, tandis que les méthodes organisationnelles pour les maîtriser n’avaient pas suivi
- La commercialisation de l’informatique personnelle et les cycles de sortie rapides ont conduit les utilisateurs à vouloir plus de capacité avant même d’avoir pleinement maîtrisé leurs outils, et « abstract it away » est devenu la réponse par défaut
- Les couches d’abstraction imbriquées entraînent un coût en performance et des modèles mentaux déformés, tout en rendant plus difficile l’accès aux fonctions fondamentales de la machine, comme le graphisme ou le son
- La solution ne consiste pas à revenir aux plateformes contraintes du passé, mais à réduire les couches d’abstraction et à préserver l’information entre les couches afin de redonner la main aux utilisateurs des outils
Une préoccupation de 1968 qui n’est toujours pas résolue
- Le terme « software crisis » a été forgé lors de la première conférence NATO Software Engineering, en 1968
- Ces conférences comptaient parmi les premières tentatives de formaliser et de systématiser les pratiques de programmation des machines de calcul automatique
- Le 16 juillet 1969, la mission Apollo 11 a été lancée, et la dernière conférence NATO Software Engineering s’est tenue en octobre de la même année
- Dans sa conférence du Turing Award en 1972, Edsger Dijkstra situait l’origine de la crise dans des machines devenues puissantes et dans l’absence de méthodes organisationnelles capables de les maîtriser
- Il a formulé l’idée que, quand les machines n’existaient pas, la programmation n’était pas un problème ; quand il y avait quelques ordinateurs peu puissants, c’était un problème mineur ; puis, avec l’arrivée d’ordinateurs gigantesques, la programmation est elle aussi devenue un problème gigantesque
- Aujourd’hui, l’expression « software crisis » apparaît rarement dans les pratiques de programmation
- L’évolution de nouveaux langages et de méthodes organisationnelles, ainsi que la distance temporelle avec les problèmes du passé, ont donné au secteur un certain sentiment de soulagement, comme si le problème avait été en partie résolu
- Mais ce soulagement reste plus proche de la défaite et de l’acceptation que d’un véritable confort
L’abstraction éloigne les utilisateurs du contrôle
- Les débuts de l’informatique et les progrès dans les domaines voisins se sont produits dans des machines et des environnements où construire une tour d’abstractions avait un coût direct
- Lorsqu’il était impossible de contourner les contraintes, un cycle de croissance s’ensuivait avec des mises à niveau matérielles
- En réalité, on en venait à vouloir plus de capacité avant même d’avoir suffisamment compris les contraintes existantes
- Après la commercialisation de l’informatique personnelle, les entreprises qui vendaient les équipements n’ont pas attendu que les utilisateurs maîtrisent pleinement leurs produits, et les cycles de croissance ont continué à s’accélérer
- Avec des cycles de sortie matériel rapides, « abstract it away » est devenu le mode de pensée par défaut
- Repousser les détails déplaisants dans une structure contrôlable procure une certaine indépendance, mais s’accompagne d’un coût en performance
- Les multiples couches d’abstraction et la dissimulation de l’information déplacent le problème de la construction logicielle vers des niveaux plus élevés
- Ces couches sont intégrées aux logiciels nécessaires pour utiliser les ordinateurs et aux logiciels qui font fonctionner la vie quotidienne
- L’industrie logicielle au sens large a accéléré les cycles de sortie et l’influence du capital, tandis que l’espace facilement accessible aux développeurs individuels s’est réduit
- La crise du logiciel ne concerne pas seulement les développeurs : elle se prolonge aussi chez les utilisateurs de logiciels
- Les utilisateurs n’ont presque aucun contrôle en dehors des fonctionnalités autorisées par les auteurs
- Le fait que créer et utiliser des logiciels soient tous deux des activités humaines s’estompe
Ce vers quoi revenir, ce n’est pas le passé, mais des couches peu profondes
- La solution proposée ne consiste pas à revenir à des plateformes plus limitées
- Il faut limiter le nombre de couches d’abstraction autorisées
- Il est nécessaire de préserver l’information entre les couches
- Les modèles de programmation, les interfaces utilisateur et le matériel sous-jacent doivent être peu profonds et composables
- Des mouvements comme les communautés Handmade, Permacomputing et rétro-informatique participent à une prise de conscience accrue de la crise du logiciel
1 commentaires
Avis de Hacker News
Bonjour, je suis l’auteur. Il me semble important de clarifier un point souvent mal compris dans cet article. Je ne suis pas opposé à l’abstraction en soi, mais à son application sans limites.
La solution n’est pas non plus de revenir à des plateformes plus contraignantes, ni d’affirmer que les utilisateurs devraient « prendre sur eux et devenir plus techniques ». La clé pour comprendre la crise du logiciel, ce sont les courbes de « maîtrise des plateformes » et de « cycles de croissance/release ». Depuis plus de 40 ans, à quelques domaines près, ces courbes se sont écartées ; nous n’avons pas su résoudre le problème quand elles étaient proches, mais le deuxième meilleur moment pour le faire, c’est maintenant.
Certains disent que cet article est du clickbait, mais c’est le premier billet de mon journal et il contient mes réflexions sur la situation dans laquelle je me trouve en tant que développeur. On retrouve des sentiments similaires, sous diverses formes, dans plusieurs communautés, en particulier dans certaines communautés issues de la contre-culture. Pour montrer une partie de la solution au problème, j’envisage aussi d’écrire un billet de suivi du type « je vais montrer comment faire ». Je travaille seul, donc merci de me laisser un peu de temps et de marge.
Tant qu’il y aura des millions de personnes qui créent du logiciel, on ne pourra pas corriger complètement ce problème. Il y en aura forcément avec lesquelles on sera en désaccord, et tout le monde ne pourra pas devenir aussi compétent que l’auteur. Au final, je lis donc cet article comme une affirmation selon laquelle il faudrait relever, par rapport à aujourd’hui, le seuil de ce qui constitue une « abstraction acceptable ».
Il est facile de parler en grands principes, mais si l’on examine un domaine précis que l’on juge « trop abstrait », on risque fort de gagner en humilité. Ces « excès d’abstraction » ont généralement de plutôt bonnes raisons d’exister, et les ingénieurs du domaine trouvent eux aussi la situation des abstractions brouillonne, tout en la jugeant nécessaire ou irréaliste à corriger.
Par exemple, beaucoup de logiciels sont construits en ajoutant de bonnes abstractions au-dessus d’abstractions intermédiaires très répandues. Kubernetes repose ainsi sur Linux, des runtimes de conteneurs et une architecture traditionnelle plan de contrôle/couche de configuration/plan de données. On pourrait implémenter toute cette logique directement dans un nouveau système d’exploitation, mais cela poserait des problèmes de compatibilité pour les utilisateurs. Même si on pouvait le construire, il pourrait ne pas avoir d’utilisateurs, et il faudrait alors réimplémenter les mauvaises abstractions qu’on cherchait à éviter. En plus, une telle solution serait bien plus difficile à mettre en œuvre. Je n’aime pas la conception de Kubernetes et j’aimerais résoudre ce problème, mais j’y vois le résultat du fait que le faire « correctement » est trop difficile ou trop coûteux pour que cela en vaille la peine.
Selon le moment et le contexte dans lesquels on est arrivé dans ce domaine, il est assez probable que les abstractions des générations précédentes aient déjà été intégrées aux pratiques acceptées. Par exemple, à une époque, l’usage d’un système d’exploitation doté d’un système de fichiers généraliste est devenu une hypothèse allant de soi.
Le problème évoqué ici me semble plutôt correspondre aux difficultés que l’on rencontre en entrant aujourd’hui dans ce domaine. Si l’on suppose qu’il faut comprendre en détail toutes les abstractions utilisées pour pouvoir contribuer, les prérequis en connaissances sont considérables. On peut se sentir submergé, mais il est aussi possible d’accepter les abstractions jusqu’à pouvoir les comprendre plus en profondeur.
0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
Cela dit, la raison pour laquelle cette situation ne change pas me paraît clairement économique. Cela ne veut pas dire que le mauvais logiciel coûte moins cher. Mais rogner sur les angles permet à un individu ou à une organisation d’économiser maintenant, tandis que les coûts plus importants seront supportés plus tard par l’organisation elle-même, ses clients ou la société dans son ensemble ; il existe donc une forte incitation aux pratiques bon marché et mauvaises. De plus, comme il est difficile d’appliquer au logiciel les standards des autres disciplines d’ingénierie, il est aussi difficile de rédiger des contrats ou des réglementations exigeant un certain niveau de standard ou de qualité logicielle.
La seule solution imaginable serait une révolution technologique permettant de produire, avec les mêmes technologies, du logiciel à la fois moins cher et meilleur, tout en empêchant de produire du logiciel moins cher et moins bon.
Il y a trop de logiciels sur trop de plateformes, et le paysage est trop fragmenté pour qu’il soit facile de généraliser. Certains projets vacillent et s’effondrent, tandis que d’autres fonctionnent bien.
Il existe des logiciels hostiles à l’utilisateur, mais c’est intentionnel. Il y a du cynisme et de la cupidité derrière. Ce n’est pas parce que les programmeurs ne savent pas ce qu’ils font, c’est parce qu’ils font ce qu’on leur demande.
Les utilisateurs eux-mêmes encouragent cela. Même si on leur fournit un bon logiciel, cela ne les intéresse pas ; les utilisateurs demandent autre chose qu’un bon logiciel. Un utilisateur qui veut du bon logiciel devient la victime de cinquante utilisateurs qui n’en veulent pas. Le logiciel grand public est désormais de la culture de masse.
Le Word de l’époque n’était pas non plus massivement inférieur à la version actuelle. Et pourtant, aujourd’hui, Windows et Office ont besoin de 50 à 100 Go de disque rien que pour fonctionner. Qu’a-t-on gagné pour justifier un facteur 1000 ?
C’est complètement délirant, mais nous faisons comme si de rien n’était. Les systèmes modernes ont environ 5000 à 10000 fois plus de disque, de RAM et de CPU, et l’Internet domestique est littéralement un million de fois plus rapide que les premiers modems.
Ce texte part du principe que la crise du logiciel existe réellement, ou qu’elle constitue un problème majeur. Il cite comme éléments de cette crise les dépassements de budget, les retards de planning, l’inefficacité, la faible qualité, les exigences non satisfaites, les projets ingérables, le code difficile à maintenir, les livraisons non effectuées, etc.
Mais si l’on retire ici le mot « logiciel », combien d’activités humaines ne connaissent pas au moins un de ces problèmes ? À l’inverse, il existe aussi beaucoup de logiciels réellement très bons. Nous avons tendance à ne voir que les échecs et les défauts, et à ignorer les réussites comme si elles étaient une base acquise, même lorsqu’elles continuent de s’améliorer.
Entre le moment où l’on appuie sur le bouton d’alimentation d’un ordinateur et l’arrivée sur le bureau, on traverse déjà des centaines d’abstractions. Et ce bureau à lui seul est l’objet le plus complexe avec lequel nous interagirons probablement de toute la journée. Cela se produit des milliards de fois par jour dans le monde, et globalement sans problème. Et ce n’est qu’un tout petit exemple.
Cela dit, je pense que la vraie motivation de ce genre d’article n’est pas cette liste d’éléments, mais le fait que tout semble devenu ingérable. Un programmeur expérimenté doit équilibrer ce sentiment d’écrasement avec ce qu’il y a effectivement à faire. Il m’a fallu du temps pour en arriver là, mais je crois que c’est important. Tout ne sera jamais parfaitement rangé, et il faut l’accepter.
Dans le logiciel, à part les contraintes de performance et de mémoire, il n’existe presque pas de limites de ce genre. Or les deux sont suffisamment généreuses pour permettre d’empiler indéfiniment des couches de déchets et de s’en sortir. Nous avons tous déjà pensé ou dit : « Mais comment est-ce que ce truc peut bien fonctionner ? » Tant que l’utilisateur ne tombe pas sur une mauvaise condition aux limites, on ne sait pas à quel point le code sous-jacent est fragile.
« Avez-vous essayé de l’éteindre puis de le rallumer ? » en est la preuve. Les systèmes logiciels entrent souvent dans des états mauvais, trop subtils et incompréhensibles, au point que la seule solution consiste à tout effacer et à tout relancer depuis le début. Comme un téléphone qui continue de vibrer après un appel jusqu’au prochain appel ou SMS, une web app dont une partie ne se charge pas à 100 % et fait disparaître des options, ou un appairage Bluetooth erratique.
La communication est la manière de diffuser la compréhension et de corriger son absence, et la compréhension est la base de la réussite dans n’importe quel domaine. Sans compréhension, au moins un des symptômes précédents apparaît. Ils peuvent aussi apparaître malgré la compréhension, mais au moins il existe alors un chemin vers la réussite.
D’après mon expérience, la plupart des problèmes de l’industrie du génie logiciel sont des problèmes humains. Ce n’est pas la technologie, ni la technique en elle-même, ni les processus. C’est pourquoi la communication et la compréhension sont indispensables au succès.
Si l’on regarde le parcours des dirigeants de sociétés d’ingénierie ou de constructeurs automobiles, on voit des étapes où ils ont assumé des responsabilités de plus en plus importantes dans la conception de pièces, de composants et de produits, ou dans l’exploitation d’installations de production. Les CEO continuent eux aussi de mettre en avant leurs connaissances techniques, et même les profils non techniques font au moins semblant
À l’inverse, dans le développement logiciel agile, la compétence technique s’arrête généralement aux échelons les plus bas. Dans une équipe Scrum, il y a les personnes qui fabriquent le logiciel, et c’est tout. Il y a de fortes chances que le Scrum Master et de nombreux business analysts n’aient jamais beaucoup codé, et que le premier vrai supérieur hiérarchique soit surtout chargé de tâches administratives ou de secrétariat, et voie donc très peu de code
Le problème n’est pas seulement que le développement logiciel se fait à l’échelle de tickets, ce qui rend difficile toute réflexion philosophique sur le nombre de couches d’abstraction que l’on crée et maintient. Les développeurs logiciels n’ont même pas de place à la table des décisions. Ils sont pris en charge par un Scrum Master, font des compromis en code review, subissent la pression de ne pas penser au-delà du ticket, et n’ont généralement pas de voie de promotion permettant d’amener leur compétence technique vers le leadership
C’est pourquoi le mouvement qui cherche à alerter sur la « crise du logiciel » risque fort de rester cantonné à des domaines de hobby comme le Handmade, le Permacomputing ou le rétrocomputing, comme le dit la fin du texte. Hollywood a aussi sa part de responsabilité, à mon avis, en représentant sans cesse les gens du logiciel/de l’IT de façon humiliante, tout en donnant indéfiniment les premiers rôles aux médecins et aux avocats, et en transformant leur jargon complexe en récits captivants. Est-ce vraiment impossible de notre côté ? Peut-être qu’une IA scénariste finira bientôt par faire quelque chose
Le développement logiciel consiste à dialoguer toute la journée avec un ordinateur de manière rigoureuse. On y résout, dans une nouvelle application, des problèmes ordinaires déjà résolus, ou bien des problèmes qu’il est même difficile de cerner sans bagage technique. Je suis développeur et je programme pour le plaisir depuis plus de vingt ans, mais la plupart du travail est d’un ennui à devenir fou. Je n’essaie même pas de l’expliquer à des non-développeurs. C’est aussi peu passionnant que la comptabilité, et beaucoup de gens tireraient sans doute des informations plus utiles d’une autre histoire
L’entreprise la plus profondément acquise à l’agile dans laquelle j’ai travaillé traitait les juniors et les seniors comme des rouages interchangeables. La seule différence était qu’un senior devait traiter davantage de points par sprint. Il y avait une répression active de toute réflexion en dehors du périmètre du ticket, et une ambiance qui incitait à baisser la tête et à se taire
Mais il y a deux problèmes. Ils ne peuvent pas entrer profondément dans les détails d’implémentation, et ils sont aussi pris dans des incitations perverses qui récompensent la création de complexité. Bien sûr, certains s’y opposent, mais ces personnes ont peu de chances d’être promues. On n’est pas récompensé pour réduire le nombre de personnes sous sa responsabilité ou pour supprimer son propre rôle
Pour dire brièvement pourquoi les développeurs ne traitent des vrais besoins qu’à l’échelle de tickets : parce qu’ils sont trop bêtes. Ils n’arrivent pas à garder l’ensemble en tête, ils ne comprennent pas. Cela vous paraît frustrant ? Ça l’est. C’est vraiment difficile à comprendre. Désolé
Ce texte présente l’abstraction comme un mal, mais c’est un outil inévitable si l’on veut créer des logiciels produits par des humains dépassant un certain niveau de capacité
Rich Hickey a dit en substance qu’« un jongleur débutant peut manipuler deux ou trois balles, mais même le meilleur jongleur du monde plafonne probablement autour de neuf. Les capacités humaines ne diffèrent pas d’un ordre de grandeur, et on atteint vite un plafond ». Pour dépasser cette limite, on n’a pas d’autre choix que de recourir à l’abstraction
Bien sûr, dans certains cas, il peut y avoir de mauvaises abstractions, ou trop d’abstractions, et je pense que c’est ce qui a mis l’auteur en colère. Mais cette distinction est importante
Le passage selon lequel « il n’est désormais plus facile de créer des logiciels, et rien n’est livré avec un manuel » est manifestement faux. Créer du logiciel est plus facile que jamais, et la documentation est aussi mieux faite
Comprendre un tout complexe n’exige pas forcément de l’indirection. Pour gérer la complexité, il faut démêler ce qui est entremêlé afin de pouvoir comprendre chaque partie indépendamment. Si l’on cache la complexité derrière de l’indirection, on crée une distance entre nous et l’objet sur lequel nous devons raisonner
L’abstraction est bonne pour l’utilisateur. Qu’il soit développeur ou non, elle lui évite d’avoir à se soucier des détails. Mais elle ne rend pas plus facile le travail qui consiste à la construire
Contrairement à l’idée qu’« il n’est plus facile de créer du logiciel », c’est très simple si l’on connaît les bons outils pour les bonnes tâches. Seulement, les informations sur ces outils sont étouffées, si bien qu’on en entend presque jamais parler
L’écosystème des outils techniques tel que la plupart des gens l’imaginent est très différent de ce qu’il est réellement. La plupart des outils que nous connaissons sont affreux. Ils essaient de se présenter comme des solutions universelles, mais en réalité ils ne sont pas très bons à grand-chose. Et pourtant, ce sont les outils les plus populaires. Comme l’article le suggère, je pense que c’est dû à l’influence du capital
Par exemple, avec l’outil que j’utilise actuellement, j’ai enregistré une vidéo où je crée de zéro, uniquement dans le navigateur, sans télécharger aucun logiciel, en serverless et en 3 heures, une application de marketplace relativement complexe avec connexion, contrôle d’accès, validation de schéma et vues filtrées complexes. Toute l’application fait moins de 700 lignes de balisage HTML et 12 lignes de JavaScript. Elle a fait une dizaine de vues
Contrairement au twist complotiste, les outils modernes sont plus flexibles et plus faciles à utiliser que jamais. Ils ont des défauts, mais ce n’est rien comparé à ce que les développeurs devaient subir il y a quelques décennies. Il n’existe pas de vaste complot visant à étouffer votre outil
Je crois beaucoup au no-code/low-code et aux outils exécutables partout. Mais ce que j’entends par là n’est peut-être pas ce que vous imaginez. Quoi qu’il en soit, je reconnais que vous l’avez créé
En commençant à regarder la vidéo, mes premières questions ont été les suivantes. Qu’est-ce que Codespaces ? Qu’en est-il de la sécurité ? Où l’application finale s’exécute-t-elle ? Puis-je la faire tourner sur mon propre matériel ? Peut-elle fonctionner sans accès au cloud ? Quel cloud ? Sera-t-elle encore là la semaine prochaine, le mois prochain, l’an prochain, dans 10 ans ? Bien sûr, ne vous focalisez pas trop sur un seul exemple
La situation du no-code/low-code peut se comparer à la PAO. La PAO n’a pas de pipeline CI/CD. On appuie sur Imprimer. C’est un environnement totalement intégré. À l’inverse, littéralement tous les environnements d’« intégration continue » semblent se dévorer eux-mêmes à force de vouloir crier trop fort. Quelque part, il existe sûrement des outils pour la séparation des couleurs, le réglage des marges, l’import de polices, des bibliothèques d’en-têtes PostScript ou la génération LaTeX, mais la plupart des gens ne les voient ni ne les utilisent. Quelque part, il existe aussi des gens qui font de l’impression multiplaque, avec des pigments bien plus variés que le CMYK, et qui n’est éclatante qu’à la lumière naturelle, mais la majorité ne voit que des instantanés médiocres pris au téléphone, donc elle n’en perçoit pas l’intérêt
Ce n’est pas seulement un problème de créateurs. Les consommateurs ne savent pas ce qui est possible et ne disposent pas non plus des appareils capables de révéler tout l’éventail des possibles. Les appareils grand public réduisent activement cet éventail pour toutes sortes de raisons liées aux écosystèmes fermés, ainsi qu’à une négligence et une ignorance ordinaires
Il y a quelques années, on m’a donné une Cadillac comme voiture de location, et je n’achèterai jamais une Cadillac moderne ; si possible, j’éviterai même d’en conduire une. Je n’arrivais pas à contrôler les essuie-glaces, et l’écran de la console a affiché à plusieurs reprises l’alerte la plus visible possible indiquant que je ne regardais pas la route. Il n’avait probablement pas compris que je portais des lunettes. Comme j’étais dans une circulation rapide sur une route inconnue, je ne regardais effectivement pas l’écran, et j’ai demandé à mon passager : « Qu’est-ce qu’il raconte, cet écran qui clignote ? » Bien joué, Cadillac
Une structure superficielle et composable est quelque chose que tout le monde expérimente en utilisant les outils UNIX
C’est là que les GUI s’effondrent. Les GUI sont littéralement des îlots qui ne communiquent pas entre eux de manière composable
Je mène une expérimentation qui mélange les GUI et l’idée des pipelines shell avec un outil appelé guish
https://github.com/williamcotton/guish
Je me demande si quelqu’un connaît des outils similaires ou des approches de GUI composables
https://hisham.hm/userland/
https://arcan-fe.com/2021/04/12/introducing-pipeworld/
http://conal.net/papers/Eros/
Je travaille moi aussi sur des idées liées à cela, et en surface elles semblent assez proches des vôtres. Cela dit, je vous conseille de regarder comment cela fonctionne dans emacs. Je n’ai pas creusé en profondeur, mais votre approche ne me paraît pas très « composable »
Si vous ne le connaissez pas, ceci peut aussi servir d’inspiration : https://gtoolkit.com/ C’est un environnement Smalltalk où, comme dans emacs, absolument tout est programmable, mais presque dans le sens inverse. La GUI n’est pas le résultat des commandes, c’est le langage lui-même
Mais le plus gros problème, ce ne sont pas les GUI. Les GUI sont bien un problème, mais comme elles se trouvent forcément tout en haut de la pile d’abstractions, le problème ne se propage pas davantage en se combinant. Fait intéressant, c’est un problème tellement gros qu’il cesse presque d’en être un
L’énorme éléphant dans la pièce aujourd’hui, ce sont les systèmes distribués
Cela dit, les GUI ont toujours été un point faible. Je pense que c’est parce qu’il y a beaucoup de considérations « globales » dans le fait qu’une UI soit bonne ou non, et que ce n’est donc pas une propriété modulaire
Personnellement, j’aimerais davantage d’UI tout en conservant l’automatisation : cette propriété qui permet d’enregistrer dans un fichier ce qu’on a tapé dans le shell pour le relancer plus tard, le modifier et le relancer, ou copier une commande et l’envoyer par e-mail à un ami
Pour donner un peu de contexte, je construis depuis des années un shell à partir de zéro, avec un mode headless pour les GUI. Il existe aussi de vraies démos écrites par d’autres personnes, mais plus personne ne travaille dessus pour l’instant
Captures d’écran :
https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
https://www.oilshell.org/blog/tags.html?tag=headless#headles...
Il y a davantage de liens ici - https://github.com/oilshell/oil/wiki/Interactive-Shell - y compris des projets intéressants mais inactifs comme Xiki
Si vous avez besoin d’un shell compatible séparé du terminal, ou d’un nouveau shell de ce type, dites-le-moi par e-mail ou sur https://oilshell.zulipchat.com
En gros, j’ai besoin de personnes pour tester le protocole headless et me faire part des améliorations possibles. Je pense qu’il faut créer une GUI de shell qui « possède » un terminal sans « être » le terminal lui-même. Cela semble aussi lié à ce que vous construisez
En ce moment, je travaille surtout sur le nouveau langage YSH, mais j’aimerais aussi relancer le travail sur la GUI. Je n’ai pas beaucoup d’expérience comme programmeur d’UI, donc d’autres points de vue seraient bienvenus
Et je suis content de voir que vous avez inclus ggplot, que j’aime beaucoup. En fait, ggplot est précisément le genre de chose qui me fait regretter que le shell n’ait pas de graphiques
La phrase finale « cela peut être amélioré. Je vais vous montrer comment » ressemble simplement à une accroche de clickbait
L’affirmation selon laquelle « il est très rare que ces modèles reflètent la réalité. Quand ils le font, c’est un heureux hasard ; sinon, c’est une catastrophe » ne correspond pas à mon expérience
En général, la plupart des logiciels du marché ne sont pas critiques. Beaucoup de webapps lourdes et médiocres peuvent pomper inutilement des quantités de ressources toute la journée, exhiber des bugs sporadiques un peu partout, tout en accomplissant très mal ce que l’utilisateur en attend. Tout cela est vrai
Mais ils ne sont pas aussi critiques que les logiciels qui gèrent des pacemakers ou des fusées spatiales. La plupart des logiciels peuvent être bancals. La plupart des projets sont liés aux caprices humains, et le pire d’un manque de qualité se limite à un peu de frustration, pas à une catastrophe ni à la mort
En outre, la plupart des développeurs logiciels ne travaillent probablement pas dans un cadre de motivation financière à la Silicon Valley, et ne gagnent pas non plus leur vie avec les projets qu’ils auraient passionnément envie de créer. La majeure partie des logiciels mis sur le marché est produite au travers de structures de récompense externes et médiocres. Qu’attendez-vous d’autre qu’un produit médiocre issu d’un tel processus ?
Je déteste vraiment les marches manquantes
Nous sommes très éloignés de l’usage réel des logiciels que nous créons, et nous ne percevons que de brefs signaux exploitables qui alimentent le processus de développement. À moins de pouvoir échanger notre place avec celle d’un nouvel utilisateur, il est difficile de ressentir correctement la douleur réelle de cette « mort par mille coupures »
Je considère la programmation comme un métier, et je pense que nous avons le pouvoir d’agir sur la qualité logicielle. Simplement, il existe des incitations, financières ou non, qui nous poussent à détourner le regard
Je ne pense pas qu’il y ait une crise du logiciel. Des millions de programmeurs dans le monde créent des programmes utiles dans une certaine mesure, et presque tout, jusqu’aux grille-pain, exécute du logiciel avec suffisamment de succès. La communauté a même créé des programmes accessibles à tout le monde, des enfants de 5 ans aux grands-parents. Où est la crise là-dedans ?
En revanche, il existe bien une crise de la gestion de projet. Elle ne se limite pas au logiciel : c’est le problème de l’éloignement entre ceux qui planifient et ceux qui livrent. Et nous semblons incapables de combler cet écart. Agile, Scrum, etc. sont les symptômes de cet écart où des « gourous » nous prennent tous pour des imbéciles, et nous ne parvenons pas non plus à produire quelque chose de meilleur
La marchandisation du développement logiciel contribue aussi à cette confusion. Comme c’est un domaine où il est facile d’entrer, des personnes de tous niveaux peuvent y participer avec des taux de réussite variables. Ce n’est pas une question de bien ou de mal, c’est la nature du phénomène. Ce n’est pas très différent de la restauration, où coexistent des restaurants étoilés Michelin et des MacDonalds, qui ont tous deux leurs clients. On ne parle pas pour autant de crise des restaurants
Cela réduit la durée de vie du grille-pain. Autrefois, on pouvait avoir un grille-pain qui durait 10 ans. Aujourd’hui, à cause de mauvais logiciels et peut-être d’une connexion WiFi ou Bluetooth imposée, il finit à la poubelle au bout de 2 ans quand le fournisseur arrête les mises à jour. Peut-être même qu’il n’y a jamais eu de mises à jour. La crise n’est simplement pas toujours visible, soit parce qu’elle ne se voit pas directement, soit à cause de la surconsommation actuelle et de l’achat incessant de nouveaux produits
Si le grille-pain s’arrête au bout de 2 ans, nous considérons que c’est acceptable, et nous pouvons ne pas nous soucier de savoir pourquoi, ou ne pas le savoir. Mais il a peut-être fait partie du botnet Mirai https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
Un grille-pain utilise probablement une puce plus simple, donc sans doute pas, mais qui sait ?
Pour info, mon grille-pain Dualit n’exécute pas de logiciel
Le passage « nous avons empilé des couches d’abstraction imbriquées et développé des moyens de cacher l’information à plusieurs niveaux. Nous avons transformé le problème de la construction logicielle en une série de strates vertigineuses » me fait penser aux abstractions qui fuient et à la tour de Babel
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
https://en.wikipedia.org/wiki/Tower_of_Babel
https://en.wikipedia.org/wiki/Hierarchy
https://en.wikipedia.org/wiki/Abstraction
https://en.wikipedia.org/wiki/Abstraction_(computer_science)
Cela vaut la peine de les comparer entre eux