Sauf que les invariants "faciles", ceux qui sont détectés à notre place, sont rarement ceux qui posent problème.
J'entends souvent cet argument mais il ne coïncide pas avec mon expérience personnelle de développement, soit dans des langages statiques soit dans des langages dynamiques. Dans un langage statique, le typeur repère très souvent des erreurs dans mon code, et dans un langage dynamique je passe parfois du temps à comprendre et corriger qui auraient été repérées par un système de types -- dernier exemple en date, manipuler dans RoR une donnée que je pensais correspondre à un modèle, mais dont certains champs n'avaient pas été chargés par une couche intermédiaire, et qui n'avait donc, moralement, pas le type attendu.
Il y a de temps en temps des expériences où on lance des outils d'analyse statique (~typage) sur des programmes écrits dans un langage dynamique (ou au système de typage faiblard, genre C), et on trouve pas mal de bugs. Dans le cas de Dialyzer que j'ai cité plus haut (pour Erlang), il y a par exemple cet article où les développeurs de l'outil l'ont lancé sur une codebase et trouvé plein d'erreurs subtiles, et de cas où les invariants mis dans les commentaires étaient devenu incorrects/périmés avec l'évolution du logiciel : Gradual Typing of Erlang Programs: A Wrangler Experience (pdf), Konstantinos Sagonas et Daniel Luna, 2008.
Après je suis bien conscient que ça dépend des développeurs (par exemple Daniel J. Bernstein a des méthodes secrètes de ninja pour écrire du code juste à la première publication), et des domaines applicatifs (la remarque de BB ci-dessous sur le fait que le code numérique se prête moins au typage est très juste). Est-ce que tu as un lien vers un répertoire versionné d'un de tes logiciels écrits dans un langage non statiquement typé, qui permettrait de vérifier ton idée sur un projet réel. L'idée est de regarder les bugfixes et de voir dans quel cas un système de types plus puissant aurait repéré l'erreur; bien sûr ça ne rend pas compte des erreurs pendant la phase de développement entre deux commits, qui jouent pourtant un rôle important dans le temps total de programmation -- je pense qu'une erreur détectée tout de suite par le typeur est en général plus facile, ou en tout cas plus rapide, à corriger qu'une erreur détectée par un test qui échoue, ne serait-ce que parce qu'il indique précisément la position du problème, plus que même des tests unitaires.
[^] # Re: J'aimerais
Posté par gasche . En réponse au journal Votre langage idéal ?. Évalué à 3.
J'entends souvent cet argument mais il ne coïncide pas avec mon expérience personnelle de développement, soit dans des langages statiques soit dans des langages dynamiques. Dans un langage statique, le typeur repère très souvent des erreurs dans mon code, et dans un langage dynamique je passe parfois du temps à comprendre et corriger qui auraient été repérées par un système de types -- dernier exemple en date, manipuler dans RoR une donnée que je pensais correspondre à un modèle, mais dont certains champs n'avaient pas été chargés par une couche intermédiaire, et qui n'avait donc, moralement, pas le type attendu.
Il y a de temps en temps des expériences où on lance des outils d'analyse statique (~typage) sur des programmes écrits dans un langage dynamique (ou au système de typage faiblard, genre C), et on trouve pas mal de bugs. Dans le cas de Dialyzer que j'ai cité plus haut (pour Erlang), il y a par exemple cet article où les développeurs de l'outil l'ont lancé sur une codebase et trouvé plein d'erreurs subtiles, et de cas où les invariants mis dans les commentaires étaient devenu incorrects/périmés avec l'évolution du logiciel :
Gradual Typing of Erlang Programs: A Wrangler Experience (pdf), Konstantinos Sagonas et Daniel Luna, 2008.
Après je suis bien conscient que ça dépend des développeurs (par exemple Daniel J. Bernstein a des méthodes secrètes de ninja pour écrire du code juste à la première publication), et des domaines applicatifs (la remarque de BB ci-dessous sur le fait que le code numérique se prête moins au typage est très juste). Est-ce que tu as un lien vers un répertoire versionné d'un de tes logiciels écrits dans un langage non statiquement typé, qui permettrait de vérifier ton idée sur un projet réel. L'idée est de regarder les bugfixes et de voir dans quel cas un système de types plus puissant aurait repéré l'erreur; bien sûr ça ne rend pas compte des erreurs pendant la phase de développement entre deux commits, qui jouent pourtant un rôle important dans le temps total de programmation -- je pense qu'une erreur détectée tout de suite par le typeur est en général plus facile, ou en tout cas plus rapide, à corriger qu'une erreur détectée par un test qui échoue, ne serait-ce que parce qu'il indique précisément la position du problème, plus que même des tests unitaires.