La conception de Python limite son potentiel en tant que langage système fiable et performant estime Murthy

Salut,

Citation:

---

Envoyé par SimonDecoline

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.

Citation:

---

Envoyé par 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 ! :D

---

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

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.

"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

Citation:

---

Envoyé par Dodrekai

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 :

Citation:

---

Envoyé par Nathan Murthy

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.

---

Citation:

---

Envoyé par Bardotj

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

Code:

---

1 2 3 4 5

def foo(x): if is_valid(x): return "hello world" else: return bar(x)

---

Devrait être :

Code:

---

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.

---

Chacun sa définition de lisibilité, perso je trouve le premier cas bien plus lisible.

Sinon il reste :

Code:

---

1 2	def foo(x): return is_valid(x) ? "hello world" : bar(x)

---

Citation:

---

Envoyé par L33tige

Chacun sa définition de lisibilité, perso je trouve le premier cas bien plus lisible.

Sinon il reste :

Code:

---

1 2	def foo(x): return is_valid(x) ? "hello world" : bar(x)

---

---

on peut aussi ecrire

Code:

---

foo = lambda x: "hello world" if is_valid(x) else bar(x)

---

non?

edit: corrigé

is_valid(x) ? "hello world" : bar(x) n'est pas une syntaxe valide en Python.
La syntaxe correcte est : "hello world" if is_valid(x) else bar(x).

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

Citation:

---

Envoyé par bizulk

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

---

:salut:

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.

Salut,

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

Citation:

---

Envoyé par danielhagnoul

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

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/

Citation:

---

Envoyé par ParseCoder

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

---

Il faut s'entendre sur ce qu'est un langage système. Si c'est un langage pour coder un noyau, un driver matériel, etc, c'est clairement inadapté ! Si c'est un langage pour écrire toute la glue qui fait le système tenir ensemble, genre des tâches planifiées lancées par CRON, ça fait le job, comme bash ou perl...

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

Citation:

---

Envoyé par CaptainDangeax

Il faut s'entendre sur ce qu'est un langage système. Si c'est un langage pour coder un noyau, un driver matériel, etc, c'est clairement inadapté ! Si c'est un langage pour écrire toute la glue qui fait le système tenir ensemble, genre des tâches planifiées lancées par CRON, ça fait le job, comme bash ou perl...

---

En effet, une partie du problème vient du fait qu'il n'y a pas de définition officielle du terme langage système.
Cependant le premier cas est le plus couramment admis. Pour le second on parle généralement plutôt de langage de script.

Citation:

---

Envoyé par CaptainDangeax

Il faut s'entendre sur ce qu'est un langage système. Si c'est un langage pour coder un noyau, un driver matériel, etc, c'est clairement inadapté ! Si c'est un langage pour écrire toute la glue qui fait le système tenir ensemble, genre des tâches planifiées lancées par CRON, ça fait le job, comme bash ou perl...

---

Pour moi, ici, on est dans le raccourci d'expression de la langue française (voir autre langue)...


Dans le principe, quand on parle de système, on est dans le bas niveau (vraiment le très bas), ce qui fait que l'on voit des langages tel que C ou assembleur...

Et on a ce que l'on appelle ou devrait appeler les langages de l'administration système et ici, cela fait intervenir des langages de script tel que les shell, perl, python...

Et bien sur, des langages tels que java et/ou php n'ont rien à faire dans ces catégories, ce sont ce que je nommerais plus des langages applicatifs, de présentation ou d'administration fonctionnelle.

Après, rien n'interdit au langage du bas de monter vers les niveaux supérieurs mais l'inverse est une aberration.

Enfin, c'est mon point de vue, en aucun cas, je ne critique un langage en particulier.

Citation:

---

Envoyé par CaptainDangeax

Qui programme encore en Fortran, en ADA, en Cobol, en dBase-clipper, en forth ?

---

Moi ... En Fortran sur du legacy. Les colboliens existent, et pas sur du legacy (il m'arrive d'en fréquenter).