Évolution et défis de la programmation système moderne

Points clés

• La programmation système en langages établis comme le C et le C++ s’est améliorée ces 20-25 dernières années, mais cette expertise reste souvent dans une "communauté de l’ombre" peu visible.
• Les méthodes classiques de gestion mémoire (pointeurs, gestion manuelle du heap) sont complexes et sources de lenteurs.
• L’évolution du hardware a creusé l’écart entre vitesse des CPU et vitesse/lenteur de la mémoire, impactant négativement les performances.
• Les langages fonctionnels avec ramasse-miettes (garbage collectors) n’ont pas atteint les performances escomptées, à cause d’une non prise en compte complète de cette disparité entre CPU et mémoire.
• La complexité et les couches logicielles additionnelles (VM, frameworks, systèmes d’exploitation modernes) ralentissent considérablement le logiciel, souvent de manière exponentielle.
• Il y a un regain récent d’intérêt pour l’optimisation des performances et la réduction de cette complexité, menée par plusieurs développeurs indépendants et communautaires.
• Exemples récents montrent que des logiciels plus performants, écrits avec une attention plus directe au matériel et à la simplicité, peuvent être significativement plus rapides et agréables à utiliser (ex: FilePilot, certains terminaux comme Ghosty).

Détails importants

• Le paradigme de gestion du heap en C/C++ mène à une "jungle de pointeurs" à gérer manuellement, source d’erreurs et de lenteurs.
• Les années 60-70, l’invention de Lisp avec des structures cons a semblé naturelle, mais les architectures modernes avec cache hiérarchisé ne favorisent plus cette approche.
• La mémoire est bien plus lente que les CPU modernes, ce qui limite l’efficacité des stratégies perçues comme modernes (GC, allocations dynamiques).
• Beaucoup d'interprètes (Python) surchargent la machine avec des opérations coûteuses comme le boxing des int en objets complexes, impactant fortement la rapidité.
• Go et Swift adoptent un compromis intéressant avec un GC plus efficace mais évitent dans la mesure du possible le boxing, améliorant les performances globales.
• La croyance des années 90 selon laquelle la vitesse des ordinateurs rendrait la vitesse logicielle négligeable s’est avérée fausse.
• Le poids de l’existant logiciel : couches telles que Electron, React et autres frameworks multiplient les abstractions, ralenties par le système d’exploitation et les couches de virtualisation.
• Mathématiquement, la croissance des couches et de leur complexité cause un ralentissement non linéaire exacerbé du logiciel.
• Le hardware évolue vers plus de parallélisme, mais beaucoup de problèmes logiciels ne pourront être accélérés par cela.
• Le quantum computing, s’il vient, sera probablement un coprocesseur spécialisé, pas un remède général à la complexité logicielle.
• Exemples contemporains (Windows Terminal rewritten, FilePilot) illustrent que l’on peut, en donnant priorité à la performance, réécrire des logiciels beaucoup plus rapides et agréables, même avec une équipe très réduite.

Conclusions

• La complexité croissante des couches logicielles est une menace lourde pour la performance et la réactivité des logiciels modernes.
• La communauté reconnait de plus en plus ce problème et commence à s’y attaquer activement, avec des résultats encourageants.
• Il reste encore beaucoup à faire pour repenser les abstractions en programmation système afin d’éviter les surcoûts inutiles sans sacrifier l’ergonomie.
• L’optimisation concrète à bas niveau (gestion mémoire, structures, évitement du boxing, réduction des couches, meilleure intégration CPU-Mémoire) est toujours une voie essentielle pour améliorer les performances.
• Le progrès matériel seul ne suffit pas à résoudre les goulots d’étranglement logiciels : il faut repenser radicalement certaines pratiques et architectures logicielles.
• Le succès de projets indépendants et communautaires plus performants prouve qu’une autre approche est possible et souhaitable.