Aller au contenu

La vieille religion de Python

Je crois que la vieille religion de Python me manque.

Python donnait l’impression d’être un langage avec une doctrine, presque un manifeste politique sur votre conception du code. Ça demandait un modèle mental très spécifique.

On attendait de vous que vous écriviez les choses de manière lisible, disciplinée et, surtout, prévisible.

Dans la vision du monde originelle de Python... la surprise était l’ennemie.

Et qu’on soit d’accord ou non, ça semblait toujours posséder une sorte de droiture bien à elle.

Est-ce qu’on peut y revenir ?

J’y pensais aujourd’hui en débuguant le crash total d’une app. J’ai commencé par l’AST, mais il s’avère que la panne était plus humaine.

Dans un système régi par des contrats, le contrat central doit être explicite.

Le mien ne l’était pas. J’ai laissé trop de structure implicite, et les agents ont commencé à compenser en faisant gonfler le cœur de l’app jusqu’à ce qu’elle s’effondre sous le poids de la lettre de la loi.

Il y a ce truc qui arrive quand on code. Votre esprit survole un vide comme celui-là et se dit : « Bah, ça devrait être évident, non ? »

Célèbres dernières paroles.

Mais je pense que c’est ça qui me semble glissant dans le Python moderne.

C’est devenu plus permissif, plus pragmatique. Plus comme le genre de truc qui a du sens dans l’urgence en production, et moins comme ce beau cristal de retenue personnelle qu’on peut observer à la lumière.

Tous les langages de programmation sont des suites de décisions sur les problèmes que vous résolvez, et pour qui, tout en sachant que personne ne sera jamais totalement satisfait de tous les compromis.

Plus un langage vieillit, plus il fait de compromis.

Et puis... boum ! Vous vous prenez le mur à un million de kilomètres-heure.

Je pense que les agents de codage galèrent aussi avec ça. Passée la phase de prototype, ils semblent avoir besoin d’une direction ferme sur l’endroit où placer la rigidité. Si les règles sont molles, l’architecture devient molle.

Et le mou n’est pas toujours mauvais. Mais il faut savoir que c’est là. Surtout quand c’est dans le plancher.

C’est en partie pour ça que j’aime autant Go. C’est plus prévisible structurellement.

Ça donne assez de flexibilité pour bâtir de vrais systèmes sans que la solidité devienne une négociation. Je ne pense pas que ça aurait réglé le problème des défauts de conception implicites, mais ça les aurait rendus plus évidents, plus tôt.

Quoi qu’il en soit, les bugs sont un signal précieux.