La Dignité de la Programmation Doit Être Reconstruite

Résumé

De l'idéal de Knuth à la déviation de la réalité, la programmation a dégénéré de l'art aux ordures en 40 ans. Unix v6 n'avait que 9 000 lignes, maintenant un bouton prend 500 lignes—l'esprit de programmation dégénère ; la tragédie du Boeing 737 Max avertit que la qualité du code concerne la vie. Nous devons retourner à l'essence de la programmation—simplicité, clarté, élégance. À tous les vrais programmeurs : SLAPS n'est pas une révolution, c'est un retour. Retour à la structure, à la responsabilité, à ces lignes de code que nous avons initialement aimées.

Contexte Précédent

"Documentation comme Code" a démontré la transformation révolutionnaire des paradigmes de programmation—de l'écriture manuelle de chaque ligne à l'utilisation de documents pour piloter la programmation IA. Mais quand la programmation devient si "facile", perdons-nous quelque chose de plus important ? Il est temps de parler de la dignité de la programmation elle-même.

1984, Donald Knuth a dit : "Les programmes devraient être écrits pour que les gens les lisent, et seulement accessoirement pour que les machines les exécutent."

2024, la réalité est : "Les programmes sont écrits pour que moi-même les lise, mieux si les autres ne peuvent pas comprendre."

Qu'avons-nous perdu en 40 ans ?

C'est l'obsession de la simplicité, le respect de la structure, la décence envers les pairs.

De l'Art aux Ordures

Vous souvenez-vous d'Unix v6 ? Le noyau entier du système d'exploitation, 9 000 lignes de code. Dennis Ritchie et Ken Thompson ont créé un chef-d'œuvre qui nous influence encore aujourd'hui avec l'expression la plus concise.

Maintenant ? Un événement de clic de bouton peut être écrit en 500 lignes. Pas à cause de la complexité, mais parce que "cela me fait paraître professionnel".

J'ai vu trop de code comme ça :

def calculate_sum(a, b):

\# Initialiser la variable de résultat

result = None

\# Vérifier les paramètres d'entrée

if a is not None and b is not None:

\# Exécuter l'opération d'addition

try:

\# Pour la robustesse, nous devons nous assurer...

if isinstance(a, (int, float)) and isinstance(b, (int, float)):

\# Considérant un possible débordement...

\# Devrait ajouter plus de vérifications ici...

result = a + b

else:

raise TypeError("Erreur de type de paramètre")

except Exception as e:

\# Gestion des erreurs

print(f"Erreur de calcul : {e}")

result = None

return result

Juste pour calculer une addition !?

Les langages de programmation sont les langages les plus structurés du monde, la voie est suprêmement simple. Mais nous compliquons habituellement les problèmes simples, obscurcissons la logique claire, écrivons cent lignes pour ce qu'une ligne peut résoudre.

Pourquoi ? Parce que plus le code est complexe, plus "seulement je peux le maintenir".

De la Solution au Problème Lui-même

Boeing 737 Max, vous savez ? 346 vies.

L'enquête a montré qu'une cause importante était les problèmes de qualité du code externalisé. Quand la programmation se transforme de "résoudre des problèmes" à "créer des problèmes", le désastre devient inévitable.

Ce n'est pas un cas isolé. Regardez autour de nous :

• Les systèmes médicaux plantent parce que le code est trop complexe, personne n'ose le changer
• Les systèmes bancaires échouent parce que la dette historique est trop lourde, ne peut pas être changée
• Les sites Web gouvernementaux traînent à cause de couche après couche d'externalisation, chaque couche "ajoutant des ingrédients"

Chaque ligne de mauvais code est un crime contre la postérité.

Chaque copier-coller abaisse la cote de crédit de cette industrie.

Chaque montagne de merde est une trahison de la civilisation.

De Respecté à Fermier de Code Auto-Dépréciant

"Que faites-vous ?"

"Fermier de code."

Derrière cette auto-dépréciation se cache la dégradation de la dignité de toute une industrie.

Le terme auto-dépréciant "fermier de code" est progressivement devenu l'étiquette par défaut de l'industrie. Au fil du temps, même nous-mêmes avons oublié : le code est en fait la forme ultime du langage.

Quel programmeur de l'ère classique n'était pas une figure respectée ? Ils ont écrit des systèmes complets avec 64K de mémoire, chaque ligne de code soigneusement considérée, chaque algorithme poursuivant l'élégance ultime. Leur respect pour le code et la structure était instinctif.

Linus Torvalds a dit : "Talk is cheap, show me the code." Mais maintenant, le talk augmente, le code empire.

Pourquoi cela se produit-il ?

Parce que tout le domaine des programmeurs coule. Le seuil a baissé, mais les normes aussi. Oser s'appeler programmeur juste en copiant-collant, penser être génial juste en appelant des API.

Les vrais programmeurs ne feraient pas les choses de cette façon. Ils savent :

• La simplicité est une vertu, pas de la paresse
• La lisibilité est une responsabilité, pas un choix
• L'élégance est une poursuite, pas une prétention

Quand la Marée se Retire, Qui Nage Nu ?

Maintenant, l'IA est arrivée.

Quand vous lancez des exigences à l'IA, le code qu'elle écrit en 10 secondes est plus clair que ce sur quoi vous avez agonisé pendant 3 jours. Quand vous ajoutez encore la 15ème couche de try-catch "pour la robustesse", l'IA a déjà résolu le problème de la manière la plus concise.

SLAPS n'essaie pas de remplacer les programmeurs, mais de forcer la programmation à retourner à son essence.

C'est un remodelage du seuil. Ne pas empêcher les gens d'entrer dans l'IA, mais rendre chaque ligne de code responsable.

Sous le cadre SLAPS :

• Vous ne pouvez pas tromper l'IA—si la structure n'est pas claire, elle ne comprendra pas
• Vous ne pouvez pas empiler des montagnes de merde—si la conception est déraisonnable, l'IA la questionnera directement
• Vous ne pouvez pas être mystérieux—chaque décision a besoin d'un raisonnement clair

C'est l'"élégance forcée". Soit vous écrivez des conceptions claires, concises et maintenables, soit l'IA ne vous aidera pas à les implémenter.

Ces programmeurs qui comptent sur la complexité pour garder leurs emplois sont effectivement condamnés.

Mais ce n'est pas mauvais, c'est l'auto-purification de l'industrie.

Laissez la Programmation Redevenir une Carrière Fière

Je crois que les vrais programmeurs ne craindront pas l'IA mais l'embrasseront. Parce que l'IA les transforme de "travailleurs du code" en "concepteurs de systèmes".

Pensez-y :

• Plus besoin d'obséder sur les détails de syntaxe, concentrez-vous sur la conception architecturale
• Plus besoin de réinventer les roues, concentrez-vous sur la pensée innovante
• Plus besoin de tomber dans l'enfer du débogage, concentrez-vous sur la valeur commerciale

C'est à quoi la programmation devrait ressembler.

Quand la programmation revient à son essence, ceux qui ne peuvent pas écrire de code pourraient créer de meilleurs systèmes. Parce qu'ils n'ont pas de "mauvaises habitudes de programmeur", ils veulent juste résoudre des problèmes, pas montrer leurs compétences.

Un chef de produit maîtrisant les affaires pourrait faire mieux avec SLAPS qu'un "fermier de code" avec 10 ans d'expérience. Parce qu'ils savent "ce qu'ils veulent", ne s'obsédant pas sur "comment écrire".

La Nouvelle Dignité de la Programmation

L'avenir appartient à ceux qui :

• Peuvent exprimer clairement l'intention
• Poursuivent la simplicité et l'élégance
• Résolvent de vrais problèmes
• Respectent à la fois le code et les gens

Les futurs programmeurs n'écrivent pas du code mais des contrats ; ne déboguent pas des bugs mais un consensus.

Ce n'est pas le jour du jugement dernier des programmeurs, c'est la renaissance de la programmation.

Quand SLAPS rend chaque ligne de code significative, quand l'IA devient le gardien de la qualité du code, quand "bricoler" n'est plus possible, la programmation redeviendra un métier respectable.

Nous n'avons pas besoin de plus de gens qui écrivent du code de montagne de merde, nous avons besoin de gens qui comprennent "pourquoi écrire".

Nous n'avons pas besoin de plus de frameworks complexes, nous avons besoin d'une pensée plus claire.

Nous n'avons pas besoin de protéger l'arriération, nous devons embrasser le progrès.

Quand le code n'est plus un fossé pour l'intérêt personnel, la pensée devient la vraie compétitivité.

Finalement

Il y a 29 ans, j'ai tapé du code ligne par ligne avec EditPlus. Pas d'indices intelligents, pas de coloration syntaxique, mais je connaissais le sens de chaque ligne.

Aujourd'hui, quand je vois l'IA écrire 1 150 lignes de code de haute qualité en 40 minutes, je ne suis pas paniqué mais soulagé. Parce que ce code incarne ce que j'ai toujours poursuivi : structure claire, logique concise, intention claire.

Certains disent que cela rendra de nombreux programmeurs au chômage. Oui, comme l'impression a rendu les scribes au chômage. Mais l'impression a aussi créé des écrivains, des éditeurs, des éditeurs. SLAPS fera disparaître les "travailleurs du code" mais créera des "architectes de protocole IA".

La dignité de la programmation n'est pas maintenue en protégeant l'arriération mais reconstruite en embrassant le progrès.

Laissez le code redevenir de la poésie, laissez les programmeurs redevenir des ingénieurs, laissez la programmation redevenir la force qui change le monde.

Le véritable esprit hacker n'est pas dans les astuces mais dans l'intention.
Face à l'IA, la réponse la plus intelligente n'est pas la résistance mais de demander : Comment puis-je conspirer avec elle ?

C'est ce que nous faisons.

À tous les vrais programmeurs : SLAPS n'est pas une révolution, c'est un retour. Retour à la structure, à la responsabilité, à ces lignes de code que nous avons initialement aimées.

Juin 2025, Lisbonne

À propos de l'auteur

Wang Xiao est architecte de protocoles d'IA, auteur de System and Freedom, créateur du Danbing AI Protocol / SLAPS Framework et initiateur d'OathAI.

Son travail porte sur la co-création humain-IA, la gouvernance des protocoles, l'ancrage sémantique et la continuité du savoir à long terme, en explorant comment les connaissances humaines et les structures collaboratives peuvent être préservées, calibrées et héritées à l'ère de l'IA.

Avertissement

Cet essai reflète les observations et réflexions méthodologiques actuelles de l'auteur, fondées sur sa pratique personnelle, sa recherche et son expérience de collaboration humain-IA. Les méthodes liées à Danbing / SLAPS / OathAI continuent d'être organisées et développées. Leurs effets pratiques peuvent varier selon le contexte de la tâche, la capacité du modèle, l'environnement d'exécution et le niveau d'engagement.

Cet essai ne constitue pas un conseil juridique, d'investissement, médical, professionnel, ni une garantie de mise en œuvre technique. Les lecteurs qui appliquent ces méthodes à des projets réels doivent exercer leur propre jugement selon leur situation et assumer la responsabilité des résultats concrets.