Tu as lu le commentaire original qui dit "Python, ça rame". Je réponds juste en disant que non ça rame pas.
Bien sur, faire du Python brut pour du calculatoire, ça rame. De même que si tu ecris un framework graphique type Qt ou Gtk en pur python, ça ramera aussi. Sauf que justement, Python vient avec tout un ensemble de bibliothèque prêtes à l'emploi, dont beaucoup ont déjà résolu le problème de la performance.
Prenons le monde scientifique où le problème est plus visible. En suivant le raisonnement du commentaire, on prend pas Python parce que ça rame, et on part par exemple sur du C++. Sauf que dans les faits, en Python, le langage et les bibliothèques existantes permettront très vite d'arriver à code une appli, et numpy est suffisamment rapide pour répondre à la demande.
Il est très probable qu'à vouloir coder un calcul scientifique en C++, l'auteur passera plus de temps d'une part à écrire son appli, d'autre part, à faire des calculs qui seront au final moins rapide que Python + numpy.
C'est pour ça que j'insiste sur ce point: le langage Python a des perf inférieurs aux langages compilés, il y a pas de toute là-dessus. Mais dans la vraie vie, les applis Python marchent plutôt bien et vite, parce que des frameworks existent pour accélérer de base les parties critiques de ton application. Et quand ils ne suffisent pas, tu peux te concentrer sur les 1% qui ont besoin de perf maximale plutôt que sur la totalité de ton appli. Et au final, tu as un meilleur résultat.
Donc le racourci, Python est lent donc les applis Python sont lentes, est un raccourci à deux balles !
[^] # Re: Déprimant
Posté par Philippe F (site web personnel) . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 9.
Merci pour ce petit cours.
Tu as lu le commentaire original qui dit "Python, ça rame". Je réponds juste en disant que non ça rame pas.
Bien sur, faire du Python brut pour du calculatoire, ça rame. De même que si tu ecris un framework graphique type Qt ou Gtk en pur python, ça ramera aussi. Sauf que justement, Python vient avec tout un ensemble de bibliothèque prêtes à l'emploi, dont beaucoup ont déjà résolu le problème de la performance.
Prenons le monde scientifique où le problème est plus visible. En suivant le raisonnement du commentaire, on prend pas Python parce que ça rame, et on part par exemple sur du C++. Sauf que dans les faits, en Python, le langage et les bibliothèques existantes permettront très vite d'arriver à code une appli, et numpy est suffisamment rapide pour répondre à la demande.
Il est très probable qu'à vouloir coder un calcul scientifique en C++, l'auteur passera plus de temps d'une part à écrire son appli, d'autre part, à faire des calculs qui seront au final moins rapide que Python + numpy.
C'est pour ça que j'insiste sur ce point: le langage Python a des perf inférieurs aux langages compilés, il y a pas de toute là-dessus. Mais dans la vraie vie, les applis Python marchent plutôt bien et vite, parce que des frameworks existent pour accélérer de base les parties critiques de ton application. Et quand ils ne suffisent pas, tu peux te concentrer sur les 1% qui ont besoin de perf maximale plutôt que sur la totalité de ton appli. Et au final, tu as un meilleur résultat.
Donc le racourci, Python est lent donc les applis Python sont lentes, est un raccourci à deux balles !