ce qui me gene le plus avec les languages de scripts, c'est que c'est pas compile...
[...]
Bon, je sais c'est un coup a prendre tout ca, mais quand meme la phase de compilation permet quand meme de detecter un tres grand nombre d'erreurs de facon automatique..
Il y a des prémisses à ton raisonnement qui sont discutables...
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
2) Le second est qu'un code écrit dans un langage statique contient autant ou moins de bugs qu'un code écrit dans un langage dynamique.
- D'une part, mon impression est que, les langages dynamiques étant plus expressifs que les langages statiques, ils permettent de décrire le même besoin avec moins de code, de façon plus lisible ; j'y vois plutôt (toutes choses égales par ailleurs) un gage de plus grande fiabilité.
- D'autre part, certains bugs (dans quelle proportion ? non négligeable je dirais) détectés à la compilation découlent directement du fait que le langage... requiert une compilation ! Exemple typique: dans un langage statique tu écris souvent qu'une classe C hérite d'une classe S ou implémente une interface I. Si tu as mal écrit l'identifiant de S ou I, ou que celui-ci a changé au cours du développement, tu auras une erreur à la compilation. Or, aussi gênant que ça puisse paraître quand on n'y est pas habitué, l'implémentation la plus naturelle dans un langage dynamique de cet exemple ne nécessite *pas* d'écrire S ou I... on adopte plutôt l'approche de "duck typing" (pas le temps d'expliciter mais d'un coup de google ca se trouve) --> avec un langage dynamique, de telles erreurs *n'existent pas*
3) Dernier point: l'idée, ou l'espoir, que corriger des bugs à la compilation fasse gagner du temps
=> De toutes manières, on ne peut pas se contenter de débugger lors de l'écriture du code, les tests unitaires + la phase de "recettage", de tests fonctionnels, sont indispensables. Ceci considéré, chasser 2 ou 3 bugs supplémentaires lors de la compilation ne change pas grand-chose
[1] J'y vais à la louche dans ce commentaire et ne considère que des langages "dynamiques" (python, ruby,...) contre des langages "statiques" (c++, c#, java,...).
[^] # Langages statiques/dynamiques et bugs
Posté par bobert . En réponse au journal Eclipse, Qt et GTK+ sont dans un bateau .... Évalué à 4.
ce qui me gene le plus avec les languages de scripts, c'est que c'est pas compile...
[...]
Bon, je sais c'est un coup a prendre tout ca, mais quand meme la phase de compilation permet quand meme de detecter un tres grand nombre d'erreurs de facon automatique..
Il y a des prémisses à ton raisonnement qui sont discutables...
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
2) Le second est qu'un code écrit dans un langage statique contient autant ou moins de bugs qu'un code écrit dans un langage dynamique.
- D'une part, mon impression est que, les langages dynamiques étant plus expressifs que les langages statiques, ils permettent de décrire le même besoin avec moins de code, de façon plus lisible ; j'y vois plutôt (toutes choses égales par ailleurs) un gage de plus grande fiabilité.
- D'autre part, certains bugs (dans quelle proportion ? non négligeable je dirais) détectés à la compilation découlent directement du fait que le langage... requiert une compilation ! Exemple typique: dans un langage statique tu écris souvent qu'une classe C hérite d'une classe S ou implémente une interface I. Si tu as mal écrit l'identifiant de S ou I, ou que celui-ci a changé au cours du développement, tu auras une erreur à la compilation. Or, aussi gênant que ça puisse paraître quand on n'y est pas habitué, l'implémentation la plus naturelle dans un langage dynamique de cet exemple ne nécessite *pas* d'écrire S ou I... on adopte plutôt l'approche de "duck typing" (pas le temps d'expliciter mais d'un coup de google ca se trouve) --> avec un langage dynamique, de telles erreurs *n'existent pas*
3) Dernier point: l'idée, ou l'espoir, que corriger des bugs à la compilation fasse gagner du temps
=> De toutes manières, on ne peut pas se contenter de débugger lors de l'écriture du code, les tests unitaires + la phase de "recettage", de tests fonctionnels, sont indispensables. Ceci considéré, chasser 2 ou 3 bugs supplémentaires lors de la compilation ne change pas grand-chose
[1] J'y vais à la louche dans ce commentaire et ne considère que des langages "dynamiques" (python, ruby,...) contre des langages "statiques" (c++, c#, java,...).