Python est sans doute l’un des langages de programmation les plus populaires et les plus utilisés dans le monde, notamment dans le domaine scientifique et dans la science des données. Mais, selon Nathan Murthy, ingénieur logiciel chez Tesla, sa conception limite son potentiel en tant que langage système fiable et performant, estimant qu’il s’agit d’une chose que beaucoup de développeurs ignorent. Dans un article, il partage tout ce qu’il déteste chez Python, qu’il invite à lire avec une attitude plus claire, plus rationnelle et impartiale.Selon Nathan Murthy, Python est considéré comme un langage de programmation omniprésent, mais il existe en son sein plusieurs choses qui font de lui un langage de programmation très problématique lorsqu’il s’agit de construire des systèmes distribués fiables et performants. Murthy estime que les problèmes de Python sont évidents pour à peu près tous les ingénieurs qui écrivent du code sérieux, critique pour la mission et de la qualité de production dans l'entreprise moderne. Il suggère de considérer cela avant d'utiliser exclusivement Python pour votre architecture orientée service.
« Mon intention n'est pas de jeter de l'ombre sur les développeurs Python et Python, mais plutôt de mettre en page toutes les considérations à peser avant d'utiliser exclusivement Python pour votre architecture orientée service », a-t-il déclaré. Voici ci-dessous un aperçu des quelques points qu’il aborde dans son billet.
Membres faiblement ou dynamiquement typés
Python est considéré comme un langage de programmation faiblement typé ou dynamiquement typé. Pour lui, la sécurité dactylographique est un élément indispensable pour construire des logiciels fiables dans les grands programmes. Il estime que tous les développeurs devraient se familiariser avec ces termes. Voici un exemple de ce qu’il dit :
| Code : | Sélectionner tout |
1 2 3 4 5 | def foo(x):
if is_valid(x):
return "hello world"
else:
return bar(x) |
Le deuxième problème flagrant est que le développeur n’a aucune idée de ce que bar(x) retourne. Est-ce qu'il renvoie un str comme le suggère la première condition ? Si ce n'est pas le cas, alors c’est une méthode qui dans certains cas renvoie une chaîne et d'autres, pas. Si bar(x) retourne un int, alors cela signifie que foo(x) pourrait retourner une chaîne ou un entier. D’après lui, les adeptes de Python appellent ça les types dynamiques et le considèrent comme une caractéristique important du langage, mais il estime que cela peut très vite devenir problématique dans les grandes bases de code.
À ce niveau, Murthy estime qu’au fur et à mesure que la complexité d'une base de code augmente, le coût d'interprétation des membres tapés dynamiquement par les développeurs peut se transformer en goulots d'étranglement énormes pour leur productivité, mais aussi ajouter des frais de maintenance inutiles. Pour Murthy, les humains doivent consacrer du temps soit à déduire manuellement les types, soit à écrire un code standard qui valide les types à chaque site d'appel critique. Il ajoute aussi un autre aspect de la chose.
Il estime qu’en Python, un bon nombre d'erreurs sont découvertes au moment de l'exécution, ce qui est un autre problème. Le fait de ne pas, en l'absence d'une couverture de test parfaite, pouvoir vérifier l'exactitude syntaxique du code de quelqu'un est un problème majeur. « C'est l'une des raisons pour lesquelles les compilateurs ont été inventés : un langage de programmation fortement typé effectuera toutes les vérifications de type nécessaires pour déceler les choses qui ne devraient jamais se produire au moment de l'exécution », a-t-il dit.
Murthy a expliqué que les compilateurs de contrôle de type offrent un niveau supplémentaire de sécurité et de défense à la fiabilité de votre code, et réduisent également le risque d'erreurs logicielles au moment du déploiement. « L'absence de sécurité de type en Python (un peu comme Ruby) devrait être une préoccupation pour quiconque écrit du code sérieux », a-t-il déclaré. Selon lui, pour améliorer le contrôle de type statique en Python, les développeurs ont créé des bibliothèques, mais qui ne sont pas souvent utilisées.
Cela serait dû au fait qu’elles n'appartiennent pas à la chaîne d'outils standard ou parce que leur utilisation nécessite souvent un effort significatif pour investir du temps dans la mise à jour du code existant en ajoutant des notes en standard si la sécurité du type est traitée comme une réflexion secondaire....
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par flapili
.