Hop, un petit thread vite fait feat. @_reflets_, sur "l'écoconception" dans le domaine du numérique et du développement en général.

Cette étude, que j'ai vu (re)passer, vise à comparer les langages de programmation du point de vue de la conso d'énergie, concluant que Ruby, Python et Perl sont les "langages les moins écologiques" https://medium.com/codex/what-are-the-greenest-programming-languages-e738774b1957 https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

Ce genre de comparatif est sans grande surprise, tous les informaticiens savent que les langages de "bas niveau" sont plus performants. A traitement identique ils consommeront moins d'énergie (le mot clé ici est "identique").

En résumé : moins un programme utilise de temps CPU (de temps de calcul sur les micro-processeurs) pour accomplir une tâche, plus il est performant et moins il consomme.

Des développeurs en devenir avec la fibre écologique seront peut-être tentés de faire le choix de tel ou tel langage en fonction de leurs "qualités écologiques" respectives, ce qui est, à mon avis, une fausse bonne idée chimiquement pure.

Ce benchmark est basé sur une suite d'algorithmes (https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game) que les auteurs de l'étude implémentent (écrivent) dans les différents langages et exécutent.

Mais ces tests n'ont donc que peu de rapport avec des usages du "monde réel". Si vous avez des développeurs dans votre entourage, demandez leur si ils ont déjà programmé des ensembles de Mandelbrot...

Je gage qu'ils seront peu nombreux à répondre par l'affirmative. D'autre part, ces tests ne tiennent pas compte des optimisations produites par certains environnements d'exécution pourtant "mal notés" ../..

sur certains types de traitements. A contrario, les performances d'un programme écrit en C, pourtant premier de la classe (han l'intello) pourront varier fortement en fonction de la manière dont il a été compilé.

Surtout, dans la vraie vie la plupart des programmes ne sont pas de "pures" implémentations d'algorithmes. Ils interagissent avec des bases de données, font des appels systèmes, ouvrent des fichiers, etc.

Et ces interactions ("les entrées-sorties") mobilisent beaucoup plus de ressources que le flux d'exécution du programme lui-même. Pour l'écrasante majorité des applications (certes pas toutes), le gain obtenu par l'utilisation ../..

de tel ou tel langage vis-à-vis de tel autre sera probablement très marginal par rapport à celui qu'un développeur pourra obtenir par exemple en optimisant la manière d'interroger une base de données.

D'autant plus que les développements ne se font pas dans un monde théorique parfait, les aspects financiers sont importants. Si vous vous lancez dans un projet d'écriture d'une application Web en C, il est probable ../..

que le coût de revient sera énorme comparé à d'autres langages, pour un gain de performances négligeable, nul, voire carrément négatif (il est généralement plus facile de faire de grosses erreurs avec des langages de "bas niveau").

En terme de productivité, cela reviendrait à vider une étable à la pince à épiler, en gros.

Dans la vraie vie, les clients attendent tous une application performante, donc économe en énergie. Mais peu sont prêts à payer l'effort d'intégrer la problématique de la performance (revues, optimisations, refactoring) dans le flux ../..

de développement. Pire, ils sont souvent responsables des mauvais profils de performance en surchargeant les applications et les interfaces graphiques de fonctionnalités foutraques et inutiles ../..

souvent inspirées par le beau-frère du gendre de la voisine qui a fait carrière dans le marketing après obtention de son diplôme dans une grande école de commerce.

Venons en, pour exemple, à la fabrication de @_reflets_. La plateforme a été développée entièrement "from scratch" sur le langage Ruby, qui rappelons-le, est dans les cancres du fond de la classe d'après ce fameux benchmark.

Et pourtant, le lecteur faisant montre d'un peu d'observation n'aura pas manqué de noter que le site est rapide, mais vraiment très rapide.

Comme nous disposions d'un budget de zéro euros tout pile, nous pouvions tout à fait encaisser un dépassement de budget de 10, 20, voire 50% :) Nous avons donc décidé de tout donner et d'y aller franco niveau perfs. Comment ?

La particularité des applications Web en général, et des sites de presse en particulier, c'est qu'elle produisent très peu d'opérations en écriture de contenu (quand le site sauvegardes des informations).

En revanche, elles génèrent énormément de lectures (quand le site génère une page, par exemple un article).

Nous avons donc fait le choix un brin radical de mettre **TOUT** le site dans un cache en mémoire (Memcached pour ne pas le nommer). De cette manière, 99,9999% des requêtes ne nécessitent quasiment aucun traitement par le code Ruby.

Pour ce faire, nous utilisons du cache en poupée-russe. Nous mettons dans le cache les "fragments" correspondant à nos contenus (articles, commentaires, etc), le code Ruby se contentant en gros de vérifier les horodatages ../..

de ces contenus pour vérifier qu'ils sont à jours, de regarder si l'utilisateur est abonné et deux ou trois autres trucs vite fait bien fait, puis de renvoyer les pages à la vitesse de l'éclair.

Plus d'accès à la base de données, plus de lecture de fichiers, plus de tâches longues et pénibles à effectuer, l'application n'effectue quasiment plus aucune tâche coûteuse.

L'expérience utilisateur en est bien meilleure, et notre infrastructure, pourtant modeste, encaisse sans moufter les pics de charge (en général quand @jacquesduplessy va faire des facéties sur BFMTV https://twitter.com/_reflets_/status/1567536809697071112) ../..

en dépassant rarement les 5% de charge CPU. Par ailleurs, nous avons beaucoup limité l'usage de Javascript, et pris le parti d'utiliser surtout du bon vieux HTML/CSS pour réaliser le fonctionnel. Oldie but goodie.

Et ça fait moins de boulot pour votre machine à vous !

@_reflets est donc sans doute un très bon élève en termes "d'écoconception", alors que le langage sur lequel est basé la plateforme est censé être l'un des plus mauvais de ce point de vue.

Donc si vous voulez apprendre la programmation, il n'y a pas de "mauvais" ou de "bon" langage. Il y a des langages qui ont des qualités et des défauts (notamment PHP, qui en a beaucoup 🤪) ../..

qui sont plus adaptés à certaines tâches ou à certains contextes, plus ou moins faciles à apprendre ou à maîtriser. N'écoutez pas les paroissiens. Choisissez au fur et à mesure de vos expériences, apprenez plusieurs langages.

Choisissez les langages qui amélioreront votre employabilité ou votre niveau de rémunération, et surtout : choisissez le langage qui vous apportera le plus de satisfaction intellectuelle.

Bref, puisque c'est la mode du placement produit, choisissez Ruby https://rubyonrails.org/doctrine#optimize-for-programmer-happiness 😁.

Et si vous êtes intéressés par le fait de connaître un peu mieux la plateforme technique de @_reflets, et les choix que nous avons faits, rien de plus simple : envoyez ARTICLE AU 81212.

The End.

La quantité de fautes d'orthographe la vie de ma mère je vais me faire éclater par @btreguier