yN & IRL - Page 121

y a pas de directives preprocesseur en python? histoire de limiter ces runtime checks aux build debug?

Zeph (./3597) :
./3590 : sérieusement.

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).
Bien sûr, avec du typage dynamique l'inférence sera moins fiable mais tu gagnes en souplesse (et parfois, ça simplifie beaucoup la vie). On peut au passage espérer que les annotations soient progressivement utilisées pour aider les IDE. Avec du typage statique… bah c'est le contraire

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

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… mais l'écosystème est important, c'est sûr Autre avantage, comparé à beaucoup de langages, l'écosystème est très homogène : tout le monde utilise le même style de code, les mêmes outils de documentation, de test, les sites pour uploader binaires, code et doc, etc. Du coup, c'est facile de se plonger dans le code d'un autre.

Ça ne m'empêche pas de regarder avec attention les langages « de nouvelle génération »

./3601 > le flag -O devrait te convenir

Zero: pour moi en basic l'utilisation de $/# est plus lié a une limitation de l’interpréteur qu'au langage en lui même

flanker (./3602) :
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).

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.

flanker (./3602) :
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…

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.

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

C'est sûr que ça demande d'utiliser un IDE correct, mais bon, c'est un peu vrai quelque soit le langage J'imagine (sans avoir vérifié, j'avoue) que les IDE bien fichus évitent la compilation en arrière-plan pour détecter les erreurs de type, n'est-ce pas le cas ?

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.

(faudrait que tu expliques à Zeph ce qu'est un IDE, il n'en a jamais utilisé )

J'ai dû mal me faire comprendre ; je citais le message de Bob pour compléter son message, mais je suis du même avis : les assert typeOf(machin) utilisés à l'exécution arrivent trop tard (mais les IDE peuvent les utiliser lors de l'écriture pour aider l'inférence de type, du coup ça peut être utile même sans jamais être utilisé à l'exécution).

Bref, tout ça pour dire que les IDE bien fichus diminuent très largement le principal inconvénient des langages à typage dynamique (l'absence de détection de bugs à la compilation), à condition de respecter de bonnes pratiques et de les aider un peu de temps en temps.

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

Mais bon c'est un détail, j'ai l'impression qu'on est d'accord sur le fond

Je suis de l'avis de Zeph, le typage dynamique fait que les erreurs ne sont détectées qu'à l'exécution, ce qui est absolument le mauvais moment, surtout parce que ça embête tes utilisateurs avec tes erreurs qui ne les regardent pas. Je dirais même que le typage dynamique est tout simplement une erreur de conception.

L'inférence de type dans les EDIs est impossible pour les langages Turing-complets à typage dynamique, c'est équivalent au problème de l'arrêt. Tout EDI qui dit proposer cette fonctionnalité sera forcément à un moment ou l'autre incapable de déterminer le type d'une variable. De plus, le typage dynamique permet aussi de réassigner une valeur d'un autre type à une variable, ce qui rend totalement impossible le typage de cette variable, et cela même si on avait un oracle pour le problème de l'arrêt. Comme cela peut se produire même à l'intérieur d'une boucle, même le typage de la variable à un endroit donné du code est impossible. Au mieux, on peut donner un ensemble de types possibles (et c'est ce que fait kdev-python dans ce cas).

Le typage statique permet aussi à l'EDI de détecter les incohérences de type de manière beaucoup plus fiable, les bons EDIs C/C++ le font.

Zeph (./3608) :
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).

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.

Ç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

Zeph (./3611) :
Ç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

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).
PHPStorm est extrêmement puissant à ce niveau-là, et chaque version le rend plus efficace encore, et je pense que tous les IDE de JetBrains font de même (ce qui, effectivement, implique au moins une mise à jour à chaque version majeure du langage, mais c'est aussi leur modèle commercial, en fait ^^).

Oui j'étais toujours dans le contexte de langages non-dynamiques, sinon c'est beaucoup moins vrai en effet

Et pour poursuivre la réflexion, le fait d'utiliser un IDE "intelligent" me fait, personnellement, coder mieux. Il y a plein de situations susceptibles de lever un notice ou un warning que je laissais passer parce que je savais que ça ne paraîtrait pas en production et que ça n'aurait pas d'incidence (une fonction qui peut renvoyer un tableau ou false, par exemple, et je faisais un foreach dessus sans me préoccuper du type), alors que maintenant je vérifie le type de ma variable, l'existence d'une clé de tableau, etc. ; tout simplement parce que mon IDE m'en avertit à la volée (et, du coup, je me fixe aussi comme objectif un zéro notice à l'exécution).

Pour le C/C++, pas mal d'IDE utilisent LLVM en backend pour contrôler le code écrit.
Certains IDE, comme KDevelop ou CodeBlocks, ont droppé leur parseur perso pour l'utiliser, par exemple.

Je suppose que tu parle plutôt de CLang que de LLVM en entier. La partie backend du compilateur est pas vraiment utile pour la vérification du code.

yup, my bad.

Je suis assez d'accord avec Zeph : ça me semble absurde de réinventer un compilateur dans l'IDE. En plus de la duplication d'efforts que ça représente, il y a toujours le risque qu'il ne se comporte pas pareil que le "vrai" compilateur. Si c'est une simple aide au développement, c'est embêtant mais ça n'est pas encore trop grave ; par contre, si c'est le seul moyen de détecter les erreurs avant l'exécution, ça devient dangereux.

Ça me semble beaucoup plus intelligent de sous-traiter le boulot au "vrai" compilateur (mais ça nécessite une collaboration intelligente entre les deux, ce qui va à l'encontre de la vision "chaque outil dans son coin, et des fichiers texte c'est bien suffisant comme API").

Zerosquare (./3618) :
ça me semble absurde de réinventer un compilateur dans l'IDE.

Quand c'est évitable, certainement ^^

Je pense que maintenant tout le monde utilise CLang, mais ça devait être plus difficile avant

Zero: c'est ce que fait clang, il est incluable en tant qu'analyseur static du code

https://clang-analyzer.llvm.org

Les IDE qui utilise clang ne font pas de la bidouille a faire leur propre interpreteur/compilateur C, car ce que propose clang la est bel est bien officiel et utilise les meme briques que le compilateur stand alone.

En fait inclure clang dans l'IDE permet en theorie de compiler directement pendant la frappe du code (ce que XCode se targue de faire dans certaines circonstances)

Je ne connaissais pas

L'arrivée de CLang a quand même donné un sacré coup de fouet aux monde des compilateurs C, j'ai l'impression.

Ha oui, en fait un énorme meme, pour paraphraser un des CEO la boite qui sponsorise le plus Clang/LLVM:

- It's Amazing!
- This is a revolution!

Clang est tellement bon que microsoft se bat avec son propre code pour l'integrer a visual studio

Nhutesque ? Notez la province d'origine ^^

Déjà posté

(c'était une campagne de prévention du suicide, à l'intérieur de la boîte il y avait un dépliant avec le numéro d'appel de la hotline, et un Kit Kat)

"tu peux doublé" (sic!)?! L'auteur de l'image aurait besoin d'un comprimé Apprendsàconjuguer.

(j'aurais mis un Mars)

Merci pour ta contribution, Kevin. Tu noteras tout de même qu'il n'a pas écrit "tu peux doublé" donc tout n'est pas perdu.

C'est Brunniesque et musical à la fois :
http://whitneymusicbox.org/index.php?var=v17