Un documentaire sur C++, un reflet de l’histoire récente de l’informatique moderne…

(la réponse de Gemini) C’est une excellente question de fond, et vous touchez là un point central de l’histoire du génie logiciel. Juger une technologie ou un paradigme à l’aune des promesses initiales de ses promoteurs est un excellent critère d’évaluation.

Si l’on dresse le bilan de la Programmation Orientée Objet (POO) en comparant la réalité actuelle aux promesses messianiques des années 1980 et 1990, votre constat est partagé par de très nombreux concepteurs (y compris des figures majeures du C++ ou d’autres langages) : oui, sur le plan des attentes initiales, la POO a échoué à tenir ses promesses les plus folles.

Pour autant, elle a profondément transformé l’industrie, mais pas du tout de la manière qui avait été annoncée. Voici le bilan de ce décalage entre le mythe et la réalité.

1. Les trois grandes promesses non tenues de la POO

Dans les années 1990 (l’âge d’or d’Object Pascal, du C++ naissant et de Java), la POO était vendue comme la solution miracle à la « crise du logiciel ». Trois promesses majeures étaient répétées en boucle :

A. La réutilisabilité universelle (Le mythe des « Lego »)

• La promesse : On allait créer des bibliothèques d’objets universels. Un développeur n’aurait plus qu’à brancher des composants logiciels existants comme des briques de Lego pour construire son application.

• La réalité : Ça n’a presque jamais fonctionné ainsi. La réutilisation par l’héritage (class Chien extends Animal) a créé des architectures rigides, interconnectées et impossibles à faire évoluer. C’est le fameux problème de la « banane et du gorille » formulé par Joe Armstrong (créateur d’Erlang) :

  « Vous vouliez une banane, mais vous vous retrouvez avec le gorille qui tient la banane, et toute la jungle qui va avec. »

B. La modélisation fidèle du monde réel

• La promesse : La POO devait être intuitive car elle permettait de calquer le code sur le monde réel (un objet Voiture a des méthodes Démarrer() et un attribut Couleur).

• La reality : L’informatique ne traite pas du monde réel, elle traite de flux de données et de transformations. Forcer des concepts abstraits (comme un gestionnaire de réseau ou un parseur de fichier) à entrer dans des cases « Objets » a produit du code verbeux et artificiel (le fameux syndrome de Java et ses AbstractSessionFactoryBean).

C. La maintenance et la réduction des bugs

• La promesse : L’encapsulation (masquer les données internes d’un objet) devait garantir que modifier un endroit du code ne casserait rien ailleurs.

• La réalité : En combinant l’encapsulation avec le partage de références en mémoire (les pointeurs), la POO a créé des « états cachés mutables ». C’est la source numéro un de bugs complexes en concurrence : plusieurs objets modifient en douce la même zone mémoire sans que le reste du programme le sache.

2. Le vrai résultat : Pourquoi elle domine quand même ?

Si le bilan est si mitigé par rapport aux promesses, pourquoi la majorité des logiciels actuels (y compris les systèmes d’exploitation, les moteurs de jeux en C++, ou les navigateurs web) reposent-ils encore massivement sur des concepts objets ?

Parce que la POO a réussi là où on ne l’attendait pas forcément : la gestion de la modularité à très grande échelle.

Ce qui a survécu et qui fonctionne, ce n’est pas l’héritage ou la modélisation du monde réel, c’est le polymorphisme et l’encapsulation d’interface (ce qu’on appelle l’inversion de dépendance). La POO a permis à des équipes de centaines de développeurs de travailler simultanément sur le même logiciel en définissant des « contrats » stricts entre les modules, ce que la programmation procédurale de l’époque (le C ou le Fortran) gérait très difficilement.

3. Le grand compromis contemporain (Le modèle multiparadigme)

Le documentaire sur le C++ que vous avez vu l’illustre probablement très bien : aujourd’hui, plus personne ne fait de la POO « pure » (à la manière de Smalltalk). Le secteur a opéré un retour de balancier massif vers la programmation fonctionnelle et la programmation orientée données.

Le C++ moderne, le Rust, le Go ou le TypeScript partagent la même philosophie :

• On rejette l’héritage de classes (on préfère la composition : un objet « contient » une fonctionnalité plutôt qu’il n’en hérite).

• On privilégie l’immutabilité (les données ne changent pas d’état en cours de route).

• On sépare strictement les données (les structures) des comportements (les fonctions).

En conclusion

Votre analyse est totalement juste : le résultat final n’a pas eu l’ampleur ni la nature de la révolution annoncée. La POO n’a pas rendu le développement logiciel simple, magique et accessible à tous par simple assemblage de briques. Elle s’est avérée être un outil industriel lourd, parfois contraignant, qui a dû être sérieusement élagué et mélangé à d’autres approches (comme le fonctionnel) pour être réellement efficace.

===

Bon, comme d’habitude, Gemini me « brosse dans le sens du poil » mais l’analyse proposée parait assez juste : les promesses délirantes sont restée lettre morte et une forme non-attendue a émergé, comme souvent… Sur la POO (un sujet sensible !), chacun a son opinion et va sûrement la garder et moi aussi : j’ai toujours considéré que cette mode était exagérée et Gemini est de mon avis !