Un moment donné, est-ce qu'il n'est pas naturel de s'attendre à ce que la meilleure manière de faire une boucle FOR, c'est de faire une boucle FOR?
Non, quand tu as fait des maths, la manière la plus naturelle d'éviter une boucle FOR, c'est de vectoriser ton calcul. Sinon, tu fais du C pur.
Avec un langage interprété comme Python, quand tu sais comment c'est fait sous le capot, tu utilises le moins possible ton code comme un langage et le plus possible comme une interface avec des modules C ou Fortran optimisés qui vont effectivement se taper les calculs.
Dès que tu vises du code qui ne fait pas « juste marcher » mais marche vite, tu es bien obligé de rentrer dans les détails bas niveau, même si la programmation n'est pas ton métier. Utiliser des entiers 8 bits à la place de flottants 64 bits quand ça n'est pas nécessaire, arrêter de stocker 3 copies de la même matrice dans 3 variables différentes que tu ne réutiliseras plus, mettre en cache des fonctions, utiliser des compilateurs JIT, feeder tes itérations à un sous-module C au lieu de les recoder, etc.
Évidemment, ça n'est pas une raison pour ne jamais évoluer, et c'est vrai que des trucs comme Ada, Fortran, ou même C tendent à disparaitre peu à peu, mais ça n'est pas une raison pour refaire pour la 1000e fois le coup du "apprenez ce truc nouveau, ça vous fera gagner du temps". Au final, plus personne ne maitrise réellement chaque langage, ça diminue la qualité du code, et ça n'apporte pas grand chose.
[^] # Re: essayer Julia ?
Posté par aurelienpierre . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 6.
Non, quand tu as fait des maths, la manière la plus naturelle d'éviter une boucle FOR, c'est de vectoriser ton calcul. Sinon, tu fais du C pur.
Avec un langage interprété comme Python, quand tu sais comment c'est fait sous le capot, tu utilises le moins possible ton code comme un langage et le plus possible comme une interface avec des modules C ou Fortran optimisés qui vont effectivement se taper les calculs.
Dès que tu vises du code qui ne fait pas « juste marcher » mais marche vite, tu es bien obligé de rentrer dans les détails bas niveau, même si la programmation n'est pas ton métier. Utiliser des entiers 8 bits à la place de flottants 64 bits quand ça n'est pas nécessaire, arrêter de stocker 3 copies de la même matrice dans 3 variables différentes que tu ne réutiliseras plus, mettre en cache des fonctions, utiliser des compilateurs JIT, feeder tes itérations à un sous-module C au lieu de les recoder, etc.
C'est exactement ce que je dis.