Python, un langage plaisant mais inefficace pour la plupart des projets professionnels

Python, un langage plaisant mais inefficace pour la plupart des projets professionnels,
selon Jos Visser, ingénieur principal chez Amazon

Jos Visser, ingénieur principal chez Amazon, critique le choix de Python comme langage de programmation pour les développeurs débutants. Il affirme que Python est un langage interprété, dynamique et qui ne garantit pas la sécurité du type ni la fiabilité du code. Il raconte ses expériences négatives avec de grandes applications Python, qui ont généré des erreurs et des exceptions imprévisibles. Visser soutient que Python est inadapté à la plupart des usages professionnels et qu’il faut lui préférer des langages compilés et sûrs du point de vue du type, comme Rust. Il donne l’exemple d’une réécriture réussie d’un système en Rust, qui a amélioré la performance et la stabilité de l’application.

Jos Visser, ingénieur principal chez Amazon, exprime son opinion négative sur Python, un langage de programmation très populaire. Il explique pourquoi il pense que Python est inutile pour la plupart des usages professionnels et qu’il faut lui préférer des langages plus adaptés. Il commence par réagir à un post LinkedIn qui conseillait aux développeurs débutants d’apprendre Python pour trouver un emploi. Il reconnaît que Python est un langage très demandé, mais il affirme que c’est un problème qui freine le progrès de l’industrie informatique. Il se base sur son expérience personnelle avec de grandes applications écrites en Python, qu’il compare à des réacteurs nucléaires construits avec des briques Lego. Il décrit les difficultés et les risques liés à la maintenance et à l’évolution de ces applications, qui sont souvent instables et imprévisibles.

Pièce jointe 642199

Il identifie le problème principal de Python comme étant son caractère interprété, dynamique et en canard. Il explique que cela signifie que le code Python n’est pas vérifié avant l’exécution et qu’il peut produire des erreurs ou des exceptions selon les données qu’il reçoit. Il souligne que cela impose aux développeurs d’avoir une discipline rigoureuse pour contrôler toutes les données d’entrée, ce qui est rarement le cas dans la pratique. Il critique également le typage en canard de Python, qui permet d’écrire du code intelligent mais inutile, qui se retourne contre les développeurs.

Il raconte ses expériences négatives avec de grosses applications Python, qui ont généré des erreurs et des exceptions imprévisibles. Il donne l’exemple d’une application qui lançait du code qui n’avait jamais été testé ni exécuté auparavant. Il dit qu’il a réussi à convaincre son organisation de réécrire son système en Rust, un langage compilé et sûr du point de vue du type, qui a amélioré la performance et la stabilité de l’application.

Il conclut en réfutant l’argument selon lequel le problème ne vient pas de Python, mais de la stratégie de révision et de test du code. Il affirme que c’est une illusion de penser qu’il est possible d’examiner et de tester toutes les possibilités du code Python. Il défend la valeur d’un bon langage de programmation, qui garantit qu’un grand nombre d’erreurs ne peuvent pas se produire. Il suggère donc aux développeurs débutants de choisir un langage plus fiable et performant que Python pour leurs projets professionnels.

Les forces et les faiblesses de Python et de Rust pour la programmation système et l’apprentissage automatique

Python est un langage de programmation puissant qui offre de nombreux avantages, mais il faut aussi considérer plusieurs aspects quand on le compare à Rust pour la programmation système. Python est le langage préféré de beaucoup de développeurs, car il dispose d’un large éventail de bibliothèques, d’outils et de frameworks. Le langage conçu par Guido van Rossum a un écosystème riche, avec des bibliothèques performantes (comme NumPy, Pandas, scikit-learn) et des frameworks de ML éprouvés (comme TensorFlow, PyTorch) qui le rendent très productif pour le développement de modèles d’apprentissage automatique.

Python est aussi un langage lisible et facile à utiliser, qui permet de prototyper, d’expérimenter et d’itérer rapidement, ce qui est essentiel dans les premières phases du développement. La communauté Python fournit de nombreuses ressources, tutoriels et forums dédiés à l’apprentissage automatique, ce qui facilite la résolution de problèmes courants et la collaboration avec d’autres praticiens.

Par contre, Rust a des contrôles stricts à la compilation et des caractéristiques de sécurité de la mémoire qui le protègent des erreurs de programmation fréquentes comme les pointeurs nuls, les débordements de mémoire tampon et les courses de données. Ce niveau de sécurité peut être crucial lors du déploiement des projets professionnels en production, en assurant la stabilité et en réduisant le risque d’erreurs d’exécution ou de plantages. Rust est aussi interopérable avec C et Python, ce qui permet une intégration facile avec les bases de code Python existantes.

En conclusion, Rust a des avantages indéniables en termes de performance, de sécurité et de concurrence, mais Python a un écosystème étendu, une facilité d’utilisation, une vaste gamme d’outils et le soutien de la communauté qui en font un choix solide pour construire et déployer des projets professionnels.

Sources : Jos Visser's blog post, Karun Thankachan's blog post

Et vous ?

:fleche: L'analyse de Jos Visser est-elle pertinente ?

:fleche: Comment Jos Visser explique-t-il la popularité continue de Python malgré ses supposés défauts ?

:fleche: Quels sont les avantages et les inconvénients de Python par rapport à des langages compilés et sûrs du point de vue du type, comme C++, Java ou Go ?

Voir aussi :

:fleche: 99% des principaux paquets Python sont maintenant des wheels, ce qui rendra plus rapide l'installation pour les paquets purement Python

:fleche: Microsoft vient d'annoncer les améliorations Juillet 2023 de l'extension Python pour Visual Studio Code

:fleche: Python 3.12.0b1, la première des quatre versions bêta de la 3.12, a été publiée et apporte de nouvelles fonctionnalités ainsi que des corrections de bogues

Salut,

Techniquement, il est difficile de comparer Rust à C++ mais pas à Python car on n'écrira pas les mêmes applications avec. Et je trouve le bonhomme un peu de mauvaise foi car beaucoup d'efforts ont été fait côté typage et analyse statique de code permettant à Python d'être utilisable dans des projets industriels.
Ceci dit pour les applications à mission critique, on préfèrera des langages encore plus robustes que Rust.

Maintenant il est clair que l'industrie informatique privilégie en général les coûts.
De ce fait, tout programmer avec un seul langage est un atout (pour moins bien payer les programmeurs puisqu'on en trouvera plein...)
Ses critiques contre un langage de programmation dominant ne sont pas nouvelles... A d'autres époques, on a connu java, php, basic... difficile de trouver du boulot sans les connaître.

Mais on adresse alors plutôt la myopie de nombre de décideurs car techniquement on ne va jamais utiliser le même langage pour tout.

- W

Citation:

---

Envoyé par wiztricks

Techniquement, il est difficile de comparer Rust à C++ mais pas à Python car on n'écrira pas les mêmes applications avec.

---

Des fois, si. Au fur et à mesure que l'écosystème de Rust progresse, il y a de plus en plus de code Python pour lequel Rust devient une alternative crédible.

Par exemple, Python est utilisé dans plusieurs entreprises pour du développement web backend, par exemple avec Django et FastAPI. Rust a aussi des crates qui ont le même rôle que FastAPI, les plus populaires étant axum et Actix Web. Pour les interactions avec les bases de données, il y a aussi des crates dédiés.

À part ça, dans le tooling et les packages Python, Rust progresse. Par exemple, Pydantic V1 était écrit en pur Python et compilé avec Cython, tandis que Pydantic V2 contient du Rust dans son implémentation (via pydantic-core) pour augmenter les performances.

Citation:

---

Envoyé par wiztricks

Et je trouve le bonhomme un peu de mauvaise foi car beaucoup d'efforts ont été fait côté typage et analyse statique de code permettant à Python d'être utilisable dans des projets industriels.

---

Effectivement, tel que Jos Visser a formulé son article, il ne semble pas au courant de l'existence du typage statique optionnel en Python, qui existe pourtant depuis longtemps.

En pratique, les développeurs Python, utilisent-ils les annotations de type quand il est pertinent de les utiliser ? Des fois oui, des fois non. Cela dépend qui code. J'ai vu les deux cas.

C'est l'éternel débat langage compilé/interprété.
Mais à mon avis, on en revient aux tests. Le code défaillant est du code non suffisamment testé.
Et le manque de compétence du programmeur, que le langage ne peut pas résoudre.

Si on regarde les choses posément, quelle est la part des problèmes de typage dans les programmes défaillants ? D'expérience, j'ai pas l'impression que c'est le souci principal.
Les langages compilés ne sont pas à l'abri d'autres problèmes, comme les erreurs de logique. Un langage compilé ne garantit pas la rigueur.

On pourrait certes argumenter que les langages comme PHP, Python etc sont abordables pour les débutants, et donc il est courant de trouver du code de mauvaise qualité, ce qui explique le mauvais retour d'expérience dans le cas présent.

Citation:

---

Envoyé par Pyramidev

Effectivement, tel que Jos Visser a formulé son article, il ne semble pas au courant de l'existence du typage statique optionnel en Python, qui existe pourtant depuis longtemps.

---

Si on parle du type hinting, des annotations, il me semble que ça ne change pas le fait que Python reste dynamiquement typé et alors ce n'est pas du vrai typage statique au sens où ça existe dans d'autres langages. Mais on peut quand même utiliser des outils comme MyPy pour tester la cohérence du code. Et un bon IDE devrait déjà attirer l'attention sur certains problèmes.

Pour ce qui est des fuites mémoire, on peut utiliser un outil comme Valgrind. Idéalement, toutes ces batteries de tests devraient être mises en place dans une chaîne CI/CD, ce qui prend du temps.

La très grande majorité des gens qui ventent Rest comme des fanboys n'ont jamais rien fait de sérieux avec ce langage.

Arrêtez de croire que déjà, ces performances sont au dessus du C ou du C++, car c'est littéralement faux.
Et arrêtez de croire que c'est mieux de coder en Rust qu'en python, car là aussi, c'est faux.

Ce qui intéresse c'est un langage ou il est rapide d'écrire avec et ou ce qui est produit est performant.
Vous pouvez bien prétendre ce que vous voulez, du python pour faire des applications dans le domaine des mathématiques (Machine Learning, ...) ça reste ce qu'il y a de mieux et de loin devant tout le reste.

Salut,

Citation:

---

Envoyé par Pyramidev

Des fois, si. Au fur et à mesure que l'écosystème de Rust progresse, il y a de plus en plus de code Python pour lequel Rust devient une alternative crédible.

---

Tant mieux si ça crée une compétition qui fait progresser...

Citation:

---

Envoyé par Pyramidev

En pratique, les développeurs Python, utilisent-ils les annotations de type quand il est pertinent de les utiliser ? Des fois oui, des fois non. Cela dépend qui code. J'ai vu les deux cas.

---

Pour moi, python restera un langage de scripting à utiliser avec discernement(*). Et je ne vois pas trop l'intérêt des annotations pour ce que j'attends de Python. J'en comprends l'intérêt pour la gestion/contrôle d'un travail d'équipe et le développement plus fiable de gros projets.
Dans la pratique, ce ne sont que des outils de gestion du risque, une assurance qualité... et ça ne fait pas tout (et de loin).

(*)Je parle là des programmeurs professionnels pas d'étudiants à qui on apprend à programmer pour l'intérêt du cheminement programmatique ou les rassurer dans l'utilisation de cet outil dans différents aspects d'un boulot technique.
Que des décideurs embauchent ce genre de profils pour écrire de vrais programmes pas cher (et assez pourris) n'est pas un sujet technique.

- W

au-delà de la polémique facile («ce langage général n'est pas adapté aux cas particuliers»), ne s'agit-il pas de faire la promotion de rust* ?

--
* en vogue : le noyau Linux l'intègre, et pourrait, à terme, être totalement réécrit dans ce langage.
?

Phrase d'accroche :

Citation:

---

Python, un langage plaisant mais inefficace pour la plupart des projets professionnels,
selon Jos Visser, ingénieur principal chez Amazon

---

vs Conclusion :

Citation:

---

En conclusion, Rust a des avantages indéniables en termes de performance, de sécurité et de concurrence, mais Python a un écosystème étendu, une facilité d’utilisation, une vaste gamme d’outils et le soutien de la communauté qui en font un choix solide pour construire et déployer des projets professionnels.

---

La divergence de la conclusion par rapport à l'énoncé de départ me dérange :aie:.

Comparer des langage si différent, ça me fait toujours sourire.
Mais pour rappelle :

1. Python = langage interprété, fortement & dynamique typé (inférence de type à la 1er affectation et pour sa durée de vie).
   Honnêtement, c'est un langage plutôt simple, à la syntaxe constante mais si je devais faire de la performance , j'oublierais l'idée sauf à ce qu'un module coder en natif existe pour ma plateforme cible.
   
2. Rust = langage compilé (AoT), fortement & statiquement typé, avec contrôle des accès mémoire par propriété (pour empêcher/limiter les datas race) et de durée de vie (pour empêcher les débordements/fuite mémoire) à la compilation.
   Avec Rust, le dilemme est plus complexe étant donner qu'il peut ce permettre un panel d'utilisations que les autres langages, compilé nativement, ont rarement avec toutes ses qualités.
   Dans ses possibilité d'abstraction il serait au niveau du Java/C#, mais avec les capacités du C/C++ accoler.
   
3. C, C++ = langage compilé (AoT), faiblement & statiquement typé (proche de la machine quoi).
   Sauf à faire du bas niveau en voulant s'épargner un max d'assembleur pour un minimum de portabilité, je le conseillerais à personne en 2023 au vu des alternatives (manque juste de maturité pour les alternatives, mais elles ont le mérite d'existées).

Si je devais faire un site simple, j'utiliserais PHP (loin d'être le langage le plus élégant/cohérant de l'histoire), mais je pourrais tout à fait le coder en C/C++ pour faire un "cgi".
Le problème est de savoir si c'est pertinent dans mon cas.
En effet qui va payer pour le temp que ça va me prendre pour avoir au final le même résultat, sachant que 99% d'internet n'est pas les GAFAM est n'a pas leurs problématiques de perf, conso, gestion des ressources ?
Et puis si demain je change de poste, bonne chance pour debugger/augmenter des "cgi" en C/C++ bien touffu :aie:.

Conclusion, s'il existe autant de langages, c'est bien qu'il existe autant de besoins différents à combler. :roll:

Citation:

---

Envoyé par N_BaH

au-delà de la polémique facile («ce langage général n'est pas adapté aux cas particuliers»), ne s'agit-il pas de faire la promotion de rust* ?

---

Python n'est pas adapté à tout. C'est une réalité technique.

Après on a une réalité économique qui va de trouver des programmeurs qui pourront coder avec le langage X ou Y à combien ils vont coûter en passant par la qualité de ce qu'ils pourront produire.

--

Citation:

---

Envoyé par N_BaH

* en vogue : le noyau Linux l'intègre, et pourrait, à terme, être totalement réécrit dans ce langage?

---

On a le droit de rêver.... mais ré-écrire un code qui marche dans un autre langage parce qu'il est mieux n'a aucun intérêt: çà coute très cher et ça n'apporte pas grand chose côté nouvelles fonctionnalités. Une telle migration prendra des années et d'ici là, peut être que Rust aura été remplacé par un autre langage à la mode.
note: par contre voilà un exemple de ce qu'on ne peut pas coder avec Python.

- W

Pour le fait que Rust ne soit pas plus performant que le C++ ?

En tout cas il ne l’est pas moins.
J’ai porté un serveur de comptage que j’avais fait en C++ vers Rust et il avait des perfs du même ordre (plus rapide dans mon cas mais c’est difficile à évaluer sans de nombreux tests et sans doute de petites optimisations des deux côtés).
Et surtout je l’ai modifié pour qu’il soit multi-threads avec connexion par socket en souffrant un peu pour trouver comment faire, mais avec un résultat qui s’est révélé fiable pour la production dès le début.

Pour python, avec les bonnes bibliothèques c’est bien pratique pour mettre en place des chaînes de traitements, avec Pandas ou Polars par exemple on peut faire du traitement de données assez lourd.

Citation:

---

Envoyé par gzii69

Pour le fait que Rust ne soit pas plus performant que le C++ ?

En tout cas il ne l’est pas moins.

---

Ce sont deux langages compilés: in fine, on exécutera du code machine et on va surtout mesurer l'efficacité du compilateur à optimiser les instructions et le code machine généré. Au cas où on trouve des différences notables, on pourra toujours remplir une fiche d'anomalie et espérer des améliorations pour des cas de figure particulier.
Techniquement, il n'y a pas de raisons techniques autre que la maturité pour que le code généré soit plus rapide pour l'un que pour l'autre.
Par contre, Python étant généralement utilisé avec l'interpréteur CPython, la couche d'abstraction ajoutée par cet interpréteur fait qu'on en sera pénalisé (côté performance) ou limité quand à l'utilisation de ressources système (comme le nombre de CPUs utilisables avec les threads).

- W

Il n’y a pas que ça pour moi :
- Comme en C, et même si c’est un peu plus abstrait, je sens les modèles mémoire derrière.
- Même si on ne place pas soi-même les malloc et les free, on sent bien comment ils sont placés. Et ce qui est vérifié au niveau du compilateur, ce sont des vérifications qui ne se font pas à l’exécution, donc le code compilé reste léger.

Je ne comprends pas les propos de ce monsieur,
Le terme "projets professionnels" est beaucoup trop vaste, il faudrait d'abord définir le type de projet
Il sera difficile de faire avec Rust ce que l'on peu faire avec Django et Python
tout comme il sera difficile d'écrire un OS en python

Avec Python, tout comme Rust, de bons développeurs sont capable de produire un projet professionnel
et de mauvais dev feront de mauvais logiciel ... c'est valable pour n'importe quel langage :)

Par contre python permettra a plus de personnes de s'intéresser au développement, alors que Rust risque de rebuter certains même sur un "hello world"
une des forces de python est son accessibilité et sa lisibilité alors que Rust est plus robuste et sécure admettons ...

Rust aura de meilleur performance, un code plus sur c'est évident, mais encore faut il que les devs codent avec cohérence et bon sens, un mauvais code reste un mauvais code quelque soit le langage.

A mon avis Rust sera certainement beaucoup moins souple et agile que python avec son langage fortement typé ... mais dans la vie il faut savoir ce que l'on veut ;)

Je pense que cette personne aimerait n'avoir qu'un seul langage à gérer pour couvrir tout les cas de figures :) pour se simplifier la vie
ce qui est totalement illusoire et à mon avis contre productif

Il devrait licencier toute son équipe technique et n'utiliser que chatGPT , bard ou BedRock :) comme cela il verra la différence ...

Ce genre de personne me fait penser à certains octogénaire regroupés dans un petit pays avec un natalité nulle, qui ont fait vœux de chasteté, et qui se permette de donner des leçons aux monde entier sur la sexualité :)

Citation:

---

Envoyé par chris_FR

Avec Python, tout comme Rust, de bons développeurs sont capable de produire un projet professionnel
et de mauvais dev feront de mauvais logiciel ... c'est valable pour n'importe quel langage :)

---

Que le code soit mal foutu n'est pas si dramatique: tout dépend à quoi/qui il servira.

Le fait est que ce ne sont pas les "bons" développeurs qui imaginent des applications intéressantes mais les utilisateurs. S'ils ont la possibilité de bricoler un truc qui répond à un vrai besoin, on pourra toujours le ré-écrire si nécessaire quel que soit l'état du code initial.
Dans cette optique, qu'un langage assez facile comme Python qui se diffuse chez les non programmeurs et leur permette de mettre en forme leurs idées n'est pas idiot/inutile.

Ce qui est discutable, c'est de limiter la formation des programmeurs à un seul langage (et il n'y a pas que le langage à maîtriser) ou demander à des personnes qui se dépatouillent avec Python de réaliser des applications qui devront évoluer, être maintenues,...

- W

Bizarre de comparer des pommes et des oranges, une clio et une formule 1...
Si on veut la facilité (lisibilité) de Python qu'apprécier les débutants avec la sécurité de Rust (que même C ou C++ n'apportent pas et il ferait donc mieux de les comparer plutôt que Python...), alors je prendrais , en tant que débutant, Julia? Pas aussi sécurisé que Rust dont c'est le coeur et raison d'être mais suffisamment, et aussi rapide a l'exécution ou presque.

De toutes façons d'ici la fin de l'année les GitHub CoPilot/GPT5 et autre Google Bard vont certainement être capables de traduire tout langage en un autre et coder eux-mêmes en comprenant nos besoins , spécifications ou même codes (donc un Linux recodé de C à Rust, idem pour Windows depuis son C++, je ne vois pas pourquoi ce serait impossible..?)...

Quelqu'un saurait me répondre si un autre langage facile pour débutant est plus sûr que Python? Ruby? Dart? Smalltalk/Pharo? ES6 (JavaScript quoi...)? Elm?...

Citation:

---

Envoyé par nhugodot

Quelqu'un saurait me répondre si un autre langage facile pour débutant est plus sûr que Python? Ruby? Dart? Smalltalk/Pharo? ES6 (JavaScript quoi...)? Elm?...

---

Le problème du débutant ne vient pas du langage mais du fait qu'il est débutant. Il pourra utiliser un langage sûr et fabriquer un code tout aussi pourri...

Citation:

---

Envoyé par nhugodot

De toutes façons d'ici la fin de l'année les GitHub CoPilot/GPT5 et autre Google Bard vont certainement être capables de traduire tout langage en un autre et coder eux-mêmes en comprenant nos besoins

---

Quand je vois comment il traduisent l'anglais ou le français: c'est utilisable si on fait abstraction de petits détails qui choquent... Dommage que la programmation soit une affaire de détails (combien d'heures à passer après avant que ce soit fonctionnel).

- W

Citation:

---

Envoyé par nhugodot

Quelqu'un saurait me répondre si un autre langage facile pour débutant est plus sûr que Python? Ruby? Dart? Smalltalk/Pharo? ES6 (JavaScript quoi...)? Elm?...

---

Un langage pourquoi faire déjà ? Il faut commencer par le projet...
Si sûr ça veut dire memory safe et plus de détection automatique des erreurs, python avec le typage optionnel et l'analyse statique c'et bien déjà. Dart c'est un langage Google assez terne mais qui marche bien avec flutter par ex. Pharo c'est un langage pour l'industrie avec une philosophie très différente et qui vise la fiabilité et le débogage. Nim ça ressemble un peu à du python compilé typé et ça vise des binaires efficaces et sûrs avec moins d'efforts qu'en rust, par contre c'est marginal .

Je trouve Python super bien pour débuter, et je le conseille quand on me demande.
Mais aussi bien plus que ça.
Des chaînes de traitement mises en place rapidement comme je l’ai déjà dit, et même des maquettes. Je trouve ça bien plus rapide à mettre en place que du Rust pour ce genre d’utilisations. Tester des idées, des algos, mais aussi pour un traitement pas trop lourd qui ne tournera qu’une fois par mois avant d’être modifié dans disons deux ans.
Je ne suis peut-être pas assez bon en Rust pour que ça soit aussi rapide.

Ce n'est un secret pour personne qu'Internet tourne grâce à l'open-source qui est omniprésent, surtout dans les écosystèmes à base de Linux,
Bien évidemment, les grosses boîtes comme Amazon en profitent allégrement (même si elles contribuent aussi).
Bref, parmi les nombreux projets open-source existants, certains sont écrits en Python.
Moi-même je dois en utiliser sans savoir qu'il y a du Python derrière.

Peut-être que la vraie question c'est: que considère-t-on comme un projet professionnel. Les points de vue peuvent varier en fonction du cas d'utilisation.
Mais il y a sûrement un paradoxe: s'il y a une demande relativement forte pour un langage, fut-il méprisé comme PHP ou Python, c'est à se demander si les employeurs qui sont derrière cette demande font du développement professionnel :cfou:

Citation:

---

Envoyé par binarygirl

Mais il y a sûrement un paradoxe: s'il y a une demande relativement forte pour un langage, fut-il méprisé comme PHP ou Python, c'est à se demander si les employeurs qui sont derrière cette demande font du développement professionnel :cfou:

---

C'est aussi un problème de marché. On peut avoir des artisans de la programmation répondant aux besoins spécifiques de petites boites qui passent complétement sous les radars des SSII (ça ne les intéresse pas car ce sont de petits projets très risqués). Et on se retrouve avec des applications en production testées par la bonne volonté des utilisateurs (ça sera pas des tests d'intégration continues ni des plan de tests et pour la revue de code, il n'y a personne) et qui seront pérenne tant que l'artisan qui les a réalisé ne mette pas la clé sous la porte et/ou parte à la retraite.

Est ce que c'est un problème? Il y a toujours eu 2 grandes écoles pour la gestion d'un système d'information: on sous traite tout à des IBM ou des microsoft (c'est cher) ou on a des gens très compétents qui font ou encadrent le gros du boulot en interne ou étant très proches. C'est moins cher et plus agile, le risque est dans la gestion de ces compétences dans la durée et les frictions qu'ils pourront avoir avec les directions métiers.

Ce qui est sûr, c'est qu'aussi bien pour les langages que pour les compétences, il faut rechercher un équilibre... et le problème est multifactoriel: ce qui va marcher pour l'un sera catastrophique pour d'autres.

- W

Citation:

---

Envoyé par binarygirl

C'est l'éternel débat langage compilé/interprété.
Mais à mon avis, on en revient aux tests. Le code défaillant est du code non suffisamment testé.
Et le manque de compétence du programmeur, que le langage ne peut pas résoudre.

Si on regarde les choses posément, quelle est la part des problèmes de typage dans les programmes défaillants ? D'expérience, j'ai pas l'impression que c'est le souci principal.
Les langages compilés ne sont pas à l'abri d'autres problèmes, comme les erreurs de logique. Un langage compilé ne garantit pas la rigueur.

---

Si un développeur a beaucoup de lacunes dans les fondamentaux et qu'on lui demande de coder un programme complexe avec un langage compilé et statiquement typé habituel, alors le code n'aura pas de tests automatisés, il y aura des copiés-collés dans tous les sens et, malgré le typage, les entrées et sorties des opérations ne seront pas claires, car il y aura des variables globales muables (ou d'autres patterns similaires) dans tous les sens. Il y aura aussi plusieurs centaines d'avertissements du compilateur, tous ignorés. Bon, par contre, les paramètres des fonctions seront typés, donc il y aura quand même quelques indices qui traîneront dans tout ce bazar pour la future victime qui reprendra le code plus tard.

Si tu prends le même genre de développeur et que tu lui donnes un langage dynamiquement typé, il te pondras un code qui atteindra des niveaux de catastrophe qu'on ne connaît pas dans le monde des langages statiquement typés. Non seulement il y a encore plus de bogues car il n'y a toujours pas de tests automatisés et car le compilateur ne rattrape plus les erreurs les plus grotesques, mais ce n'est pas tout : quand on lit une fonction quelconque dans le code, on ne sait pas ce qu'elle prend en entrée, on ne sait pas ce qu'elle retourne en sortie et on ne sait même pas toujours quel code est appelé à l'intérieur : objet.methode_dont_le_nom_existe_dans_plein_de_classes(lol). Mais je ne sais pas à quelle(s) classe(s) cet objet peut appartenir !

Les deux exemples précédents, je les ai vus en entreprise.

Avec un mauvais développeur, le code sera mauvais quel que soit le langage. Mais, plus le langage lui permettra d'aller loin dans le mauvais code dès le début de l'apprentissage du langage, plus il ira loin dans l'immaintenabilité. :aie:

Citation:

---

Envoyé par defZero

C, C++ = langage compilé (AoT), faiblement & statiquement typé (proche de la machine quoi).

---

C++, ce n'est pas le même langage que C. Concernant le typage, on n'est pas du tout au même niveau.

En C, dès qu'on veut faire un peu d'abstraction au runtime, on se retrouve avec des void* qu'il faut convertir de manière un peu sauvage. En outre, en langage C, tout pointeur est nullable, alors que C++ supporte des alternatives aux pointeurs comme les références et std::reference_wrapper.

Sur certains aspects, le C++ est même un peu plus fortement typé que Java. Par exemple, en Java, comme toute classe dérive de Object qui possède une méthode equals, on peut comparer tout objet avec n'importe quel autre objet, même quand ça n'a pas de sens. En C++, par contre, si on écrit objet1 == objet2 sans avoir surchargé l'opérateur == sur le ou les types correspondants, cela provoque une erreur de compilation.

Par contre, pour la gestion de la mémoire, il est vrai que C++ est périlleux si on le compare à Java et Rust.

Citation:

---

Envoyé par nhugodot

De toutes façons d'ici la fin de l'année les GitHub CoPilot/GPT5 et autre Google Bard vont certainement être capables de traduire tout langage en un autre et coder eux-mêmes en comprenant nos besoins , spécifications ou même codes (donc un Linux recodé de C à Rust, idem pour Windows depuis son C++, je ne vois pas pourquoi ce serait impossible..?)...

---

D'ici la fin de l'année ?! En plus, on est déjà en août ! Non, on n'en est pas à ce stade là. :mrgreen:

Bonjour

Citation:

---

Envoyé par Bruno

:fleche: L'analyse de Jos Visser est-elle pertinente ?

---

Pas vraiment. Parce que tout ce qu'il dit en réalité c'est que Python est un bien beau langage mais il a ses faiblesses et si ces faiblesses sont critiques vis à vis d'un projet X alors il ne faut pas l'utiliser. Ce qui est parfaitement vrai. Mais c'est vrai pour tout langage. Donc cette analyse qui dit en simplifié "un truc qui n'est pas adapté n'est pas adapté" est peut-être exacte mais n'apporte rien de vraiment pertinent.
De plus commencer son argumentation par "j'ai vu des codes pourris tourner sans avoir été testés" ben oui je veux bien mais est-ce la faute de Python ?

Citation:

---

Envoyé par Bruno

:fleche: Comment Jos Visser explique-t-il la popularité continue de Python malgré ses supposés défauts ?

---

Parce que Python a été pensé pour être assez central. Son crédo de base est "je ne peux pas tout faire très bien donc je fais tout au mieux et je vous laisse ensuite déléguer à d'autres outils plus adéquats les trucs plus spécifiques". C'est un peu comme demander "pourquoi le béton est-il si apprécié dans la construction alors qu'il est moche?" réponse : parce que le béton n'est que le support solide et la beauté est faite avec d'autres matériaux.

Citation:

---

Envoyé par Bruno

:fleche: Quels sont les avantages et les inconvénients de Python par rapport à des langages compilés et sûrs du point de vue du type, comme C++, Java ou Go ?

---

Avantage: il n'a pas été conçu pour les mêmes buts
Inconvénient: il n'a pas été conçu pour les mêmes buts
C'est comme demander "quels sont les avantages et inconvénients de l'avion par rapport à l'hélicoptère"...

Donc voilà, un bien beau discours mais qui ne fait en réalité que brasser du vent :?

Citation:

---

Envoyé par binarygirl

Mais à mon avis, on en revient aux tests. Le code défaillant est du code non suffisamment testé.
Et le manque de compétence du programmeur, que le langage ne peut pas résoudre.

Si on regarde les choses posément, quelle est la part des problèmes de typage dans les programmes défaillants ? D'expérience, j'ai pas l'impression que c'est le souci principal.
Les langages compilés ne sont pas à l'abri d'autres problèmes, comme les erreurs de logique. Un langage compilé ne garantit pas la rigueur.

On pourrait certes argumenter que les langages comme PHP, Python etc sont abordables pour les débutants, et donc il est courant de trouver du code de mauvaise qualité, ce qui explique le mauvais retour d'expérience dans le cas présent.


Si on parle du type hinting, des annotations, il me semble que ça ne change pas le fait que Python reste dynamiquement typé et alors ce n'est pas du vrai typage statique au sens où ça existe dans d'autres langages. Mais on peut quand même utiliser des outils comme MyPy pour tester la cohérence du code. Et un bon IDE devrait déjà attirer l'attention sur certains problèmes.

Pour ce qui est des fuites mémoire, on peut utiliser un outil comme Valgrind. Idéalement, toutes ces batteries de tests devraient être mises en place dans une chaîne CI/CD, ce qui prend du temps.

---

+1 sur les tests.
pour pas mal bosser en Python, Go, C# en milieu professionnel, je vois passer bcp d erreurs de code en Python qui n apparaissent qu'au Runtime alors que VS aurait déjà évité certaines en C#/.NET.

La flexibilité de Python doit s accompagner de plus de tests qu un équivalent en C# ou Go, et c est souvent là que cela pèche: Python est choisi pour son côté "proto" mais trop de dev se refusent à écrire tout les unit tests nécessaires pour rendre le code "professionnel grade / production ready".


Indépendamment du langage, c est surtout la philosophie de plusieurs développeurs Python que je trouve assez désolant: trop de laisser aller et esprit "quick and dirty".
J'ai vu trop de fois j ai vu du code style

Code:

---

str(len(project["propA"]["subPropB"]))

---

sans pre-check, alors que c est pas bien compliqué d'écrire au dessus

Code:

---

if project and "propA" in project and "subPropB" in project["propA"]:

---

(En C# ou Go, l erreur serait la même, mais VS émet qques warning ici il me semble)

Citation:

---

Envoyé par Eric80

Code:

---

str(len(project["propA"]["subPropB"]))

---

sans pre-check, alors que c est pas bien compliqué d'écrire au dessus

Code:

---

if project and "propA" in project and "subPropB" in project["propA"]:

---

---

Pardon mais là je suis pas trop d'accord. Si j'écris traite dico["xxx"] c'est que je me sens à priori assez hardi dans le fait que quelque part plus haut j'ai écrit dico["xxx"]=valeur_à_traiter.
Et si je ne suis pas confiant dans mon Alzheimer, je peux toujours écrire traite dico.get("xxx", "valeur_sinon").

Parce que c'est bien joli d'écrire if project and "propA" in project and "subPropB" in project["propA"] style "je pense à tout" mais il faut alors vraiment penser à tout et donc aussi réfléchir à ce qui se passe dans le "else"...:aie:

ds mon exemple, il s'agit de lire des valeurs d un fichier json transformée en dictionnaire avec les noeuds json. (d un json.load). J aurais du le préciser pour éviter toute incompréhension.
Donc aucune garantie que les valeurs existent. Et si elles n existent pas, il faut simplement ignorer le noeud parent. D'où le if and in proposé.

Si python propose une façon simple et puissante de charger un json, je préfère ce que je fait généralement en C# avec une approche 100% objet et une flopée de classes générées, avec un deserialize<myRootNodeClass>(jsonString) comme décrit dans la doc MS. Alors oui c est bcp plus long et verbeux mais AMHA plus facile à débugger et tester.

Dans tout les cas, je trouve que c est un bon ex de la puissance de Python. Ma critique va d'abord aux développeurs qui n ont pas tjs conscience des effets de bords possible...

Citation:

---

Envoyé par Eric80

ds mon exemple, il s'agit de lire des valeurs d un fichier json transformée en dictionnaire avec les noeuds json. (d un json.load). J aurais du le préciser pour éviter toute incompréhension.
Donc aucune garantie que les valeurs existent. Et si elles n existent pas, il faut simplement ignorer le noeud parent. D'où le if and in proposé.

---

Dans ce cas, je conseille d'utiliser un package Python qui va valider le JSON et le transformer en objet plus fortement typé. Je pense que le plus connu est Pydantic (qui est utilisé par FastAPI). Aujourd'hui, je viens de tester un peu msgspec (qui est utilisé par Litestar), mais je n'ai pas encore vérifié si Mypy le gère bien.

Voici un script de démo que je viens d'écrire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78

#!/usr/bin/env python   PYTHON_VERSION = "3.11.4" DEPENDENCIES = ["msgspec==0.17.0"] VENV_DIR_NAME = ".venv"   def run(): from typing import Annotated   import msgspec from msgspec import Struct, Meta   PlayerName = Annotated[str, Meta(min_length=1, pattern="^[A-Z][a-z]*$")]   class Player(Struct, forbid_unknown_fields=True): name: PlayerName score: Annotated[int, Meta(ge=0, le=10)]   class Game(Struct, forbid_unknown_fields=True): players: Annotated[list[Player], Meta(min_length=1)] winner: PlayerName   game = msgspec.json.decode( b'{"players":[{"name":"Alan","score":2},{"name":"Bob","score":7}],"winner":"Bob"}', type=Game, ) print(game) print(game.players[0].name) try: msgspec.json.decode(b'{"players":[{"name":"Bob","score":7}]}', type=Game) except Exception as exc: print(f"Error when the winner is missing: {exc}") try: msgspec.json.decode(b'{"players":[],"winner":"Bob"}', type=Game) except Exception as exc: print(f"Error when the player list is empty: {exc}") try: msgspec.json.decode(b'{"players":[{"name":"Bob","score":"7"}],"winner":"Bob"}', type=Game) except Exception as exc: print(f"Error when the score is not an integer: {exc}")     def main(): import sys from pathlib import Path   if Path(sys.executable).parent.parent.name == VENV_DIR_NAME: run() else: create_venv_if_needed_and_run_script_from_it()     def create_venv_if_needed_and_run_script_from_it(): import shlex from pathlib import Path from subprocess import check_call, check_output   def print_and_execute(command): print("------ " + shlex.join(str(x) for x in command)) check_call(command)   venv_python = Path(VENV_DIR_NAME) / "bin/python" if not Path(VENV_DIR_NAME).is_dir(): pyenv_root = Path(check_output(("pyenv", "root")).decode("utf-8").strip()) pyenv_python_dir = pyenv_root / f"versions/{PYTHON_VERSION}" if not pyenv_python_dir.is_dir(): print_and_execute(("pyenv", "install", PYTHON_VERSION)) pyenv_python = pyenv_python_dir / "bin/python" print_and_execute((pyenv_python, "-m", "venv", VENV_DIR_NAME)) print_and_execute((venv_python, "-m", "pip", "install", "--upgrade", "pip")) for dependency in DEPENDENCIES: print_and_execute((venv_python, "-m", "pip", "install", dependency)) print("-"*80) check_call((venv_python, Path(__file__).resolve()))     if __name__ == "__main__": main()

---

Sortie :

Code:

---

1 2 3 4 5

Game(players=[Player(name='Alan', score=2), Player(name='Bob', score=7)], winner='Bob') Alan Error when the winner is missing: Object missing required field `winner` Error when the player list is empty: Expected `array` of length >= 1 - at `$.players` Error when the score is not an integer: Expected `int`, got `str` - at `$.players[0].score`

---

La partie qui concerne msgspec est dans ma fonction run. Le reste du script est un bricolage de ma part pour créer à la volée un environnement virtuel avec la version désirée de Python (elle-même installée à la volée via pyenv si besoin), avant de relancer le script depuis cet environnement virtuel.

Remarque : dans la doc de msgspec, il y a un exemple concret de parsing d'un pyproject.toml : https://jcristharif.com/msgspec/exam...ject-toml.html

À première vue, Mypy sait gérer msgspec.

Je viens d'apprendre à utiliser Scriptisto. Voici une nouvelle version améliorée du code qui tient aussi en un seul fichier et qui lance des linters avant l'exécution du code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

#!/usr/bin/env scriptisto   from typing import Annotated   import msgspec from msgspec import Meta, Struct   PlayerName = Annotated[str, Meta(min_length=1, pattern="^[A-Z][a-z]*$")]   class Player(Struct, forbid_unknown_fields=True): name: PlayerName score: Annotated[int, Meta(ge=0, le=10)]   class Game(Struct, forbid_unknown_fields=True): players: Annotated[list[Player], Meta(min_length=1)] winner: PlayerName   game = msgspec.json.decode( b'{"players":[{"name":"Alan","score":2},{"name":"Bob","score":7}],"winner":"Bob"}', type=Game, ) print(game) print(game.players[0].name) try: msgspec.json.decode(b'{"players":[{"name":"Bob","score":7}]}', type=Game) except Exception as exc: print(f"Error when the winner is missing: {exc}") try: msgspec.json.decode(b'{"players":[],"winner":"Bob"}', type=Game) except Exception as exc: print(f"Error when the player list is empty: {exc}") try: msgspec.json.decode( b'{"players":[{"name":"Bob","score":"7"}],"winner":"Bob"}', type=Game, ) except Exception as exc: print(f"Error when the score is not an integer: {exc}")   """ scriptisto-begin script_src: me.py build_once_cmd: python build_venv.py && chmod +x script build_cmd: ./venv/bin/mypy me.py && ./venv/bin/ruff check me.py files: - path: requirements.txt   content: |     msgspec==0.17.0     mypy==1.4.1     ruff==0.0.284 - path: build_venv.py   content: |     from pathlib import Path     from subprocess import check_call, check_output     python_version = "3.11.4"     pyenv_root = Path(check_output(("pyenv", "root")).decode("utf-8").strip())     pyenv_python_dir = pyenv_root / f"versions/{python_version}"     if not pyenv_python_dir.is_dir():         check_call(("pyenv", "install", python_version))     check_call((pyenv_python_dir / "bin/python", "-m", "venv", "venv"))     check_call(("venv/bin/python", "-m", "pip", "install", "--upgrade", "pip"))     check_call(("venv/bin/python", "-m", "pip", "install", "-r", "requirements.txt")) - path: script   content: |     #!/bin/sh     DIR="$(cd "$(dirname "$0")" && pwd)"     exec "$DIR/venv/bin/python" "$DIR/me.py" "$@" scriptisto-end """

---

Quand on lance Scriptisto sur ce fichier, cela fait les opérations suivantes :

• Initialiser un dossier de cache quelque part dans $HOME/.cache/scriptisto/bin et y exécuter build_venv.py :
  
  • Installer Python 3.11.4 avec pyenv s'il n'est pas déjà installé.
  • Créer l'environnement virtuel et y installer msgspec, Mypy et Ruff.
• Depuis cet environnement virtuel :
  
  • Vérifier le typage avec Mypy.
  • Si c'est OK, vérifier le code avec Ruff.
  • Si c'est OK, exécuter le script.

Après avoir édité le code, Scriptisto ne réexécutera pas build_venv.py, sauf si on détruit le cache associé au script, par exemple via la commande scriptisto cache clean ./nom_du_fichier.py.

Cela fait quand même beaucoup de tours de passe-passe juste pour faire tenir tout ça en un seul fichier…

Citation:

---

Envoyé par Eric80

Indépendamment du langage, c est surtout la philosophie de plusieurs développeurs Python que je trouve assez désolant: trop de laisser aller et esprit "quick and dirty".

---

Faut-il blâmer les développeurs ou ceux qui les emploient (et qui laissent faire)?
De toutes façons, il n'est pas facile de devenir "bon". On peut avoir une formation initiale raisonnable, mais si on n'a pas l'opportunité de bosser dans des équipes pour apprendre des plus anciens, difficile de s'améliorer seul dans son coin.
Tout l'intérêt de la qualité d'un développement est dans la compréhension d'un travail d'équipe. On écrit du code qui devra pouvoir être relu/maintenu par d'autres.
Et pour des applications critiques, on préférera faire faire le contrôle qualité par une autre entité que celle qui développe (on évite les conflits d'intérêt qui pourraient fermer les yeux sur certains défauts).

- W

Un truc basique qui manque en Python: les constantes. Tellement basique que je considère que c'est un vrai manquement.
Pouvoir protéger des variables n'est quand même pas un luxe. Même bash le permet.

Je déteste aussi la tabulation qui peut causer des erreurs de logique si on ne fait pas attention. Mais c'est ce qui arrive à ceux qui pondent du long code avec des if imbriqués, ce qui n'est pas un bon pattern dans l'absolu. D'ailleurs, je pense que ça m'a ouvert les yeux.
Depuis que je fais du Python, j'ai appris à rédiger des fonctions plus succinctes et mieux modulariser le code.

Citation:

---

Envoyé par binarygirl

Un truc basique qui manque en Python: les constantes. Tellement basique que je considère que c'est un vrai manquement.
Pouvoir protéger des variables n'est quand même pas un luxe. Même bash le permet.

---

Depuis Python 3.8, typing.Final permet de signaler à l'analyseur statique de type qu'une variable ne peut pas être réassignée. Si de plus la variable pointe vers un objet immuable, on a alors une constante.

Citation:

---

Envoyé par binarygirl

Un truc basique qui manque en Python: les constantes. Tellement basique que je considère que c'est un vrai manquement.
Pouvoir protéger des variables n'est quand même pas un luxe. Même bash le permet.

---

En dehors d'un aspect lié au langage en lui-même (pouvoir écrire var=123 puis plus tard var="autre chose" parce que les variables doivent pouvoir être réaffectées), il y a une notion philosophique. Est-ce que la notion de "variable invariable" a un sens? Si "var" ne doit pas changer de valeur "123", pourquoi alors utiliser "var" et ne pas utiliser directement "123" ? Pour des questions de lisibilité me répondras-tu (à mon avis). Effectivement c'est plus lisible d'utiliser une variable "avogadro" qu'une valeur "6.02214076e+23". Dans ce cas, le consensus c'est de la mettre en majuscules (comme les #define du C). Mais ça ne reste qu'un consensus (comme les "_" pour les attributs publics, nécessaire pour être connus des objets hérités, mais ne devant pas être utilisés depuis l'extérieur).

En bash (en fait ça date même du Bourne Shell originel de 1970) c'est pour une question de sécurité. Par exemple la variable "EUID" (Exec User Identifiant) sert à identifier l'utilisateur qui demande une action. Il est évidemment impensable (enfin si on tient à garder un système multi-utilisateurs intègre) d'autoriser n'importe qui à modifier cette valeur et à la mette par exemple à 0

Citation:

---

Envoyé par binarygirl

Je déteste aussi la tabulation qui peut causer des erreurs de logique si on ne fait pas attention.

---

Personnellement je ferme toujours mes blocs par un commentaire équivalent au mot clef qui a ouvert le bloc (sauf si le bloc ne contient qu'une ligne)

Code:

---

1 2 3 4 5 6

def toto(): for truc in machin: if chose: actionX # for # toto()

---

Mais effectivement moi aussi j'ai réduit mes imbrications. C'était peut-être le but voulu en définitive...

Citation:

---

Envoyé par Pyramidev

Depuis Python 3.8, typing.Final permet de signaler à l'analyseur statique de type qu'une variable ne peut pas être réassignée. Si de plus la variable pointe vers un objet immuable, on a alors une constante.

---

Oui, mais ça reste une déclaration d'intention au niveau du code, tout comme le typage qui reste dynamique même quand on assigne un type à la variable au départ, mais on peut quand même faire ce qu'on veut de cette variable.
L'interpréteur ne fait aucun "enforcement". Pour protéger des variables/objets on peut seulement s'appuyer sur les conventions de nommage (uppercase) et éventuellement des outils comme Flake et les tests unitaires.

Mais merci du rappel, je vais quand même m'habituer à utiliser typing.Final pour enfoncer le clou même si ça ne sert pas à grand-chose dans l'absolu... 8-)

Citation:

---

Envoyé par binarygirl

L'interpréteur ne fait aucun "enforcement". Pour protéger des variables/objets on peut seulement s'appuyer sur les conventions de nommage (uppercase) et éventuellement des outils comme Flake et les tests unitaires.

---

Le typing sera utilisé par un analyseur de code statique comme mypy.
C'est un outil qui permettra de vérifier qu'on n'écrase pas une variable déclarée typing.Final... Et plus généralement du respect du type des objets qui amenés à transiter via les différentes interfaces.
Comme je le disais plus haut, c'est le genre d'outil qui permet de réduire quelque peu la couverture fonctionnelle des tests et du nombre de boulettes qu'on ne pourrait découvrir qu'en production.

Si on veut fabriquer un logiciel de quelque importance, il faut faire travailler plein de monde et avoir des gardes fous pour assurer la qualité de ce qui sera produit. Le typing est un des outils qui peut faire passer Python de l'artisanat à une production plus industrielle (c'est pour ça que ça intéresse les grosses boites).

Ceci dit, un (gros) logiciel fabriqué en usine ne sera jamais parfait.

C'est pour ça qu'on va faire des alpha/beta tests en plus de toutes une batterie de tests automatiques.

Dans les faits, on arbitrera sa mise en production/sortie en fonction du nombre de bugs résiduels et de leur gravité/impact estimé côté utilisateurs. Parfois on se trompe (sur la gravité ou sur ce qui a été effectivement testé).

Et on se prend un tollé côté utilisateurs.

D'où les réticences de certains à se jeter dans une version .0 et préférer attendre une version .1 ou .2 et/ou de ne pas se jeter sur la dernière mouture disponible mais de patienter en .n-1 ou .n-2.

- W

"Python inefficace pour la plupart des projets pro", certains peut-être, mais apparemment pas la plupart. Par exemple dans le traitement data et calcul scientifique il est au top. Pour indice voir aussi l'index Tiobe, en 10 ans d'évolution... Je l'invente pas ça non plus ;)

"n'est pas vérifié avant l'exécution et qu'il peut produire des erreurs ou des exceptions selon les données qu'il reçoit"... J'utilise beaucoup de C++, et les erreurs à l'exécution existe aussi, croire que le typage va tout résoudre est un peu naïf.
"Il donne l'exemple d'une application qui lançait du code qui n'avait jamais été testé ni exécuté auparavant"... Et avec n'importe quel langage on obtiendra le même résultat, pas testé donc pas valide, le travail n'est clairement pas terminé, pareil pour ceux qui ne documente pas leur code et le fond faire par des prestataires (les tests aussi mais là c'est une hérésie mais c'est bien réel malheureusement).

Le peu que j'ai vu de rust ne m'a pas du tout convaincu d'y passer, pour moi il est encore plus que prématuré de s'y lancer professionnellement, à moins d'être kamikaze. Quand à python, cela reste un excellent langage, avec des défauts, et des qualités, et des domaines où il est mieux adapté qu'ailleurs. Et c'est comme tout, un excellent langage dans les mains des mauvaises personnes, produira toujours un résultat imprévisible. Imposer rust à une équipe qui ne le connais pas et je parie que le résultat ne sera pas merveilleux.

Et puis, on se focalise souvent sur le langage, mais à la base pour réussir une application, c'est avant tout un travail de réflection, conception, test, le langage n'est qu'un outils. Dans ma jeunesse on m'avait interdit d'utiliser du C++, j'ai conçu tout une bibliothèque avec des classes, héritage, polymorphisme en langage C, c'était certes bien plus lourd mais pas infaisable, dans ce cas le langage C++ m'aurait aider, mais au final cela ne m'a pas manqué, car j'ai pu concevoir ce que je voulais faire.

Citation:

---

Envoyé par defZero

Phrase d'accroche :

"Python, un langage plaisant mais inefficace pour la plupart des projets professionnels,
selon Jos Visser, ingénieur principal chez Amazon"

vs Conclusion :

"En conclusion, Rust a des avantages indéniables en termes de performance, de sécurité et de concurrence, mais Python a un écosystème étendu, une facilité d’utilisation, une vaste gamme d’outils et le soutien de la communauté qui en font un choix solide pour construire et déployer des projets professionnels."

La divergence de la conclusion par rapport à l'énoncé de départ me dérange :aie:.

---

C'est parce que c'est dérangeant.
l faut lire les articles originaux pour démêler cette traduction approximative.
L'auteur s'est basé sur deux articles différents ayant des points de vue opposés, donc forcément ça n'aide pas.

Citation:

---

Envoyé par popo

C'est parce que c'est dérangeant.

---

Yes, ça dérange parce que c'est dérangeant. Ca c'est de la conclusion profonde :mrgreen:

Citation:

---

Envoyé par popo

L'auteur s'est basé sur deux articles différents ayant des points de vue opposés, donc forcément ça n'aide pas.

---

Compris. C'est comme s'il avait dit qu'il n'aime pas l'avion parce qu'il avait lu un article sur la choucroute alsacienne et qu'on n'en sert pas dans les avions. Le fait que l'avion vole, permette d'aller loin rapidement n'entre absolument pas en ligne de compte...

Citation:

---

Envoyé par Sve@r

Yes, ça dérange parce que c'est dérangeant. Ca c'est de la conclusion profonde :mrgreen:

---

Dans mon commentaire "C'est" faisait référence à "La divergence de la conclusion par rapport à l'énoncé de départ".
Ce qui est, effectivement, dérangeant.

Citation:

---

Envoyé par Sve@r

Compris. C'est comme s'il avait dit qu'il n'aime pas l'avion parce qu'il avait lu un article sur la choucroute alsacienne et qu'on n'en sert pas dans les avions. Le fait que l'avion vole, permette d'aller loin rapidement n'entre absolument pas en ligne de compte...

---

Là aussi, tu n'a pas compris mes propos.
Alors tu les déformes et tu les tournes en ridicule.

Le post indique qu'il s'agit des propos négatifs de Jos Visser (ingénieur principal chez Amazon) à propos de python.
Le post se termine sur une contradiction totale par rapport à l'introduction sans préciser qu'elle est tirée d'un autre article (qui n'est pas celui de Jos Visser mais celui de Karun Thankachan).

Noter que mon objectif n'était pas d'émettre un avis sur Python (qui soit positif ou négatif).
Mon objectif était d'expliquer pourquoi on a cette divergence de la conclusion par rapport à l'énoncé de départ.

Citation:

---

Envoyé par popo

Là aussi, tu n'a pas compris mes propos.
Alors tu les déformes et tu les tournes en ridicule.

---

Pas les tiens, les siens !!! Ce sont les siens que tu as expliqué !!!
Tu me connais non, on a déjà parlé ensemble, je me suis jamais moqué de toi. Un peu d'humour oui sur "dérange/dérangeant" mais bon si ça te... dérange...

Citation:

---

Envoyé par popo

Le post indique qu'il s'agit des propos négatifs de Jos Visser (ingénieur principal chez Amazon) à propos de python.
Le post se termine sur une contradiction totale par rapport à l'introduction sans préciser qu'elle est tirée d'un autre article (qui n'est pas celui de Jos Visser mais celui de Karun Thankachan).

---

Exactement ce que je dis. Jos Visser a des propos négatifs sur les avions parce que Karun Thankachan encense la choucroute (ou tout autre plat typiquement délicieux que la consonnance de son nom laisse suggérer) et qu'on n'en sert pas dans les avions. Comme quoi

1. j'avais parfaitement compris tes propos
2. c'est toi qui n'a pas compris les miens