1) Le premier est que dans ton esprit tu limites l'usage des langages dynamiques [1] aux seuls scripts alors qu'ils sont de facto des langages permettant de réaliser des applications des pieds à la tête
j'entends bien, je saisi tout a fait la difference, et je sais pertinemment que de grosses applis sont ecrites avec ces langages dit "de script".
avec un langage dynamique, de telles erreurs *n'existent pas*
Disons plutot qu'elles peuvent ne pas exister.
Et quand aux erreurs de typages, elles peuvent toujours exister (t'as beau avoir un langage dynamique si t'affecte des types incompatibles, tu vas avoir un probleme).
Itou pour les declarations implicites de variables.
Et celles la elles peuvent etre particulierement chiantes a detecter en runtime.
Quand tu code un plugin ou equivalent, effectivement t'es bien oblige de pouvoir etendre une classe qui n'existe pas dans ton environnement de dev.
Quoique t'es quand meme oblige d'avoir un minimum de spec dessus, au minimum l'interface de la classe etendue, donc en quoi est ce utile ? (c'est une vraie question, je connais assez peu ces langages..)
Cela dit, ya pas mal de cas ou tu ne veux pas deriver une classe inexistante et ou tu aimerais bien pouvoir le verifier en compilant ton code pour t'en assurer, plutot que de rechercher la faute de frappe malencontreuse pendant des heures.
Disons que la compilation permet de blinder un peu plus l'appli de facon automatique.
En fait, j'ai mal formule l'histoire de compilation, sans forcement compiler au sens strict, le fait de pouvoir valider le typage serait un plus notoire je pense.
Sinon pour reagir a ton [1], contrairement a ce que tu dit, Java est dynamique, tu peux charger une classe en runtime, appeler des methodes dynamiquement dessus etc., je m'en sert d'ailleurs enormement au taff en ce moment.
Evidmment, pas possible de compiler une classe derivant une autre sans la classe mere, vu qu'il faut generer du byte code.
[^] # Re: Langages statiques/dynamiques et bugs
Posté par serge_kara . En réponse au journal Eclipse, Qt et GTK+ sont dans un bateau .... Évalué à 2.
j'entends bien, je saisi tout a fait la difference, et je sais pertinemment que de grosses applis sont ecrites avec ces langages dit "de script".
avec un langage dynamique, de telles erreurs *n'existent pas*
Disons plutot qu'elles peuvent ne pas exister.
Et quand aux erreurs de typages, elles peuvent toujours exister (t'as beau avoir un langage dynamique si t'affecte des types incompatibles, tu vas avoir un probleme).
Itou pour les declarations implicites de variables.
Et celles la elles peuvent etre particulierement chiantes a detecter en runtime.
Quand tu code un plugin ou equivalent, effectivement t'es bien oblige de pouvoir etendre une classe qui n'existe pas dans ton environnement de dev.
Quoique t'es quand meme oblige d'avoir un minimum de spec dessus, au minimum l'interface de la classe etendue, donc en quoi est ce utile ? (c'est une vraie question, je connais assez peu ces langages..)
Cela dit, ya pas mal de cas ou tu ne veux pas deriver une classe inexistante et ou tu aimerais bien pouvoir le verifier en compilant ton code pour t'en assurer, plutot que de rechercher la faute de frappe malencontreuse pendant des heures.
Disons que la compilation permet de blinder un peu plus l'appli de facon automatique.
En fait, j'ai mal formule l'histoire de compilation, sans forcement compiler au sens strict, le fait de pouvoir valider le typage serait un plus notoire je pense.
Sinon pour reagir a ton [1], contrairement a ce que tu dit, Java est dynamique, tu peux charger une classe en runtime, appeler des methodes dynamiquement dessus etc., je m'en sert d'ailleurs enormement au taff en ce moment.
Evidmment, pas possible de compiler une classe derivant une autre sans la classe mere, vu qu'il faut generer du byte code.