Discussion :

[Invité]

En premier lieu, il n'y a pas de rapport entre design patterns (patrons de conception) et sécurité. Sauf si par sécurité, vous sous-entendez "un code plus maintenable/portable/interopérable" ?

Les design patterns ne sont qu'un ensemble de "bonnes pratiques" de conception (au plus, reconnues comme telles par l'industrie).

"L'apprenant" a plutôt intérêt à comprendre et pratiquer les différents paradigmes de programmation et architectures logicielles existantes.

Au temps pour moi, j'aurai dû les citer avec mon précédent commentaire.
Un exemple de 3 Design Pattern servant la sécurité :
- Gatekeeper
- Federated Identity
- Valet Key

[zecreator]

Oui programmer peut necessiter de l'experience, c'est un vrai metier qui en plus de demander de la logique, demande aussi d’être créatif, d'etre capable de composer avec l'existant. Pour moi programmer est assez proche de metier comme la serrurerie, l'horlogerie, ou même la menuiserie, et il me semble que le compagnonnage serait un excellent moyen de devenir un "bon" programmeur. Tout le monde peut prendre 3 planches en bois et les clouer pour faire une table, n'empêche que si tu danse dessus ca n'ira pas. Pour savoir faire une table qui tient quand tu dansera dessus, tu faudra un peu plus d'experience.

L'histoire de "La table", c'est vrai pour tout les métiers de fabrication. Si je veux faire une Charlotte aux fraises, je peux prendre un kit tout prêt. Ce ne sera pas la Charlotte aux fraises du pâtissier 5 étoiles, mais en même temps, je ne veux pas devenir pâtissier, je veux juste faire un gâteau.

Il y a une réalité de plus en plus présente : les entrepreneurs n'ont plus l'envie ni les moyens de passer par des presta pour dev leurs applications. Le "no-code" les attirent de plus en plus, et les outils deviennent très efficaces même sur des apps complexes. Et si cela demande un peu plus d'entrer dans le code, il existe aussi des langages low-code qui sont à la portée de tous.

Je crois seulement que dans un futur très proche, le métier de développeur tel qu'on le vie aujourd'hui, va changer. Il y aura de moins en moins de code à produire, et avec l'émergence de l'AI, créer et modifier une application complexe sera de moins en moins un travail d'expert.

Je vois des posts qui disent "un programmeur choisit les bons outils, les bonnes bibliothèque". Je dirais, le programmeur qui bosse tout seul peut se permettre de choisir les bon outils, celui qui bosse sur un projet qui contient plus de 2 millions de lignes de code.

Les projets dont tu parles, avec des millions de lignes, difficiles à maintenir sans une équipe de plusieurs devs, c'est sans doute aussi un coût énorme pour les entreprises.

[Bousk]

Tous les X ans y'a une nouvelle tentative/percée de "nocode" et des marketteux et business non techniques s'emballent et se voient déjà contrôler parfaitement une machine pour faire leurs tâches.
Ça reste un rêve, et le restera imo. Ne serait-ce que parce que ces mêmes personnes on sait très bien ne sont pas capables d'écrire des specs correctes ce qui ne facilite jamais les développements.
Il existe des langages qui le permettent, et c'est suffisant pour certains, mais c'est pas possible que ça couvre tous les cas.
Je prends ce qui se fait dans le jeu-vidéo : le blueprint de Unreal Engine est formidable, tu peux faire ton jeu entier en BP. Presque tout ce qui est faisable en C++ l'est en BP.
Et certains le font.
Mais ce truc est aussi un puit à performance, et si le projet est un peu gros ou vise un peu de performances, il faudra les réécrire en C++.
C'est aussi pour ça que les frameworks web à la Magento, Joomla, Wordpress etc ont été créés. Et pour avoir un site correct au bout du compte il faut quelqu'un pour les personnaliser.

RDV dans 5 ans pour la prochaine poussée de la lubie nocode.

[Mickael_Istria]

Je te rejoins sur les IDE qui ont besoin de 2Go de SDK et de plugins pour t'afficher un simple "Hello world" qui pèse 60 Mo à l'arrivée. Les usines à gaz à la Eclipse et Visual Studio, j'ai du mal à croire que l'on arrive encore à être productif avec de telles marmites.

Pour info, Eclipse IDE demarre assez bien sur 128MB et un Hello World en Java ne pese que quelques bytes.
Les IDEs ne sont pas faits pour etre legers, ils sont faits pour rendre efficace. Rendre un developpeur efficace, ca consiste a detecter des bugs a l'avance, a suggerer des constructions de code performantes, a aider au debuggage... Tout ca avant que ce meme developpeur ait a builder/deployer/tester l'application. Ce ne sont pas des operations legeres, et il est normal qu'elles consomment de la resource. Mais au final, tout cela n'est rien par rapport au gain d'efficacite: un developpeur qui utilise un IDE avec de l'assistance et de la validation a la volee et du debug efficace sera facilement 3 a 4 fois plus productif qu'un developpeur qui ne fait que de l'editeur de texte avec peu d'assistance, des commandes console pour builder et qui passe son temps a switcher entre les 2 et a lire des lignes de codes la ou une IDE te souligne le code en rouge des que tu l'ecris.
Par contre, il est vrai qu'un bon langage de programmation qui de par sa syntaxe et ses APIs emmene les utilisateurs et ecrire le meilleur code possible augmente naturellement l'efficacite de ses utilsateurs a outil egal.

[thamn]

Les projets dont tu parles, avec des millions de lignes, difficiles à maintenir sans une équipe de plusieurs devs, c'est sans doute aussi un coût énorme pour les entreprises.

Je pense que tu comprends que ces projets n'on pas dans leur specifications un point qui indique une nécessite d'avoir des millions de lignes, si ils finissent avec des millions de lignes c'est par necessite et pas un objectif en soit (j'ai du mal a croire que je suis en train d'expliquer ca mais bon . Le no-code comme tu appelle ça (ce qui est tentancieux puisque si tu le dessine ou que tu l'ecrive, tu manipule toujours un moyen de communiquer avec un automate) est déjà utilise pour pas mal d'application (par exemple, scripting dans le jeux video, edition de VFX toujours dans le JV, generation procedurale, ou meme musique / video avec Max4Live, Reaktor, PureData), et ce n'est pas magique, tous ce que tu n'as pas a faire toi meme pour que ca tourne correctement c'est parce que quelqu'un l'a deja fait pour toi.
De même que les programmes capable de générer du code ne font rien de magique, et comme toujours avec l'apprentissage statistique, tu a enormement de possibilite de variation importante entre le resultat que tu espere et le resultat qui tu obtiendras, alors tu pense vraiment qu'on va bien vouloir faire des plans sur la cometes en esperant que l'IA qui va generer le code dont tu as besoin va effectivement generer du code qui te peteras pas dans les doigts?

Ce no code est un vieux serpent de mer qui ne marche qu'au oreilles des gens qui ne comprenne rien au difficultés de la programmation. Encore une fois, torcher un programme qui a l'air de faire ce qu'il faut c'est possible rapidement, faire un programme performant qui gère bien les erreurs et est fiable, c'est une autre affaire. Mais je pense que ça demande évidement de le vivre pour le comprendre j'imagine.
De meme, si c'etait possible d'avoir une recette miracle pour avoir des programmes qui ont toutes les qualites qu'on attend d'un programme, tu pense bien qu'on aurait automatise ca.. Enfin apres si t'as une vrai solution, moi je suis flemard dont je sera i preneur si tu trouvais une recette magique

[Bruno]

Pourquoi l'utilisation du langage de programmation Python serait en train de « détruire la planète »,
d'après Mohammed Ayar

Dans une étude intitulée : Efficacité énergétique dans les différents langages de programmation et publiée en 2019, six chercheurs de trois universités ont révélé que Perl, Python et Ruby sont les langages de programmations les plus voraces en énergie. Python a des résultats médiocres en termes de puissance et de temps d'exécution, et est même moins performant que Lua et Perl en termes de puissance. Pourquoi le problème c'est Python et pas Perl ou LUA ? Parce que c'est le plus utilisé.

Alors que les uns se plaignent d’une possible destruction de notre planète du fait des différentes technologies en place aujourd’hui, les autres pensent au contraire que la technologie peut résoudre les problèmes environnementaux. Dans une étude intitulée : Efficacité énergétique dans les différents langages de programmation et publiée en 2019, six chercheurs de trois universités portugaises ont révélé que Perl, Python et Ruby sont les langages de programmations les plus voraces en énergie. Pour comparer correctement l'efficacité énergétique entre différents langages, il faut obtenir des implémentations comparables de solutions à un ensemble représentatif de problèmes. Et c’est ce qui avait été fait par les chercheurs des universités portugaises.

« Malgré les inconvénients de Python, j'ai toujours été convaincu que la proposition de valeur de Python - lisibilité, maintenabilité, communauté - peut difficilement être surpassée. Cependant, au fur et à mesure que je m'enfonce dans le terrier du lapin, de nouveaux inconvénients cachés ont commencé à faire surface. Des inconvénients sur lesquels je ne pouvais plus fermer les yeux. L'un de ces inconvénients est la durabilité », écrit Mohammed Ayar.

Avec l'adoption croissante des appareils sans fil, il est plus que jamais temps de coder en tenant compte de la consommation d'énergie. Les téléphones mobiles, les ordinateurs, les tablettes et les gadgets technologiques sont alimentés en électricité et consomment de l'énergie. Intégrées à ces appareils, les applications déterminent la consommation d'énergie, et les logiciels qui consomment moins d'énergie sont dits « économes en énergie ». Lorsqu’un téléphone surchauffe, c'est parce que vous utilisez une certaine application. La chaleur excessive, à son tour, vide votre batterie, ce qui vous oblige à charger votre téléphone. Plus vous chargez votre téléphone, plus il consomme d'énergie. De même, moins vous chargez votre téléphone, mieux c'est - pour votre batterie et pour l'environnement.

Il y a une question qui démange tout programmeur soucieux de l'énergie. Cette question est la suivante : un programme plus rapide est-il, de par sa conception, économe en énergie ? Les réponses à cette question sont assez diverses. Certains disent qu'un programme plus rapide a tendance à être économe en énergie parce qu'il se ferme plus tôt. D'autres adoptent une approche mathématique et suggèrent que ce n'est pas toujours le cas :

E (Energy) = P (Power) x T(Time)

La comparaison des performances des logiciels est une tâche suffisamment complexe. Les logiciels peuvent être développés à l'aide de différents langages de programmation et de différents frameworks. De même, différents algorithmes peuvent produire le même logiciel. Les langages de programmation ont historiquement été la métrique par défaut dans l'espace énergétique. Mais là encore, il est possible de rendre un langage de programmation plus efficace qu'un autre en optimisant le compilateur/interprète, en améliorant les frameworks/librairies.

La consommation d'énergie aurait été difficile à calculer s’il nexistait pas des techniques établies (par exemple, le RAPL d'Intel, Running Average Power Limit Energy Reporting, Qualcomm TrepN...) qui produisent des mesures de consommation d'énergie assez précises. Cependant, il y a un avertissement. RAPL n'est supporté que par les chipsets d'Intel. Par conséquent, si vous n'utilisez pas un processeur Intel et que vous souhaitez effectuer ces tests sur votre machine locale, il est possible d’explorer d'autres interfaces de rapport de consommation d'énergie (par exemple, le Trepn Power Profiler de Qualcomm).

Cela dit, pour embellir RAPL en Python, nous pouvons utiliser la bibliothèque pyRAPL. Java dispose de JRAPL et C de RAPL. Le script Python ressemble à quelque chose comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
import pyRAPL

pyRAPL.setup() 

@pyRAPL.measure
def doSomething():
# Instructions to be evaluated.

doSomething()

Temps

Afin de mesurer le temps, Mohammed Ayar utilise un script simple qui permet de mesurer le temps d'exécution d'un programme. Il existe différents moyens d'y parvenir, voici un script simple qui le fait à partir de références :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
from time import time...
while (i < N):
   start = time()
   ...
   # insert program here
   ...
   end = time()
   ...# Calculate average taken time
...

Selon Mohammed Ayar, il est difficile d'obtenir directement la puissance car son unité (W) est plutôt un quantificateur théorique. Par conséquent, en suivant l'école de pensée qui stipule que l'énergie dissipée (J) = Temps (S) x Puissance (W), il est possible de calculer facilement la puissance consommée par chaque langage de programmation.

La dernière pièce du puzzle consiste à choisir un programme mis en œuvre de manière similaire dans différents langages de programmation. L'idée est que choisir un programme optimisé dans un langage et algorithmiquement déficient dans d'autres rendrait la comparaison biaisée, tuant la robustesse de l'expérience. Pour éviter ce problème, Mohammed Ayar emprunte les problèmes de référence proposés dans The Computer Language Benchmark Game (CLBG).

CLBG est une initiative open source pour aider à mesurer les performances de différents langages de programmation. Il propose un ensemble de problèmes informatisés optimisés pour différents langages de programmation afin de garantir une comparaison précise des performances. Tous les éléments réunis, le calcul de l'énergie (E), du temps (ms) et de la puissance (W) conduit aux chiffres suivants :

Comme nous pouvons le constater, Python se trouve malheureusement en bas du classement. Il a des résultats médiocres en termes de puissance et de temps d'exécution. En fait, Python est même moins performant que Lua et Perl en termes de puissance. Il se trouve qu'ils sont nettement plus lents. D'où leur forte consommation d'énergie. En réduisant les langages de programmation aux langages interprétés, nous intégrons les chiffres ci-dessus dans un graphique pour les rendre plus expressifs.

À la lecture de cette figure, nous remarquons que Python est le troisième langage le plus mauvais en termes de consommation d'énergie du CPU, précédé par Lua et Perl. En revanche, le C domine les langages de programmation en termes de consommation d'énergie, ce qui en fait un pari intéressant pour les logiciels verts.
Les deuxième et troisième places reviennent respectivement au C++ et à Rust, ce qui confirme l'engouement massif pour Rust dans la communauté logicielle. La principale mesure sur laquelle Mohammed Ayar c’est appuyé dans cette analyse pour représenter la durabilité est la consommation d'énergie (E).

L'énergie est une forme de chaleur qui se manifeste lorsqu'un courant électrique traverse une résistance. « Ayant une formation d'ingénieur en électricité, je trouve que l'énergie (E) en joules est le meilleur candidat pour représenter la durabilité, car c'est un sous-produit des déchets solides », écrit Mohammed Ayar.

Cela dit, on aurait pu mettre « Perl détruit la planète » ou « Lua détruit la planète » en titre, car leur consommation d'énergie est plus élevée que celle de Python. Cependant, aucun des deux n'est utilisé autant que Python. Python est très utilisé dans l'industrie, en particulier dans l'intelligence artificielle et l'apprentissage automatique. En fait, les géants de la technologie, dont Google et Meta, font pression pour l'utilisation de Python.

Toutefois, Mohammed Ayar note que Python n'est pas un langage de programmation écologique en soi. Son empreinte énergétique est en moyenne 40 fois supérieure à celle du C, du C++ et du Rust. Le C et le C++ seraient naturellement difficiles à utiliser pour certains. Lors d’une conférence d’AWS tenue l’année dernière, Shane Miller, présidente de la Fondation Rust, et Carl Lerche, chef de projet de Tokio, ont plaidé en faveur de l'utilisation de Rust pour minimiser l'impact environnemental, tout en précisant que sa courbe d'apprentissage abrupte rendait la tâche difficile.

Rust est un langage de programmation compilé multiparadigme, conçu par Graydon Hore alors employé chez Mozilla Research, avec la contribution du créateur de JavaScript Brendan Eich. Utilisé par plusieurs grandes entreprises et par de nombreux développeurs dans le monde, Rust est devenu le langage de base pour certaines des fonctionnalités fondamentales du navigateur Firefox et de son moteur Gecko, ainsi que pour le moteur Servo de Mozilla.

Rust fait partie des langages de programmation les plus efficaces. La source citée pour cela est l’article susmentionné, de 2017, qui a mesuré les performances, l'utilisation de la mémoire et l'efficacité énergétique de 27 langages de programmation, et a placé C comme le plus efficace, mais Rust juste derrière avec seulement trois pour cent de plus d'utilisation d'énergie. Java utilise près du double d'énergie, C# plus de trois fois, et Python plus de 75 fois, selon l'étude.

Source : Mohammed Ayar's blog

Et vous ?

Pensez-vous que l'analyse de Mohammed Ayar est pertinente ou pas, et pourquoi ?

Selon vous, un programme plus rapide est-il, de par sa conception, économe en énergie ?

Rust deviendra-t-il le principal concurrent du langage C et du C++ dans le domaine des "langages de programmation plus écologiques" ?

Voir aussi :

Rust peut-il sauver la planète ? Un composant JavaScript a été réécrit en Rust et aurait une amélioration de 50 % de la latence, une réduction de 75 % de l'utilisation du CPU et 95 % de la mémoire

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

[earhater]

Lorsqu’un téléphone surchauffe, c'est parce que vous utilisez une certaine application. La chaleur excessive, à son tour, vide votre batterie, ce qui vous oblige à charger votre téléphone. Plus vous chargez votre téléphone, plus il consomme d'énergie. De même, moins vous chargez votre téléphone, mieux c'est - pour votre batterie et pour l'environnement.

Quand on sait que 90% du bilan carbonne d'un smartphone se situe dans sa fabrication, transport et recyclage (ou déchetterie) on peut quand même se dire qu'améliorer le bilan CO2 de l'utilisation d'un smartphone reste une optimisation à la marge. Je préfère un smartphone que je dois recharger 3 fois par jours (ignorons l'inconfort de la chose) mais durable (ex fairphone) qu'un smartphone à la mode Chinoise (huawei, xiaomi, ...) qui n'ont aucun support de l'OS après 2 ans et sont trop difficile à réparer (c'est vraiment des produits de conso) si on s'en tient à l'impact environmental.

C'est dommage de faire la majorité de l'article là dessus (de la part des chercheurs) car cela me semble contre productif alors qu'il y a de réel gains à ne pas utiliser python pour d'autres cas d'usage, je pense notemment aux API : faire du backend en python va requérir plus d'instances en cas de volumétrie par rapport à des langages compilés bad niveau (rust, go, c, ...) et là le gain est plus important.

[Fagus]

Pensez-vous que l'analyse de Mohammed Ayar est pertinente ou pas, et pourquoi ?

Bof. 90% de l'énergie consommée par les appareils informatiques vient de leur fabrication (extraction de minerais, etc.).
Réduire de 10% le renouvellement du parc ça a quasi 2x plus d'impact que de réduire de 50% la consommation d'électricité du parc (d'autant que ce dernier objectif ne serait pas atteint juste en remplaçant tout le python par du c)

Python c'est de la colle. Si son code python consomme trop de CPU, peut être qu'il est temps de déléguer à un module compilé ou d'écrire ce dernier.

[yahiko]

Programmer en Python apparaît donc comme étant peu responsable ce qui ne m'étonne qu'à moitié au vue de ses performances intrinsèques sommes toutes très médiocres.
Pour rester dans la famille des langages interprétés avec une courbe d'apprentissage abordable, je note que JavaScript / TypeScript est sans doute la meilleure alternative au langage reptile.

[Pyramidev]

En France, trouver un poste en Rust, c'est quasiment mission impossible.

De ce que j'ai vu pendant des entretiens d'embauche l'an dernier, dans les entreprises où le backend est fait en Python, quand les développeurs décident de migrer un morceau pour améliorer les performances, on dirait que c'est le langage Go qui est le plus souvent choisi.

[GATEN]

Python est un genre de serpents de la famille des Pythonidae.

[HaryRoseAndMac]

Programmer en Python apparaît donc comme étant peu responsable ce qui ne m'étonne qu'à moitié au vue de ses performances intrinsèques sommes toutes très médiocres.
Pour rester dans la famille des langages interprétés avec une courbe d'apprentissage abordable, je note que JavaScript / TypeScript est sans doute la meilleure alternative au langage reptile.

mouais,
franchement je trouve que prétendre que python détruit la planète pour des raisons de performance, est à la limite du risible.
Sans parler du fait que derrière, tout est optimisé en serveur, via des caches, du servless, et j'en passe, une fois en production.

Pour le reste, sur la prétendue consommation électrique du langage, il y a surtout une question de compétence du développeur, ne serais-ce qu'en notation Big O, architecturage et j'en passe.

Quand je vois en 2022 des gens qui continues de foutre des commentaires dans leur code ou mettre des paramètres à une fonction avec des retours à la ligne et donc n'ont aucunes maitrises des bonnes pratiques, qui permettent justement de ne plus avoir à mettre de commentaire, ou de ne pas avoir plus de 3 paramètres, maximum dans une fonction, sauf cas exceptionnel, pour ne prendre que ça, je me dis qu'on est pas près de faire baisser la facture et le langage n'y changera rien.

Sans parler de la légion de développeurs version LIDL qui arrive sur le marché formé en six mois.

Dans tous les cas, j'en reviens au fait que ce que prétends l'article est digne d'un titre du gorafi

[Invité]

Python reste bien plus performant énergétiquement parlant qu'un fichier Excel bourré de macros et de formules circulaires, puisque c'est a cette catégorie d'utilisateurs que ce langage s'adresse.

Ajouté à cela, la plupart des bibliothèques du langage sont des bindings vers des briques codées en C/C++.

[Uther]

Comme expliqué, par d'autres, Python est censé être un langage de script qui n'est pas fait pour être utilisé directement pour de la performance brute. S'il est utilisé judicieusement dans son domaine, ça n'est pas un problème.

Malheureusement c'est devenu un langage généraliste très utilisé dans la data science et l'IA et souvent par des non-informaticiens pas toujours très au courant des problématiques de performance. Du coup c'est une vraie problématique sur laquelle il faut informer, d'autant que de nos jour où avec le Cloud c'est assez tentant de simplement augmenter la puissance de calcul pour compenser un manque de performances.

[smarties]

Avant d'accuser Python, il faudrait agir en amont :
- garder le plus longtemps ses ressources informatique et ne pas renouveler tant que ça ne tombe pas en panne (et on peut généralement réparer)
- mutualiser les ressources, tous les serveurs ne demandent pas 100% de puissance ou de RAM tout le temps !

Python est certes pas très rapide mais il est adossé à plusieurs bibliothèques natives aussi ! Donc quand le programme Python ne fait pas de calcul, il ne doit pas avoir une forte emprunte énergétique.
Dans le milieu scientifique, quelle est l'emprunte de Matlab et de Scilab ?

[archqt]

Il faut voir que nombre de sites sont faits en langage interprétés dont python (Djano, Flask...) et là effectivement il y a de grosses pertes vu que les serveurs s'adaptent en consommant plus de VM et donc d'électricité.

Il y a quelques années une société (Orange je crois) avant transformé la gestion d'envoi des SMS en passant du php au langage C. Résultat ils avaient augmentés l'envoi par 150. Facebook a aussi fait un transpileur php vers C++.

Il y a donc un soucis sur les langages interprétés pour faire de grosses applications ou du back-end. Python pour du script c'est bien, pour du code côté serveur c'est pas le plus économique.

[GLDavid]

Bonjour

Mouais, étude encore une fois qui montre que les langages scriptés ne sont pas supers en performance et donc consomment du CPU inutilement.
Mais, on le sait déjà... Alors, j'ai été programmeur Perl, je dois donc faire une excuse public d'avoir utilisé ce langage parce que j'ai trop pollué ?
Comme dit plus haut, des langages comme Perl ou Python sont de très bons compléments au Shell. Après, leurs librairies étant gigantesques, on peut piocher dedans pour faire des projets plus évolués. C'est là peut être que se trouve l'erreur car on ne regarde pas la performance.
Mais pour moi, l'étude est bidon et joue la 'hype' sur l'écologie pour dénoncer les performances des langages. Dénoncer est une chose, peut être trop fait, remédier ou optimiser en est une autre...

@++

[Zefling]

C'est quand même bizarre de mettre un comparatif de langages de 2017... 5 ans c'est une éternité.

Plus récent :
https://github.com/kostya/jit-benchm...rytrees-5-runs

[Uther]

C'est quand même bizarre de mettre un comparatif de langages de 2017... 5 ans c'est une éternité.

L'étude est remise a jour chaque année (ca a été posté sur ce sujet), mais les résultat ne varient pas des masses.

[Guesset]

Bonjour,

Il y a des arguments assez classiques de détournement. Cette technique, très utilisée par les hommes politiques, consiste à comparer à pire : "Quand on voit la consommation de xyz on se demande pourquoi s'intéresser à sss", "avant de s'intéresser à sss on ferait mieux de régler le cas de xyz". En général, on prend un pire cas difficile à résoudre et à la limite du domaine pour éviter les retours de manivelles par des experts. Cela présuppose un règlement purement séquentiel des difficultés et donc une hiérarchisation (instauration d'une relation d'ordre dirait un informaticien). D'une part, la hiérarchisation est impossible car nous sommes en multidimensionnel (coûts, domaines, impacts sociétaux etc.). D'autre part, même en informatique le multi-tâche existe, rien n'impose le séquentiel sinon le désir de repousser aux calendes grecques.

Il y a la relativisation, technique, proche, mais qui apparaît plus honnête : "quand on voit que l'empreinte environnementale de production, distribution et recyclage représente 90% on se dit que gagner sur le code est très marginal". Ce qui est gênant dans cette démarche d'élargissement est qu'elle reste restreinte. Supposons, c'est juste une illustration, que le code divise par 2 sa consommation, cela jouera aussi sur la durée de vie de la batterie donc sur les 90 % car, après le goût de la nouveauté (très peu écologique), c'est le coût de remplacement de la batterie qui incite le plus au renouvellement.

Il y a aussi un argument qui fait sourire à propos des langages interprétés : "Ils ne peuvent pas être si mauvais puisque leurs bibliothèques sont écrites en C ou C++". En résumé, ils sont bons là où ils ne sont pas

Nous sommes souvent attaché à un langage plus qu'aux autres pour des raisons objectives mais également subjectives (souvent historiques). C'est pourquoi, il me semble utile de maîtriser plusieurs langages et d'en connaître plus encore (les apprendre, les tester sans nécessairement faire des programmes ambitieux).

Comme je l'ai déjà écrit, oui je radote, les langages qui réussissent sont souvent des langages de formation initiale. C'est un peu dommage que les langages utilisés professionnellement n'aient pas été choisi pour leur adéquation mais pour la disponibilité des compétences économiques.

Pour ma part, j'évite les langages interprétés et intermédiaires (semi-compilés, machines virtuelles...) pour tout projet moyennement ambitieux.

Salutations