Discussion :

[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 ).

[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.

[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/

[wiztricks]

Salut,

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 ?

Vous avez une idée du nombre de langages de programmation que nous avons inventé ces 50 dernières années? Des milliers.
Beaucoup ont été des flops, certains sont encore très utilisés dans quelques niches, rares sont ceux qui sont devenu "populaires" et de toutes façons çà dure quoi 10ans, 15 ans?
Après on passe à autre chose.

Mais la question de base reste: pourquoi inventer un nouveau langage "métier" au lieu de mettre un langage passe partout "on top" d'une bibliothèque métier écrite avec le langage ad hoc? LeCun peut dire ce qu'il veut, il reproduit le schéma de penser que nous avons suivi ces 40 dernières années: un nouveau domaine d'application => un nouveau langage spécifique....

Ca me fait penser à la découverte de Neptune. Le Verrier constate des anomalies dans l'orbite d'Uranus et déduit par le calcul que la perturbation devait être due à une planète jusqu'alors inconnue. Bingo. on découvre Neptune. Il a essayé d'appliquer le même raisonnement à Mercure... pas de bol, il n'a pas pu trouver Vulcain et il a fallu attendre la théorie de la relativité générale d'Einstein pour expliquer les excentricités de Mercure.

Ainsi va la science, on répète ce qu'on sait jusqu'à plus soif avant de tout jeter par terre.
Les gens intelligents sont aussi accrochés à des croyances qui leur font souvent rater le coche quand ils ne sont pas aussi "réactionnaires" que l'Inquisition.

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 !

Normalement on écrit avec Python une orchestrations originales d'opérations réalisés par des bibliothèques écrites avec des langages compilés.
Une fois que ces orchestrations trouvent un domaine d'application plus large, on les recode tout ou partie en langages plus optimisables.
Ca permet de développer rapidement des applications (le nerf de la guerre) à un coût raisonnable puis quand on sait ce qu'on veut avoir des spécifications qui permettront de recoder tout çà rapidement dans des langages plus efficaces.
C'est comme çà qu'il faut envisager le cycle de vie des applications avec Python: on peut envahir tous les domaines de façon brouillone... Quand çà se stabilise un peu on peut optimiser.

- W

[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.

[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.

[yahiko]

Au final, il s'agit davantage d'un reproche sur les cas d'utilisation du langage que sur le langage en lui-même.
L'auteur devrait tout de même mieux formuler ses propos car le tout peut laisser croire que Python est un "mauvais" langage. Ce n'est pas le cas. C'est juste un outil à utiliser à bon escient.

[Dodrekai]

"Python est considéré comme un langage de programmation faiblement typé ou dynamiquement typé. "

Il me semblait que Python était fortement type et dynamiquement typé. L'auteur semble assimiler les deux, ce sont deux notions différentes, non ?

Il dit aussi que python ne permet pas de sécurité dactylographique ce qui n'est plus vrai depuis la version 3.5 avec les type hints qui, justement, permettent de préciser le type attendu des arguments ainsi que le type retourné par la fonction. https://docs.python.org/3/library/typing.html

Lorsqu'il indique que dans la plupart des distribs mac et linux on a un interpréteur python 2.7 et que l'on risque de ne pas avoir conscience que l'on utilise python 2 plutôt que le 3, cela me parait plutôt étrange. La programmation système, me semble-t-il n'est pas pour les débutants, il me parait douteux que le développeur fasse une erreur aussi grossière que de ne pas se rendre compte qu'il n'utilise pas la version du langage qu'il voulait utiliser a la base... Après, c'est sur que le passage de la version 2 a la 3 pose de gros problèmes.

"Il est idéal pour les petits programmes rapides et sales", c'est encore cette légende comme quoi python est un langage de script et pas un "vrai" langage. Il est certain que Python n'est pas adapté a toutes les pratiques, ne serait-ce que parce-qu'il n'est pas particulièrement rapide, mais quel langage est adapté a tout les besoins...

edit : clarifications

[Pyramidev]

Il dit aussi que python ne permet pas de sécurité dactylographique ce qui n'est plus vrai depuis la version 3.5 avec les type hints

Il n'a pas oublié les type hints, car il a cité pytype et mypy. Extrait de l'article original :

To improve static type checking in Python, developers made libraries like jedi, pytype, mypy, and toasted-marshmallow, but they are often not used in most projects because they do not belong to the standard toolchain or because it often requires some significant effort to invest time updating legacy code with boilerplate annotations if type safety gets treated as an afterthought.

[bizulk]

L'inconstistance des données, c'est vraiment le gros risque avec les langages comme python et peut-être aussi Javascript. Le dev se doit d'être très rigoureux sur le sujet et bien documenter ses fonctions pour les tests, sinon effectivement impossible de sécuriser le code. Donc pour pas des petits juniors.

Parler ensuite de code plus lent... bon et bien c'est le problème de tous les langages interpretés. Après le code peut-être pré-compilé. Il y aurait toujours l'overhead du typage dynamique selon moi mais à voir si c'est très significatif dans ce cas et même ainsi on peut essayer profiler et faire appel aux ffis.

L'intérêt de python pour moi c'est qu'avec peu de code on fait beaucoup de choses.
ET c'est vrai que pour produire de petit outils, ou faire du calcul sans risquer d'overflow le typage dynamique est très pratique.

A voir mais le module typing viendrait compenser cette faiblesse (module tout frais visiblement). Si le module est très utilisé cela pourrait faire orienter les évolutions du langage.
Il tient également aux utilisateurs de s'investire pour faire bouger les choes

[danielhagnoul]

[...] A voir mais le module typing viendrait compenser cette faiblesse (module tout frais visiblement). Si le module est très utilisé cela pourrait faire orienter les évolutions du langage.
Il tient également aux utilisateurs de s'investire pour faire bouger les choes

Avec Visual Studio Code on dispose de l'extension typescript pyright qui fait du contrôle de type dès la frappe du code. On peut faciliter son travail en utilisant plus ou moins le module typing.

Bref, le contrôle de type c'est une affaire de volonté pas de moyen.

Pour le reste, si l'on essaie de faire n'importe quoi avec Python, les critiques de Nathan Murthy me semblent justifiées.

Je trouve Python et "ses piles" génial, mais je lui trouve aussi un défaut : croire que le développeur sait toujours ce qu'il fait est une erreur de jugement qui prive le langage de quelques garde-fous.

[Beginner.]

Salut,

Pour JavaScript il y a TypeScript... Existe-t-il un équivalent pour Python ?

Avec Visual Studio Code on dispose de l'extension typescript pyright qui fait du contrôle de type dès la frappe du code. On peut faciliter son travail en utilisant plus ou moins le module typing.

Merci, je viens de l'installer...

Il y en a d'autres apparemment mais peut-être qu'il n'y a pas d'extensions pour les autres...

[Bubonik software]

L’argumentaire de cet ingénieur est assez partisan, mais il n’a pas tort sur le fond. Cependant :

1) Concernant le typage, comme le rappelle Dodrekai, Python est typé dynamiquement, mais il pas faiblement, surtout Python3 : chaque valeur a un type bien déterminé ; il existe beaucoup de types spécialisés différents et peu de conversions implicites. Par contre, effectivement, le type est attaché à la valeur, pas à la variable.

2) Concernant les accusations de permissivité, je pourrais accuser bien des langages "stricts" d’autoriser le développeur à indenter n’importe comment le code et de le rendre illisible. Le concours IOCCC existe pour le C (langage système, compilé, typé statiquement)… un tel concours serait beaucoup moins drôle avec Python .

3) Sur les avantages de l’analyse statique, rien à dire : c’est vrai que ça contribue à améliorer la sécurité et la performance. Et l’analyse statique peut aller beaucoup plus loin avec un typage statique. Oui, il existe des outils pour résoudre cette lacune de Python, mais si on en a vraiment un besoin indispensable, peut-être qu’on n’aurait pas dû choisir Python (je dis bien "peut-être" : après tout, il peut y avoir une killer feature de Python qui fait qu’on va quand même l’utiliser).

Utiliser Python dans des domaines où il est loin d’être idéal n’est pas une garantie d’échec, mais ça implique d’avoir une certaine rigueur (qui peut être imposée si besoin par les chefs de projet).

Ensuite, oui, c’est vrai, Python aura bientôt 30 ans et certains projets ont probablement de la dette technique. J’en ai sur mes bibliothèques perso : les faire monter en qualité de code prendrait du temps que je n’ai pas forcément. La même chose est sûrement vraie pour des projets plus ambitieux développés en Python.

Par contre, je trouve contrairement à Nathan Murthy que Python est un langage remarquablement bien géré par sa fondation (ce n’est pas LE seul langage dans ce cas, mais il doit beaucoup de sa popularité au concept “batteries included” qui a été intelligemment mis en pratique). Même dans les bibliothèques non incluses en standard, on s’y retrouve bien. Accuser numpy de peser ½ Go me semble assez mesquin (vu que le gars le compare à Matlab, Octave ou R, alors il devrait dire combien d’espace disque occupent ces solutions).

Les problèmes de portabilité / pérennité des dépendances et de l’environnement de développement, ça existe dans tous les langages. J’en ai fait l’expérience avec le C, le C++, le Go, le Java, le BASIC (sans même avoir beaucoup pratiqué). Et oui, avec Python aussi.

Au fait, je suis le seul à avoir immédiatement pensé à ce CommitStrip ? http://www.commitstrip.com/fr/2019/1...hon-what-else/

[byrautor]

Merci à tous les intervenants.
ça me rafraichit la mémoire.
Un ancien.