Un fil de bon sens de vrais gens du métier qui expliquent pourquoi, en pratique, les études sur l'efficacité écologique des langages sont extrêmement trompeuses (mais j'ai aussi un mot à dire là dessus). https://t.co/XmA7blzhB6

Ce papier particulier est là, il date de 2017. Et le lire est intéressant, parce que c'est plutôt fouillé par rapport aux torchons qu'on voit habituellement passer en la matière. https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

Le papier tente d'évaluer réellement la conso énergétique à partir d'une micro-API Intel de mesure. C'est toujours de grosse louche mais ça prend en compte la conso CPU et la conso mémoire.

Le premier gros problème méthodologique que je vois c'est que le papier ne fait tourner chaque code qu'une fois. Donc du Python/Ruby et autres langages "dynamiques" (pour ne pas dire interprétés) vont être indûment pénalisés par le coût élevé de démarrage de tout le bastringue.

Sur un site web, comme dans le cas de @TouitTouit (et de pas mal d'autres gens), le code va en fait être chargé 1 fois et tourner des heures voire des jours (suivant le nombre de requêtes gérées par 1 instance ; on peut vouloir le limiter pour certaines raisons).

Donc on retombe là sur l'absence de distinction coûts fixes/coûts marginaux qui fausse pas mal d'estimations environnementales. On impute les coûts fixes au petit bonheur, et alors sur 1 instance unique c'est un peu brutal, personne ne fait ça.

La seule partie citée partout de l'étude (y compris par les auteurs) est le tableau "général" attribuant à chaque langage une unique note, comme s'il pouvait exister un classement objectif unique des langages. Ce n'est pas du tout le cas, les circonstances sont très variables.

Le tableau cité en fin d'étude est plus intéressant, montrant clairement que suivant les critères prioritaires, le classement change grandement. Mais même là, on reste quand même dans le réducteur en raison des critères externes (type d'usage, type de dev etc). https://t.co/5N5x5oWYR5

Et puis à la fin, quand on a besoin de perfs sur un langage lent, les surcouches d'optimisation de manquent pas et les dévs et exploitants ne restent pas coincés comme des moules à encaisser l'impact du langage. @TouitTouit cite la moulinette de précalcul type site statique,

Il y a tout un tas d'autres choses. #spoiler c'est un métier et #spoiler2 tout le monde a intérêt à ce qu'un site marche le mieux possible avec le moins de ressources possibles, même si ce n'est jamais totalement parfait. Arrêtons de prendre les gens pour des idiots, peut-être.

#spoiler3 on aura plus tendance à se casser la tête à optimiser un gros site à fort trafic (donc fort impact et fort gain) qu'un site à petit trafic (faible impact et perte de temps, les optimisations de perfs sont aussi une forme de coût fixe=impact qu'il faut amortir ensuite).

#spoiler4 tout ça est quasi directement corrélé avec des coûts (énergie + infra/hardware + visiteurs perdus si c'est trop lent) donc la motivation à faire des sites à faible impact est directement alignée avec le portefeuille, et ça c'est plutôt rassurant, non ?