Et à moi, ça m'inspire que c'est un exemple typique de situation où on attend trop de la phase de compilation. Lorsqu'un code "statique" compile correctement, on a tendance (c'est aussi mon cas) à se dire, OK, tout va bien, je ne dois pas avoir fait d'erreurs. Mais malheureusement:
1) un compilateur ne pourra jamais trouver tous les bugs
2) ça relève d'une approche que j'appellerai ici, par provocation, "roulette russe" : on exécute son application compilée. En cas de bug, on corrige, et dans le cas contraire, confiant, on embraye sur une nouvelle fonctionnalité à implémenter. Or à cette étape, le code écrit est loin d'être fiable. Une approche beaucoup plus saine consiste à écrire les tests unitaires, en d'autres termes le comportement auquel l'application doit obéir, avant d'écrire l'application elle-même.
Je dirais que l'étape de compilation lors de l'utilisation de code "statique", a tendance à nous bercer d'illusions sur la fiabilité du code écrit et à masquer les dangers de l'approche "roulette russe".
Si on choisit d'adopter l'approche plus saine "les tests précèdent le code", alors il me semble que les langages "statiques" n'ont pas d'avantage par rapport aux langages "dynamiques", sur ce point précis.
Inversement, je me verrais mal désormais écrire du code fiable avec un langage, qu'il soit "dynamique" ou "statique", sans adopter cette approche.
[^] # La compilation ne fait pas notre boulot...
Posté par bobert . En réponse au journal Eclipse, Qt et GTK+ sont dans un bateau .... Évalué à 3.
1) un compilateur ne pourra jamais trouver tous les bugs
2) ça relève d'une approche que j'appellerai ici, par provocation, "roulette russe" : on exécute son application compilée. En cas de bug, on corrige, et dans le cas contraire, confiant, on embraye sur une nouvelle fonctionnalité à implémenter. Or à cette étape, le code écrit est loin d'être fiable. Une approche beaucoup plus saine consiste à écrire les tests unitaires, en d'autres termes le comportement auquel l'application doit obéir, avant d'écrire l'application elle-même.
Je dirais que l'étape de compilation lors de l'utilisation de code "statique", a tendance à nous bercer d'illusions sur la fiabilité du code écrit et à masquer les dangers de l'approche "roulette russe".
Si on choisit d'adopter l'approche plus saine "les tests précèdent le code", alors il me semble que les langages "statiques" n'ont pas d'avantage par rapport aux langages "dynamiques", sur ce point précis.
Inversement, je me verrais mal désormais écrire du code fiable avec un langage, qu'il soit "dynamique" ou "statique", sans adopter cette approche.