Zeph (./3597) :Je trouve que le fait que l'inférence de type soit liée au langage et présentée par l'IDE (Scala), ou directement faite par l'IDE (Python) ne change pas grand-chose en pratique : tu auras l'info au moment de coder (je trouve que s'il faut attendre la compilation pour trouver un bug de typage, c'est que c'est déjà trop tard).
./3590 : sérieusement.
./3589 : non en fait à la réflexion il y a des langages "modernes" statiquement typés qui misent sur l'inférence de type pour éviter d'alourdir la syntaxe (Scala, Groovy, Kotlin, etc.) mais rien qui se rapproche de la syntaxe de Python (après j'ai l'impression que la grande force de Python c'est la richesse de sa lib standard, pas tellement le langage en lui-même)Je trouve que ces langages transpirent souvent le Java (à cause de la JVM pensée pour Java), sans compter que le temps de chargement est souvent désagréable (ça limite l'usage comme langage de script classique).
flanker (./3602) :Quelle est la différence ? Quand tu as l'erreur "au moment de coder", à moins que ce soit une IDE qui refasse tout le boulot (auquel cas ton langage n'est sûr qu'à condition d'utiliser l'IDE kivabien) ça passe par une compilation en background. Dans tous les cas ce qui est important c'est qu'un maximum d'erreurs soit détecté avant de commencer à exécuter le programme, et ça a d'autant plus de valeurs que les erreurs identifiées se situent dans des branches rarement atteintes. Tous les tests dynamiques à base de "if typeof machin != truc throw new Exception" c'est sympa pour fournir un peu plus de contexte au mec qui va débugger, mais en pratique ça veut dire que le programme a planté en pleine exécution.
tu auras l'info au moment de coder (je trouve que s'il faut attendre la compilation pour trouver un bug de typage, c'est que c'est déjà trop tard).
flanker (./3602) :Je n'ai pas dit qu'avoir un code expressif ne soit pas important (en revanche je ne suis pas d'accord pour "compact"), juste que ça n'était pas un atout particulièrement marquant de Python ; il y a d'autres langages dynamiques qui permettent le même niveau d'expressivité, donc ça n'est pas un argument qui le démarque.
Je ne suis pas d'accord avec toi sur la grande force du Python (avoir un code compact et expressif compte pas mal), mais bon, les égouts et les couleuvres…
uelle est la différence ? Quand tu as l'erreur "au moment de coder", à moins que ce soit une IDE qui refasse tout le boulot (auquel cas ton langage n'est sûr qu'à condition d'utiliser l'IDE kivabien)Je parle bien de ça ; on est d'accord, ça demande d'utiliser un IDE correct et les asserts sont un pis-aller (un peu moins quand l'IDE s'en sert pour aider l'inférence de type).
Dans tous les cas ce qui est important c'est qu'un maximum d'erreurs soit détecté avant de commencer à exécuter le programmeÇa, on est d'accord, mais je serais volontiers encore moins indulgent que toi : Je trouve que les erreurs devraient être montrées à partir du moment où elles peuvent être détectées, donc directement dans l'IDE pour les erreurs de type.
Zeph (./3608) :En fait si, c'est exactement ça, du moins pour les IDE les plus avancés comme Eclipse qui a son propre compilateur Java intégré. Certains utilisent directement le vrai compilateur, mais un compilateur spécifique permet généralement d'avoir de meilleures performances en se concentrant uniquement sur la gestion des erreurs et faisant l'impasse sur la génération du code. Ça permet aussi d'avoir des réactions plus adaptées au code en cours de frappe qui est forcément faux.
Tiens, je ne sais pas comment font les IDE modernes pour détecter les erreurs de type, mais ça veut dire être capable de parser un langage et faire une passe d'inférence de type, ce qui plonge quand même assez profondément dans la première passe d'un compilateur. Je serais étonné qu'un IDE s'amuse à réimplémenter tout ça pour les langages qu'il supporte vu la quantité de boulot que ça représente, quand on peut demander au compilateur de s'en occuper pour pas cher (puisqu'on s'arrête juste après la reconnaissance, pas besoin de déclencher réellement une compilation et encore moins d'optimiser le code).
Zeph (./3611) :Pas que de performance, mais de profondeur d'analyse du code (il y a plein de choses qui ne seront jamais détectées à la compilation et uniquement à l'exécution, et encore que dans des cas précis).
Ça veut dire que les mainteneurs doivent se tenir à jour de toutes les évolutions du (des) langage(s) supporté(s) pour rester au même niveau que le compilateur ? C'est quand même l'enfer, surtout avec des langages encore plus compliqués à analyser que Java, je ne comprends pas comment le seul critère de performance peut justifier un choix pareil
Zerosquare (./3618) :Quand c'est évitable, certainement ^^
ça me semble absurde de réinventer un compilateur dans l'IDE.