Cette étude pourra intéresser ceux pour qui l’écologie entre en considération dans le choix des techno & langages 
1 Like
Il faudrait ajouter le temps de programmation du code, temps qui peut être plus long sur un langage compilé très typé, et plus court sur un langage dynamique. Après, est-ce que le développeur utilise un écran à tube, lcd, plasma ? S’éclaire au filament, au gaz, à la led ? Mange de la viande, des pizzas ou est végétarien ? Bois de l’alcool, un peu, beaucoup ?
D’après « une étude américaine indépendante », les développeurs Rust codent lentement, sont carnivores, dorment la lumière allumée au filament, sur un écran à tube et dégagent beaucoup de CO2.
Au contraire, les développeur Python, s’éclairent à la led, sur des écrans à led, sont végétariens, beaux , intelligents, équilibrés, se couchent tôt en éteignant toute lumière, programment vite et plantent des arbres.
Franchement, y a pas photos. (Comment ça vous ne trouvez nulle part cette étude…). 
Ok je sors…
6 Likes
Tu m’as fait bien rire mais, franchement, discussion sur celui qui en a une plus grosse.
Chaque langage a ses avantages et inconvéniants et est plus adapté à un programme qu’à un autre. De même, un développeur sera plus à l’aise avec celui qui correspondra le mieux à sa manière de penser.
Donc, rien de nouveau concernant le développement de la monnaie libre.
Et le temps de débogage et de maintenance ? hum ? Bien plus élevé pour un code non-typé, j’ai pu en faire l’expérience au boulot, ayant vécu les 2 situations (1 projet en angularjs vs un projet en typescript).
De plus, la consommation d’un programme très majoritairement due a son utilisation, pas a son développement, surtout pour les programmes très utilisés.
Dans le cas de Duniter par exemple, le programme est utilisé directement par une centaine d’utilisateurs et permet le fonctionnement d’une monnaie comptant environs 3000 utilisateurs pour moins d’ 1ETP en développeur. Le coût énergétique du développeur est donc négligeable pour un programme très utilisé.
Franchement les amis je ne comprend pas vos réactions ?!?
Si tu fait un projet perso qui sera peu utilisé, alors la consommation du programme qui en résulte importe peu, mais si tu réalise un programme qui a vocation a être utilisé massivement, alors la question se pose, (en tout cas pour moi, et pour vous aussi sinon vous ne vous seriez pas senti visés 
).
Après chacun fait ce qu’il veut, mais je trouve cette étude intéressante. Le Go et le Java sont plus efficients que je ne l’aurais pensé, j’ai appris des choses, je pense que d’autres peuvent en apprendre aussi 
Après concernant la Ğ1, est ce que l’efficience énergétique de son fonctionnement est un objectif ? Je ne sais pas, personnellement je trouverai plus cohérent que s’en soit un, mais je ne sais pas quel est votre point de vue la dessus.
lol quel troll 
Ceci étant je suis végétarien et circule uniquement a vélo donc ça fait au moins un contre-exemple 
1 Like
C’était de l’humour et tu l’as bien compris 
Blague à part, cette étude est très intéressante, et m’a surpris comme toi sur plusieurs points.
Leur classement par paradigme me laisse perplexe, sachant que python est un langage impératif,
et que « scripting » ne me paraît pas être un paradigme (impératif, déclaratif, objet, fonctionnel, de mémoire…).
Le python est dit « interprété », mais pourtant il passe par une phase de jit compiler qui fait un bytecode (les fichiers .pyc), ce qui se rapproche un peu du principe de Java non ? Un bytecode est donc considéré comme un code à interpréter dans leur étude ?
1 Like
Oui moi aussi, le Rust est aussi mal classé car ce n’ai pas vraiment un langage impératif mais multi-paradigme (ça mélange du fonctionnel, de l’orienté objet, du procédural, etc).
Mais cette catégorisation par paradigme n’est qu’une façon d’aider le lecteur a ce repérer parmi tout ces langages (27 c’est beaucoup) et a placer rapidement dans une case les langages qu’il ne connaît pas du tout. Cette catégorisation grossière n’entre pas du tout en compte dans les mesures des performances des différents langages et les classements qui en résultent
La méthodologie de cette étude est tout de même très sérieuse, CLBG, RAPL, etc (beaucoup plus poussée que ce que j’ai pu voir par le passé) et couvre beaucoup de langages.
Tout bon scientifique se doit de considérer ces résultats
En même temps le “langage python” a plusieurs formes d’exécution : il peut être compilé (cython), interpreté (python) etc… JavaScript aussi possède plusieurs formes d’exécution/compilation (wasm).
C’est bizarre de pas avoir distingué tous ces cas. Parce qu’il est évident qu’un code, quelque soit le langage, qui ne passe pas par une phase de compilation nécessitera plus de cpu. On apprend rien quoi. Le langage n’est pas le code exécuté derrière…
Sinon pour du debug le typé est probablement plus efficace (encore que ça dépend de la nature du bug), mais pour de l’évolution, le non typé est probablement plus rapide (ce qui explique pourquoi la recherche en réseau de neurones fait 90% de son code en python).
Bref franchement tout ceci c’est vraiment “a celui qui a la plus grosse”, ça existe depuis qu’il existe plus de 1 langage de programmation et ça a franchement très peu d’intérêt.
A chaque outil son objectif, tu peux utiliser un tournevis pour planter des clous mais certainement pas un marteau pour visser des vis.
Ce qui m’intéresse surtout ce n’est pas la vitesse, mais la consommation énergétique.
L’étude est une publication scientifique qui explique les objectifs, les biais induits par les différentes approches d’autres études, et qui détaille avec des graphiques les résultats. Dès l’introduction ils déclarent que mieux connaître les propriétés d’énergie, de vitesse et de ram permettront de choisir le langage le plus adapté aux objectifs/contraintes d’un projet.
Sincèrement, regardez l’étude (en anglais), elle est beaucoup plus sérieuse et intéressante que le texte de developpez.com qui ramène ça à qui a la plus grosse…
2 Likes
Développez point com
Ze référence non ?
Tous les langages ont leurs atouts et défauts. D’expérience, ce qui fait la différence est la richesse, la stabilité de leurs bibliothèques et l’ouverture de la communauté qui l’utilise… Une fois dans la boite (ou l’application), c’est la rapidité d’exécution et l’expérience utilisateur qui décide
Depuis toujours, les tribus évoluent… Aujourd’hui javascript en s’exécutant coté client et serveur a envahi tous les espaces, python robuste et polymorphe a renforcé les racines des systèmes… Il semble que la recherche en outils de développement renouvelle C++ en Rust… Moi j’aime toutes les tribus, même encore la PHP… Sans oublier l’Assembleur !! J’ai quand même laissé de coté le Cobol et le Fortran 
Au final, ce qui compte, c’est l’outil qui est forgé et l’art des forgerons qui l’auront fait exister!
Quand l’outil est libre, son utilisateur le devient sans le savoir… Mais ne le sera jamais tant que 100% de ses outils ne le sont pas… La monnaie libre dépasse à mon avis le simple cadre de la monnaie, sa WOT offre l’Identifiant Unique Libre, clef tant convoité par les Goolgoth du web!!! A l’heure où Facebrok propose à nos États de devenir garant des identités et de la monnaie mondiale. Il serait bien opportun de forger un écosystème numérique libre qui puisse faire alternative…
- IPFS a grand peine à sortir son Filecoin, mais ouvre le chemin vers un Web3.0 sans Datacenter
- Libremesh attend son libre router pour relier les territoires sans Opérateur.
- Des centaines de services décentralisés sont encore dans la marmite du libre…
Il y a un truc à jouer, non?
4 Likes