Discussion :

[Bill Fassinou]

La conception de Python limite son potentiel en tant que langage système fiable et performant,
estime Nathan Murthy, ingénieur logiciel chez Tesla

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 - Visualiser dans une fenêtre à part

1
2
3
4
5
def foo(x):
   if is_valid(x):
       return "hello world"
   else:
       return bar(x)

Pour lui, ce petit bout de code est chargé de problèmes potentiels. Selon lui, si un programmeur visionne ce code pour la première fois, sa question immédiate sera : que fait foo() ?. S’il n’y a pas un test unitaire auquel il peut se référer, ce dernier ne saura pas donner un sens à ce code. Selon Murthy, il est pratiquement impossible d'analyser statiquement cet extrait sans regarder les définitions des fonctions is_valid() et bar(x), et ces méthodes peuvent avoir des références à d'autres méthodes, et ainsi de suite. Le premier problème flagrant est que le programmeur n’a aucune garantie que is_valid() renvoie un type bool.

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.

Le verrouillage de l'interprète global

Selon Murthy, les logiciels modernes sont multithread et multicore, et donc presque tous les langages de programmation modernes offrent des primitives de concomitance. Il estime que Python est livré avec un module de threading, mais en raison de la façon dont l'interpréteur Python est implémenté, il ne peut jamais exécuter qu'un seul thread à la fois. Ceci est dû au fameux Global Interpreter Lock (GIL). Les ordinateurs possédant aujourd’hui plusieurs processeurs, le GIL introduit un comportement litigieux entre les processeurs pour les tâches liées au CPU. Ainsi, il impose une contrainte aux programmes concurrents qui sont lourds en calcul.

Performance

D’après ce que dit Murthy, Python est relativement lent par rapport aux langages de programmation qui fonctionnent plus près du système d'exploitation. La concomitance multithread est une faiblesse de Python pour les tâches liées au CPU, de même que le traitement parallèle dans des tests similaires. La vitesse brute de Python lorsqu'il s'agit d'exécuter une variété de tâches de calcul ou de tâches liées aux E/S n'est pas stellaire comme le démontrent plusieurs benchmarks standards. Il a aussi déclaré que Python souffre également d'une surcharge d'invocation de fonction très élevée.

Selon lui, il existe des implémentations telles que PyPy qui sont fondamentalement plus rapides que l'implémentation de référence de CPython, mais qui n'offrent pas la même étendue de bibliothèques déjà supportées par l'écosystème CPython. « Les limites de performance de Python le rendent mal adapté aux systèmes de traitement en temps réel ou aux systèmes basés sur les flux qui déplacent ou manipulent de grands volumes de données sur plusieurs machines avec une faible latence, ce qui est pratiquement tautologique pour les ingénieurs construisant des systèmes distribués à grande vitesse », a-t-il déclaré.

Le Grand Schisme : Python2 vs Python3

Murthy suggère que si vous faites du développement sur Mac ou Ubuntu, vous avez probablement déjà installé Python 2.7. Si c’est le cas, il estime qu’il y a de fortes chances que lorsque vous avez commencé à programmer en Python, personne ne vous ait parlé de Python 3. Et donc, si vous parcouriez Python 2 sans vous en rendre compte, vous avez peut-être été surpris d'apprendre que certains programmes Python fonctionnent bien sur les machines de vos collègues, mais que sur votre machine, un tas d'erreurs de syntaxe apparaissent.

Ce qu’il appelle le schisme de Python serait apparu en 2008 avec la sortie de Python 3. Selon lui, beaucoup pensaient que ce serait l'avenir de Python, mais en réalité, ce n'était pas le cas. « Plusieurs projets ont été développés sous Python 2. J'ai moi-même travaillé sur une base de code pendant trois ans qui n'a fonctionné que sur Python 2.4. La migration vers Python 3 ou 2.7 était impossible à cause des bibliothèques spécifiques aux fournisseurs que nous utilisions », a-t-il déclaré, ajoutant que ces points douloureux ne sont pas uniques.

Il a déclaré qu’au fil du temps, la communauté des développeurs a créé des outils comme 2to3, 3to2, et six, qui étaient tous des gestes bien intentionnés pour apporter une amélioration à la compatibilité syntaxique entre les bibliothèques, mais n'étaient pas des solutions parfaites, car il y a toujours du code qui ne peut être converti. Ainsi, selon lui, Python a des limitations sur l'écriture de code propre en amont et en aval du code compatible. Ces limites ne sont pas anodines, surtout pour les équipes qui possèdent des logiciels essentiels à leur mission.

Encapsulation et conditionnement

Ici, Murthy avance que les abstractions de classes fuient en Python. « N'importe qui peut accéder au code de presque n'importe où », a-t-il déclaré. Les classes peuvent avoir des membres qui ne sont pas sûrs lorsqu'ils sont exécutés en dehors de leur définition de classe. Par convention, les membres avec un seul trait de soulignement en tête sont considérés comme “protégés”, et les membres avec un double trait de soulignement en tête sont considérés comme “privés”. Cependant, il dit que Python n'a pas de véritable modèle de confidentialité. Ainsi, au lieu de cela, l'interpréteur recourt à la manipulation pour protéger les espaces de noms lors de l'utilisation de l'héritage, mais permet toujours l'accès aux membres mutilés.

Système de construction désorganisé

Selon Murthy, construire un projet avec Python et importer des dépendances peut être compliqué. Si vous faites du développement logiciel sérieux en Python, c'est presque toujours compliqué. Pour donner des exemples de ce qu'il dit, il utilise la bibliothèque numpy, un module de programmation numérique populaire qui enchante les développeurs à la recherche de l'apparence de MATLAB, Octave ou R. Murthy a conclu à cette étape que le gonflement et la pilosité de l'installation des paquets Python est épouvantable.

« Juste pour faire une simple déclaration d'importation d'une ligne, numpy nécessite 285 Mo à 529 Mo de code de soutien », a-t-il dit. L'espace disque est bon marché de nos jours, et il y a des choses bien pires dans le monde que les images de conteneurs gonflés. Cependant, le fait est que construire des projets Python sur une infrastructure de déploiement moderne peut être un processus très désorganisé et impur du point de vue de l'intégration continue et de la livraison continue. Les outils d'installation des dépendances Python placeront les fichiers et les linkers dispersés dans votre système de fichiers.
Pour conclure, Murthy a déclaré qu’au niveau le plus fondamental, Python est un langage de script, comme Perl, Ruby ou JavaScript.

C'est un langage interprété. Il est idéal pour les petits programmes rapides et sales qui exécutent des tâches séquentielles à filetage unique. Il s'est imposé comme une marque puissante au sein de la communauté des chercheurs et des programmeurs scientifiques. Il y a donc incontestablement une place pour lui en tant qu'outil approprié en fonction de l'emploi. Toutefois, choisir d’utiliser exclusivement Python dans les entreprises utilisant des systèmes distribués critiques en production s'accompagne de toutes sortes de compromis considérables.

Source : Nathan Murthy

Et vous ?

Trouvez-vous les arguments de Nathan Murthy pertinents ou pas ? Pourquoi ?
Quel est votre avis sur le sujet ?
Partagez-vous les mêmes points de vue que Nathan Murthy à propos de Python ? Pourquoi ?
Comme Nathan Murthy, pensez-vous que Python ne soit pas adapté pour construire des systèmes distribués fiables et performants ? Pourquoi ?

Voir aussi

Microsoft a intégré Python 3.7 par défaut dans la MàJ Windows 10 mai 2019 de son système d'exploitation

Python Software Foundation annonce qu'elle mettra fin au support de Python 2 à partir du 1er janvier 2020 et prévient qu'elle n'apportera plus son aide pour tout problème rencontré après cette date

Meilleurs langages en 2019 selon l'IEEE : Python leader pour la troisième année consécutive. Il s'impose dans tous les domaines dans lesquels il est utilisé, du développement web à l'embarqué

Un bogue dans un code Python pourrait avoir causé des erreurs de calcul dans plus d'une centaine d'études scientifiques publiées depuis 2014

[matthius]

Passez de Python et Matlab à Julia, de Ruby à Crystal, de C à RUST.

[flapili]

python n'as jamais eu cette prétention, par contre il y a clairement de la mauvaise fois ... que ce soit sur python 2 ou encore la taille sur le disque"

Python n'a pas de véritable modèle de confidentialité

il ne faut pas reprocher à quelque chose un choix de conception, idem pour le typage ...

[magatst]

Et que dire des Bugs d’indentation !!!

[Uther]

il ne faut pas reprocher à quelque chose un choix de conception, idem pour le typage ...

Je dirait a la fois oui et non. Il n'est, en effet, généralement pas pertinent de parler d'un langage en dehors de son domaine d'utilisation normal. Cependant Python et JavaScript ont en commun d'être des langage dont l'utilisation c'est développé bien au delà de leur domaine d’origine et le but ici n'est pas de dire du mal de Python en général mais de Python utilisé là où on devrait avoir recours a un langage système.

En dehors de cela, certains choix de conception peuvent tout a fait être criticables. Si tous les choix de conception de Python 2 avaient été exempts de reproche, il n'y aurait pas eu de Python 3.

[CaptainDangeax]

La communication de ce M. Murphy est limite trollesque, je trouve.

Il commence par écrire une fonction toute sale, et puis il vient reprocher au langage de lui avoir laissé écrire une fonction toute sale. Ce n'est pas le langage qui a écrit une fonction toute sale, c'est lui...
Il reproche au langage de ne pas être fortement typé. C'est sa définition. Si ça ne convient pas, on utilise autre chose
Il reproche au langage son manque de performances. Si on veut de la performance, on ne programme pas dans un langage interprété, on programme dans un langage compilé, voire en assembleur si on veut VRAIMENT de la performance.
Il reproche le schisme qu'il y a eu entre Python2 et Python3. Il faut juste se dire que c'est un nouveau langage et que tout programme mérite un certain niveau de maintenance si on veut le garder dans le temps. C'est d'autant plus vrai que les langages finissent pas être frappés d'obsolescence. Qui programme encore en Fortran, en ADA, en Cobol, en dBase-clipper, en forth ? Qui, surtout, démarre un nouveau projet avec un langage ancien ?

[ParseCoder]

"Langage système"!!! Ai-je bien lu! Ah oui.

[Bardotj]

Je trouve son code super pas propre, je vais faire du pseudo code, ne faisant pas tout les jours du python.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
def foo(x):
  if is_valid(x):
    return "hello world"
  else:
    return bar(x)

Devrait être :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
def foo (x):
  result = valeur
  if is_valid(x):
    result = "hello world"
  else:
    result = bar(x)
 
  return result

Car oui le code est fait pour être lisible facilement, maintenable facilement. L’optimisation c est au compilo/interpréteur de la faire surtout sur l utilisation des primitives languages. On est clairement pas dans un algo compliqué ou l on cherche a améliorer la complexité (au sens algo/math).

Étant sans javascript pas d intent dans le code j ai sauté une ligne pour le return pour signifier qu il n est pas dans le else. Il s agit néanmoins bien d’une instruction appartenant a foo.

[emixam16]

Il commence par écrire une fonction toute sale, et puis il vient reprocher au langage de lui avoir laissé écrire une fonction toute sale. Ce n'est pas le langage qui a écrit une fonction toute sale, c'est lui...

Complétement d'accord. Surtout que même avec un langage fortement typé, si je veux écrire une fonction `is_valid(x)` qui retourne un `struct chou_fleur*`personne ne va m'en empêcher... Un mauvais code reste un mauvais code dans n'importe quel langage. Et il n'y a aucun langage généraliste avec lequel je ne puisse pas écrire de code pourri, donc c'est minable de taper sur le python pour ça.

Quant au schisme python2/3, on commence à avoir pas mal de recul et la transition est quasiment faite partout vers python 3. En tout cas ce sera rapidement le cas avec la mort programmée de python2.

Pour les performances, évidemment que le python n'est pas adapté à tout. Mais pour un bon nombre de scénarios ce n'est pas un problème. Pour d'autres, comme souvent en Machine Learning, les API sont en python pour être facilement accessibles et les opérations sensibles aux performances sont écrites en C.

Bref, évidemment que le Python n'est pas fait pour tout (personnellement j'ai une sainte horreur de l'absense de typage en Python et je travaille dans des systèmes ou la performance est reine). Mais ça ne signifie pas qu'on ne puisse rien faire de sérieux/propre en python

[rattlehead]

Ça n'est pas le souci. c'est que tu supposes que bar(x) peut renvoyer une chaine ou autre chose éventuellement un int vu qu'il n'y a pas de type défini au niveau de la définition de foo(x).
en gros dans un langage "standard" tu aurais function foo(x) as string ou string foo(x). Là tu ne sais pas.

[Fagus]

Je ne comprends pas très bien cette querelle sur le typage de python. Oui, ce n'est pas typé par défaut et donc on peut faire des erreurs grossières de typage, mais c'est pratique pour écrire un script sale à l'arrache. Pour le code sérieux on peut utiliser le typage optionnel (mypy, pycharm).

il y a d'autre problèmes plus ennuyeux : si on veut programmer sur du desktop, la distribution est vraiment compliquée pour obtenir un installateur en un fichier pour l'utilisateur final, ce qui est vraiment un gros problème (un de mes logiciel open source de desktop en python a juste abandonné la distribution de binaires pour windows car leur code plante les outils tiers qui assemblent tout le code, les dépendance et un interpréteur et que personne n'a de solution...). Je regrette beaucoup que les dév de python n'intègrent pas à python les outils pour déployer simplement (genre comme delphi ou java)

[Uther]

Il commence par écrire une fonction toute sale, et puis il vient reprocher au langage de lui avoir laissé écrire une fonction toute sale. Ce n'est pas le langage qui a écrit une fonction toute sale, c'est lui...

Forcément pour la démonstartion, il a pris un cas simple, où l'erreur est évidente. Mais tout l’intérêt du typage, c'est justement d'attraper des erreurs qui ne sont pas forcément facile débusquer, parce que le développeur qui ne fait pas d'erreur, ça n'existe pas.

Il reproche au langage de ne pas être fortement typé. C'est sa définition. Si ça ne convient pas, on utilise autre chose.
Il reproche au langage son manque de performances. Si on veut de la performance, on ne programme pas dans un langage interprété, on programme dans un langage compilé, voire en assembleur si on veut VRAIMENT de la performance.

Justement sa diatribe vise particulièrement l'utilisation de Python dans le domaine système où il n'est pas adapté, ce qui est malheureusement de plus en plus le cas.
En fait dès qu'un langage gagne en popularité, notamment au niveau des débutants, il y a toujours des gens qui sont tentés de l'utiliser partout sans se poser les bonnes question. Ça a été le cas du VB et du Java à une époque, maintenant c'est le JavaScript et le Python.

Il reproche le schisme qu'il y a eu entre Python2 et Python3. Il faut juste se dire que c'est un nouveau langage et que tout programme mérite un certain niveau de maintenance si on veut le garder dans le temps.

La plupart des langages d'un age similaire au Python, voire bien plus vieux, ont pourtant su gérer leur transition bien mieux. Java et C++ par exemple ont su évoluer sans briser lourdement l'écosystème.
Perl a choisi de changer de nom pour marquer la clairement la rupture.

C'est d'autant plus vrai que les langages finissent pas être frappés d'obsolescence. Qui programme encore en Fortran, en ADA, en Cobol, en dBase-clipper, en forth ? Qui, surtout, démarre un nouveau projet avec un langage ancien ?

- Cobol : encore très utilisé dans le bancaire, même si c'est vrai que c'est généralement pour des base code existantes complexes
- Fortan : Pas mal de scientifique en font encore y compris pour du neuf.
- Ada : est toujours utilisé dans des domaine particulier qui nécessitent de la sécurisation


Pour Forth en effet c'est plus compliqué, mais beaucoup de langage bien plus ancien que le Python comme le C, C++ ou le LISP se portent toujours bien.

[defZero]

MDR, Le mec c'est "Captain Obvious" ressuscité
L'ingénieur de chez Tesla il l'as eu comment sont poste ?
Mr MURPHY Nathan, un nom qui restera dans les annaux .

Trouvez-vous les arguments de Nathan Murthy pertinents ou pas ? Pourquoi ?

Je croit que le mec à fait un "poste blague" à ces collègues et qu'il n'as pas voulue attendre le 1er Avril .

Le mec vient ce plaindre :

• Qu'un langage dynamique soit dynamique. Il n'as semble t-il pas assimilé le prince du "Duck Typing".
• Qu'un langage de script, ne soit qu'un langage de script.
• Et en plus, il vient nous informé qu'un langage mono-thread, n'est pas bon en multi-thread/parallélisme/distribution .

Il est Ingénieur Commerciale le gars ?
En plus sont affirmation comme quoi Python ne serait pas fortement typé est fausse (enfin, moins qu'ADA et plus que C dans tous les cas).

Quel est votre avis sur le sujet ?

C'est évident que d'architecturer un système distribué complexe, ce n'est pas ceux à quoi Python ce destine.
Python est un très bonne outils dans son domaine, ni plus, ni moins.
Pour des tâches de scripting, de création d'outils ou/et de développement sans trop de contraintes IO/CPU, il est parfait.
C'est un langage propre, facile à apprendre et à maintenir, mais il ne faut pas pensé qu'il sera efficace dans tous les domaines.
Ce qui laisse à penser que les gars de chez Tesla auraient tendance à ne pas utilisé le bon outil au bon endroit.

Enfin, la vrai force de Python à l'heure actuelle, ce n'est pas la technique derrière le langage, mais la communauté (enfin, surtout ces contributions ).
Techniquement, tous les langage récent font mieux que Python, maintenant, très peut on une masse critique de contributeurs et de lib disponible, à la hauteur de ce que propose Python.
C'est l'inertie technologique qui impose Python de fait, mais c'est pareille pour une multitude de plateformes (JAVA/.NET/C++/Node/...etc).

P.S. : Je ne dit pas que ces plateformes ne font pas le job, juste, que depuis il y a déjà eu mieux mais qu'elles continuent malgré tout à être utilisé pour tout et n'importe quoi, sous prétexte qu'il y a de l'"expertise sur ces stack" (terme repris d'un recruteur, autour d'un café).

Partagez-vous les mêmes points de vue que Nathan Murthy à propos de Python ? Pourquoi ?

Mouais ... Le gars énonce certains fait et donc qui ne sont pas opposables.
En parallèle, ils balance quelque contre vérité, mais dans tous les cas, il (ou Tesla) semble utiliser Python de la mauvaise manière en dehors de sont champs d'application.

Comme Nathan Murthy, pensez-vous que Python ne soit pas adapté pour construire des systèmes distribués fiables et performants ? Pourquoi ?

Oui, mais pour ça défense, Python n'as jamais été créer pour ça .
Un langage Distribué + Fiable + Performant, ça n'existe pas (à ma connaissance et en 2019 ).
En langage Performant, on a les ASM/C/C++/Fortran/ADA/Pascal/Rust/...etc (plein d'alternative bas niveau genre Zig/Odin/Kitlang/Jai/...etc).
En langage Distribué, on a quoi, Erlang/Scala/Clojure.
En langage Fiable, je regrette mais pour l'heure, le plus fiable reste ADA (et ASM, mais on est pas Maso ) mais même lui peut cracher dans certain cas lorsque la pression sur le cache ou la mémoire est trop importante.
Ce que demande le Cpt. Murphy, ça n'existe juste pas.
Par contre, on peut très bien combiner ces langages dans un même projet pour tirer partie de leurs avantages respectifs.
Mais le Cpt. ne semble pas remettre sa réflexion en cause et ça m’inquiète sur le niveau de mec qui construise des batteries, potentiellement explosive et des véhicules, potentiellement tueurs de cycliste .

Bref, si vous avez des actions, c'est le moment de vendre .

Enfin, tous les inconvénients qu'il cite sur Python, ne sont que des problème d'implémentation particulié.
Le langage en lui même ne les imposes pas que je sache ?
Il aurait très bien pu faire comme Elixir avec Ruby, mais en partant sur une syntax Python et là il aurait eu Distribué + Fiable (enfin, disont qui crache sans conséquences ).

[Sodium]

Il commence par écrire une fonction toute sale, et puis il vient reprocher au langage de lui avoir laissé écrire une fonction toute sale. Ce n'est pas le langage qui a écrit une fonction toute sale, c'est lui...

On parle d'applications critiques là, le plus efficace pour s'assurer que l'on ne peut pas faire des erreurs de programmation grossières, c'est que le langage ne les permette pas.

C'est un peu comme dire que poser un verre de café sur un clavier d'ordinateur n'est pas dangereux, il suffit de faire en sorte que les gens ne soient pas maladroits.

[Betameche]

Complétement d'accord. Surtout que même avec un langage fortement typé, si je veux écrire une fonction `is_valid(x)` qui retourne un `struct chou_fleur*`personne ne va m'en empêcher... Un mauvais code reste un mauvais code dans n'importe quel langage. Et il n'y a aucun langage généraliste avec lequel je ne puisse pas écrire de code pourri, donc c'est minable de taper sur le python pour ça.

Je ne suis pas vraiment d'accord avec ta remarque pour deux raisons.
Premièrement, l'exemple de code donné n'est pas du code python pourri. Une fonction qui fait une vérification de validité et retourne une valeur par défaut ou un résultat sur la valeur passée c'est assez commun dans un code. Pour faire la présentation de ce qu'il trouve problématique, je trouve qu'il choisit un code assez simple sans chercher des usages inhabituels, et sous une forme que l'on retrouve partout. D’ailleurs le code de Bardotj est plus sale de mon point de vu. Après on peu me rétorquer qu'il n'y a pas de vérification du type de l'entrée …

Deuxièmement, même dans un langage peu typé comme le C/C++ le code ne compilerait pas dans la plupart des cas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
<source>:14:16: error: could not convert 'is_valid(i)' from 'choux_fleur' to 'bool'
 
  14 |       if(is_valid(i))
      |           ~~~~^~
      |                     |
      |                choux_fleur

Sauf dans le cas des pointeurs, le langage permettant de vérifier directement par if s'il est un NULL/nullptr ou pas.
Ce choix est aussi critiquable, même si c'est un choix de conception. Rust par exemple a fait un autre choix, le if ne prenant q'un type bool comme opérande.

Pour le reste je suis plutôt d'accord avec defZero, avec comme réserve qu'il me semble légitime de critiquer un langage dans ses domaines d'applications en plus des domaines pour lesquels il a été créé.

[Uther]

MDR, Le mec c'est "Captain Obvious" ressuscité
L'ingénieur de chez Tesla il l'as eu comment sont poste ?
Mr MURPHY Nathan, un nom qui restera dans les annaux .

Je crois que vous vous méprenez lourdement sur l’intention du message. Dès la première phase l'article est clair sur son intention :

Python est vu comme un langage de programmation à tout faire; cependant sa conception limite son potentiel en tant que langage sytème fiable et à haute performance. Malheureusement, tous les programmeurs ne sont pas au courant de ses limitations

Il ne prétend pas démontrer quoi que ce soit de nouveau, il déplore juste que la forte popularité de Python fait qu'il est parfois surestimé.
Bref cet article ne s'adresse pas aux experts qui connaissent bien les limitation du langage, mais à ceux qui sont tenté de faire du Python partout parce qu'il ne connaissent pas assez les autre langages, ou aux décisionnaire pas forcément au fait de tous les détails techniques, pour leur expliquer pourquoi ça n'est pas une bonne idée de l'utiliser partout.

[wiztricks]

Salut,

C'est un langage interprété. Il est idéal pour les petits programmes rapides et sales qui exécutent des tâches séquentielles à filetage unique. Il s'est imposé comme une marque puissante au sein de la communauté des chercheurs et des programmeurs scientifiques. Il y a donc incontestablement une place pour lui en tant qu'outil approprié en fonction de l'emploi. Toutefois, choisir d’utiliser exclusivement Python dans les entreprises utilisant des systèmes distribués critiques en production s'accompagne de toutes sortes de compromis considérables.

Je suis plutôt d'accord avec la conclusion.
Un langage interprété n'ayant pas vocation à être un langage système, le monsieur enfonce nombre de portes ouvertes que nous connaissons (ou sommes supposés connaître) depuis 30 à 40 ans.
Après, si son intention est de sensibiliser les jeunes générations de développeurs et de décideurs qu'on ne peut pas tout faire avec Python... bah s'il a l'impression que c'est nécessaire et que son article apportera quelque chose.

- W

[Xavier98]

Tout ce qu'il a trouvé comme sois disant bug ou mauvais au langage a déjà été déclarer par la Fondation Python python.org, le langage Python a été conçu avec une simplicité ce qui le rend très différent des autres langages.

Par exemple: Youtube, Netflix etc. ont été développer avec python.

[Invité]

...
Il est Ingénieur Commerciale le gars ?
..
Ce que demande le Cpt. Murphy, ça n'existe juste pas.
Par contre, on peut très bien combiner ces langages dans un même projet pour tirer partie de leurs avantages respectifs.
Mais le Cpt. ne semble pas remettre sa réflexion en cause et ça m’inquiète sur le niveau de mec qui construise des batteries, potentiellement explosive et des véhicules, potentiellement tueurs de cycliste .
...

Merci pour la rigueur de cette analyse.
Et concernant cette interview ci, où LeCun émet des réserves sur l'utilisation de python pour l'IA, c'est aussi parce que c'est un incompétent qui a eu son diplome dans une pochette surprise ?
https://venturebeat.com/2019/02/18/f...-language/amp/

[Steinvikel]

Cette histoire de typage, je la vois souvent pour des histoires de "sécurité", pour contenir des erreurs ou des incohérences. Mais l'effet phénoménal à notre époque, c'est de permettre au compilateur de fait un tas d'optimisations bien plus pertinentes !

Un exemple typique de l'utilité de pondre une ligne de code généreusement explicitement, écrite sur un langage typé et compilé.
NB : son but était de faire tourner un jeu sur un CPU sans faire appel à la RAM, le HDD, etc. en s'appuyant intégralement sur le processeur et son cache --> MSP 430-FR5849 (16 bit, 16 MHz, 66 ko, 10$)

Vous voyez sur ce court extrait de 2min, la programmation en C++ d'un space-invaders, la problématique est la suivante :
Il pond du code (à gauche) ...et une fois compilé, le code asm généré est gigantestque (à droite).
Que peut-il faire pour permettre à son code asm de "maigrir" ? --> déclarer sa variable statique de manière explicite avec "const" car elle est ici utilisé comme constante, et non comme une variable.
conséquence --> l'overhead de 350 instructions assembleur se transforme en simple 6 instructions --> merci à l'optimisation du compilo !

https://youtu.be/zBkNBP00wJE?t=1599