Qu'en pensent les spécialistes ?
Tu n'as, je pense, pas idée de l'impact écologique de choix informatiques. Aujourd'hui, 95% des mails qui transitent sur internet sont du spam et la gestion de ce spam consomme l'électricité de quelques tranches nucléaires rien qu'en Europe. On pourrait lutter contre ce spam en utilisant des serveurs de mail gérés correctement par des gens compétents.
C'est exactement la même chose pour les logiciels. Lorsqu'un logiciel est écrit correctement, il est plus compact, tourne plus vite, bref, c'est optimisé. Lorsqu'il est écrit à l'arrache avec un langage objet, il est beaucoup plus gourmand parce que le langage part du principe que les données procèdent du programme et non le contraire avec la conséquence immédiate que lorsqu'on a besoin d'appeler la variable "banane", il faut siffler une classe "singe" pour apporter cette banane et que la classe "singe" refuse de venir sans avoir avec elle tous ses copains de la jungle. Et c'est sans compter avec les garbage collectors (ou ramasse-miettes) parce que l'utilisateur ne doit pas gérer lui-même la mémoire... Suspect
L'utilisation de tels langages demande ainsi des processeurs plus rapides (quitte à ce qu'ils passent leur temps à traiter des informations totalement inutiles dans des structures de données vides) et beaucoup plus de mémoire. C'est aussi ce qui explique que depuis une dizaine d'années au moins, la vitesse d'exécution des programmes ne s'est plus accrue malgré l'augmentation des performances des ordinateurs. Il y a donc un coût écologique (puisqu'on pourrait faire la même chose avec grosso-modo des machines 20 fois moins rapides et avec 20 fois moins de mémoire) provenant d'une surconsommation d'énergie et d'un surdimensionnement des capacités de calcul et de mémoire.
Ce qu'il faut aussi noter, c'est la vitesse de développement du code. En utilisant un langage impératif (typiquement Cobol, un ancêtre qui est toujours bien vivant puisque la majorité du nouveau code informatique est écrit en Cobol, Cobol étant le seul langage qui permette de travailler en virgule fixe, pour la comptabilité, c'est très important), procédural (Fortran, C...) ou fonctionnel (LISP et dérivés), il faut penser ses algorithmes et écrire des choses de façon propre. La programmation commence par une feuille de papier, la conception est correcte et il n'est pas rare de trouver en production du code dont les premières lignes ont été écrites il y a plus de 40 ans. En utilisant des langages abjects, pardon objet, on peut utiliser des méthodes "agiles" (un joli nom !) puisqu'on part des données pour écrire le code sans réellement avoir pris le temps d'écrire un cahier des charges. Le code est alors jetable et à chaque nouveau besoin, on réécrit tout. Typiquement, les logiciels écrits en Java sont entièrement réécrits entre la version n et la version n+1 parce qu'il est plus rapide de tout réécrire que de comprendre les interactions subtiles entre objets. Seul le concepteur pourrait à la rigueur s'y retrouver. Mais il est vrai qu'on trouve beaucoup plus de bidouilleurs sur des langages objets que sur les autres. On ne peut pas bidouiller avec un langage qui n'est pas objet.
Pour fixer les idées, juste un exemple. J'ai dû coder à l'arrache un algorithme A* pour un test sur un coin de table. Un A*, c'est un algorithme capable de trouver le plus court chemin dans un graphe. Mon graphe comportait plus de 15 millions de segments et un Dijkstra ne convenait pas car bien trop lent. Je n'avais pas le temps de coder un A* et j'ai cherché dans les bibliothèques existantes un A* que je pourrais utiliser 'out of the box'. J'en ai trouvé un, dans la bibliothèque Boost (C++). J'ai donc codé une interface C++ à mes routines et... et le calcul en question a mis à genou mes machines de calcul (8 Go de mémoire, 70 Go de swap et 32 processeurs). Pourtant, un tel graphe doit pouvoir tenir dans la mémoire du calculateur en question. Un coup de debugger et j'ai pu constater que les objets Boost::graph était dérivés de la libstd du C++ et qu'à chaque segment du graphe (dont les seules informations pertinentes étaient point source 32 bits, point destination 32 bits, pénalité du segment 32 bits) correspondait une structure de plus de 1 Ko ! J'ai donc passé quelques jours à réécrire un A* dans un langage procédural (je n'ai pas trouvé d'A* en C ou équivalent). Il tournait 20 fois plus vite en consommant en tout 25 fois moins de mémoire. Rien que la consommation électrique était divisé par plus de 20 !
Plutôt que de fermer Fessenheim, on devrait interdire l'exécution du code de merdre. Ça, ce serait écologique !