Clojurians Log v2

J'ai partagé le lien vers cet article sur #news-and-articles: What Functional Programmers Get Wrong About Systems - Ian Duncan https://www.iankduncan.com/engineering/2026-02-09-what-functional-programmers-get-wrong-about-systems/ Voici la discussion HN correspondante, mais c'est l'article qui reste plus intéressant: https://news.ycombinator.com/item?id=46953491 Comme j'ai produit un "Key Takeaways" en français pour d'autres audiences, je le partage ici. L'article ne couvre rien de révolutionnaire au niveau des idées, mais c'est une bonne présentation et rassemblement d'aspects techniques que l'on aborde normalement de manière séparée et tactique. L'état de l'art fait que l'on ne peut agir qu'à ce niveau tactique, mais la vision d'ensemble proposée aide à naviguer vers une plus grande maitrise des sujets d'architecture et de la gestion des changements (SCM/CI/CD). Ce que j'en retiens: • FP et type checking permettent de valider/raisonner dans le cadre d'une seule unité de déploiement. Les vrais bugs difficiles et couteux se situent lorsque qu'on traverse les frontières, non seulement entre les systèmes, mais aussi entre leurs différentes versions de code et des données. C'est cela la nouvelle frontière qu'il faut franchir. • Bien identifier et gérer les versions qui sont concurrentes, pendant combien de temps, et combien de versions tournent en parallèle, ce qui implique de rendre visibles les propriétés de ces versions (les réifier), leur dépendences, à des fins d'analyse et d'instrumentation, i.e. gérer ces versions et leur cohérence globale par CI/CD voire idéalement un runtime control plane. • Il faut considérer les versions du code, mais aussi des données c'est-à-dire de leur schéma, les deux étant co-dépendants. Cependant le versionning des deux est encore géré de façon très/trop séparée. Les schema repository et les BD (bi)temporelles telles que Datomic peuvent grandement faciliter la besogne mais de façon partielle tant que leur co-dépendance n'est pas réifiée. • Bien connaitre et choisir ses invariants, pas seulement en isolation, mais à travers toutes ces frontières qui doivent être traversées. Les invariants cristallisés dans le code (ce qu'encourage le static type checking) peuvent à terme se transformer en une dette technique s'ils sont mal placés, e.g. dans plusieurs unités de déploiement plutôt qu'une couche transversale de contrôle. • Semantic-drift: il faut les éviter car impossibles à gérer automatiquement. Il faut apprendre à les identifier, l'article donne des exemples. • Event-sourcing est un style d'architecture assez récent qui fait ses preuves, mais la présence d'un event log met encore plus la pression pour gérer de manière cohérente les versions des données et les traitements associées. • C'est pas ce que l'article dit mais il implique qu'une analyse des incidents et bug passés peut permettre une meilleure identification des frontières à litiges, ainsi que les données qu'il faut réifier pour mieux gérer les changements des SI.