Mais j’avais déjà noté la levée de boucliers quand son langage favori n’est pas en tête,
Le problème n'est pas que notre langage "favori" soit en tête ou non (d'ailleurs en ce qui me concerne je n'ai pas de langage vraiment favori) mais que les résultats soient douteux et la méthodologie derrière aussi. Les bonnes pratiques de conception ou d'éco-conception ne peuvent pas se réduire à "tel langage est plus performant / plus économe" (je ne sais pas si les gens se rappellent d'une ancienne version de Gnome où Nautilus mettait je crois environ 70 secondes pour afficher /usr/bin, bien qu'étant codé en C...).
Dans mon cas, il est possible que mon code Python/numpy/Geopandas soit plus performant que la même chose écrite en C (car en l'absence de "pénalité" sur les boucles je n'aurais peut-être pas naturellement vectorisé mon code de la même manière, or le fait de vectoriser permet de mieux utiliser le SIMD et le cache du CPU).
[^] # Re: Je ne suis pas sûr que les logiciels libres soient moins consommateurs de ressources CPU/Mém
Posté par karteum59 (site web personnel) . En réponse au journal Cailloux, joujoux, bijoux. Évalué à 2. Dernière modification le 29 septembre 2023 à 18:57.
Le problème n'est pas que notre langage "favori" soit en tête ou non (d'ailleurs en ce qui me concerne je n'ai pas de langage vraiment favori) mais que les résultats soient douteux et la méthodologie derrière aussi. Les bonnes pratiques de conception ou d'éco-conception ne peuvent pas se réduire à "tel langage est plus performant / plus économe" (je ne sais pas si les gens se rappellent d'une ancienne version de Gnome où Nautilus mettait je crois environ 70 secondes pour afficher /usr/bin, bien qu'étant codé en C...).
Dans mon cas, il est possible que mon code Python/numpy/Geopandas soit plus performant que la même chose écrite en C (car en l'absence de "pénalité" sur les boucles je n'aurais peut-être pas naturellement vectorisé mon code de la même manière, or le fait de vectoriser permet de mieux utiliser le SIMD et le cache du CPU).