Les tests unitaires remplissent la fonction de la phase de compilation, de ce point de vue (tout en allant beaucoup plus loin car les tests ne se limitent pas à vérifier que les types conviennent).
Mouais, je pense que c'est bien, les tests unitaires, mais c'est un peu optimiste de penser qu'il y en a systématiquement et qu'ils couvrent tous les bouts du code :) (Surtout que pour les applis graphiques qui demandent une interaction avec l'utilisateur, je trouve pas évident de faire des tests unitaires)
Quant à la "greppabilité" du code, c'est plus une question de style objet (namespaces imbriqués, avec des noms souvent réutilisés) vs. style procédural (tout à plat, avec des noms très distinctifs). On peut très bien n'utiliser que des fonctions globales en Python.
C'est pas juste une question de style objet et de greppabilité : en Java t'as aussi de l'objet, mais si tu refactores une méthode, t'as la compilation qui va t'envoyer bouler s'il y a un endroit où tu n'as pas modifié l'appel (et, j'imagine, des IDE qui permettent de faire ça automatiquement). C'est la combinaison "objet" et "dynamique" qui rend ça embêtant, parce que si t'oublies un appel dans une fonction obscure qui ne se lance pas tout le temps, tu (ou un utilisateur) ne t'en rendras compte qu'à l'exécution. (Cela dit, oui on peut éviter l'objet en python)
Cela dit, autant je pense qu'un typage statique permet de détecter pas mal d'erreurs à la compilation, autant avec un typage dynamique, certes ça plante à l'exécution, mais en général c'est des erreurs où on voit assez trivialement d'où ça vient (puisqu'il y a quand même une vérification des types, et que tu vas avoir une erreur du genre "Grrrr, tu me donnes une chaine de caractères alors que je veux un entier"). Je trouve ça moins pénible à débugger qu'en C quand t'as un pointeur sur un tableau qui n'est pas la bonne taille, et que ça ne vérifie ni à la compilation, ni à l'exécution, mais que tu te retrouves avec une segfault ou des données bizarres à un autre endroit du code.
[^] # Re: C vs Python pour des applis Gnome
Posté par Lizzie Crowdagger . En réponse au journal Quelques langages de programmation pour GNOME. Évalué à 4.
Mouais, je pense que c'est bien, les tests unitaires, mais c'est un peu optimiste de penser qu'il y en a systématiquement et qu'ils couvrent tous les bouts du code :) (Surtout que pour les applis graphiques qui demandent une interaction avec l'utilisateur, je trouve pas évident de faire des tests unitaires)
C'est pas juste une question de style objet et de greppabilité : en Java t'as aussi de l'objet, mais si tu refactores une méthode, t'as la compilation qui va t'envoyer bouler s'il y a un endroit où tu n'as pas modifié l'appel (et, j'imagine, des IDE qui permettent de faire ça automatiquement). C'est la combinaison "objet" et "dynamique" qui rend ça embêtant, parce que si t'oublies un appel dans une fonction obscure qui ne se lance pas tout le temps, tu (ou un utilisateur) ne t'en rendras compte qu'à l'exécution. (Cela dit, oui on peut éviter l'objet en python)
Cela dit, autant je pense qu'un typage statique permet de détecter pas mal d'erreurs à la compilation, autant avec un typage dynamique, certes ça plante à l'exécution, mais en général c'est des erreurs où on voit assez trivialement d'où ça vient (puisqu'il y a quand même une vérification des types, et que tu vas avoir une erreur du genre "Grrrr, tu me donnes une chaine de caractères alors que je veux un entier"). Je trouve ça moins pénible à débugger qu'en C quand t'as un pointeur sur un tableau qui n'est pas la bonne taille, et que ça ne vérifie ni à la compilation, ni à l'exécution, mais que tu te retrouves avec une segfault ou des données bizarres à un autre endroit du code.