Avant même de parler de bugs ou de tests unitaires, on a déjà de très gros problèmes de productivité avec le typage dynamique.
De par sa nature même, un langage à typage dynamique interdit toute complétion automatique ou assistance à la refactorisation digne de ce nom. Cela ralenti énormément le développement.
Idem, je ne compte plus le nombre de fois où je me pose la question de ce qu'attend comme paramètre une fonction python ou ce qu'elle est sensée me retourner. Quand ce n'est pas littéralement un gros « data » tout moche, aussi bien en entrée qu'en sortie…
Développer en Python ou en Ruby, c'est passer plus de temps à regarder ce qu'a codé le voisin pour savoir comment utiliser son API que de coder son propre code.
(Et qu'on ne me parle pas de Javadoc, Doxygen, Sphinx, ou autre, je n'ai JAMAIS vu une documentation complète et correcte, et encore moins sur des API internes…)
On est à des années-lumières de la productivité d'un langage à typage statique type Java, où l'IDE va directement sortir les bons types de paramètres de la fonction, voire même y placer les variables disponibles qui correspondent (merci Eclipse !).
Enfin, la refactorisation de code est juste une hérésie en dynamiquement typé.
Comme l'IDE ne peut être d'aucune sorte d'utilité, réécrire une méthode, renommer un paramètre ou introduire du polymorphisme ou une super-classe, et on a la quasi-certitude d'une énorme régression qu'on ne détectera qu'à la prochaine exécution (loi de Murphy aidant, la probabilité que cela arrive en production avoisine les 100%…).
L'étude réalisée par Evan Farrer est intéressante, mais arrive trop tard dans la chaîne de développement.
Surtout qu'apparement, vu la popularité des librairies analysées, les bugs non détectés ne devaient pas être si méchants et fréquents que ça.
Avant de penser à corriger du bug ou à implémenter du test unitaire (quoi que TDD, tout ça tout ça, mais je vous laisse imaginer le calvaire en Python ou Ruby…), il faut déjà l'avoir écrit, le code =)
# Les tests U et les bugs c'est bien, la productivité c'est mieux (mais la conclusion reste la même)
Posté par Aeris (site web personnel) . En réponse au journal Typage statique versus typage dynamique. Évalué à 10. Dernière modification le 08 juillet 2012 à 20:00.
Avant même de parler de bugs ou de tests unitaires, on a déjà de très gros problèmes de productivité avec le typage dynamique.
De par sa nature même, un langage à typage dynamique interdit toute complétion automatique ou assistance à la refactorisation digne de ce nom. Cela ralenti énormément le développement.
Idem, je ne compte plus le nombre de fois où je me pose la question de ce qu'attend comme paramètre une fonction python ou ce qu'elle est sensée me retourner. Quand ce n'est pas littéralement un gros « data » tout moche, aussi bien en entrée qu'en sortie…
Développer en Python ou en Ruby, c'est passer plus de temps à regarder ce qu'a codé le voisin pour savoir comment utiliser son API que de coder son propre code.
(Et qu'on ne me parle pas de Javadoc, Doxygen, Sphinx, ou autre, je n'ai JAMAIS vu une documentation complète et correcte, et encore moins sur des API internes…)
On est à des années-lumières de la productivité d'un langage à typage statique type Java, où l'IDE va directement sortir les bons types de paramètres de la fonction, voire même y placer les variables disponibles qui correspondent (merci Eclipse !).
Enfin, la refactorisation de code est juste une hérésie en dynamiquement typé.
Comme l'IDE ne peut être d'aucune sorte d'utilité, réécrire une méthode, renommer un paramètre ou introduire du polymorphisme ou une super-classe, et on a la quasi-certitude d'une énorme régression qu'on ne détectera qu'à la prochaine exécution (loi de Murphy aidant, la probabilité que cela arrive en production avoisine les 100%…).
L'étude réalisée par Evan Farrer est intéressante, mais arrive trop tard dans la chaîne de développement.
Surtout qu'apparement, vu la popularité des librairies analysées, les bugs non détectés ne devaient pas être si méchants et fréquents que ça.
Avant de penser à corriger du bug ou à implémenter du test unitaire (quoi que TDD, tout ça tout ça, mais je vous laisse imaginer le calvaire en Python ou Ruby…), il faut déjà l'avoir écrit, le code =)