Parmi les expériences contrôlées, seules trois montrent un effet suffisamment important pour avoir une signification pratique. L'étude Prechelt comparant C, C ++, Java, Perl, Python, Rexx et Tcl; l'étude Endrikat comparant Java et Dart; et l'expérience de Cooley avec VHDL et Verilog. Malheureusement, ils ont tous des problèmes qui font qu’il est difficile de tirer une conclusion vraiment solide.
Dans l'étude de Prechelt, les populations étaient différentes entre les langages dynamiques et les langages typés, et les conditions pour les tâches étaient également différentes. Une étude de suivi a illustré le problème en invitant les lispers à proposer leurs propres solutions au problème, en comparant des personnes comme Darius Bacon à des étudiants de premier cycle au hasard. Un suivi du suivi consiste littéralement à comparer le code de Peter Norvig au code d’étudiants au hasard.
Dans l'étude Endrikat, ils ont spécifiquement choisi une tâche pour laquelle ils pensaient que le typage statique ferait une différence et ils ont tiré leurs sujets d'une population où tout le monde avait suivi des cours en utilisant le langage à typage statique. Ils ne précisent pas si les étudiants avaient ou non une expérience du langage à typage dynamique, mais il semble raisonnable de supposer que la plupart ou tous avaient moins d'expérience dans le langage à typage dynamique.
L’expérience de Cooley a été l’une des rares à attirer des membres d’une population non-étudiante, ce qui est formidable. Mais, comme avec toutes les autres expériences, la tâche était une tâche de jouet triviale. Bien qu'il semble accablant qu'aucun des participants au langage VHDL (langage statique) n'ait été en mesure de terminer la tâche à temps, il est extrêmement inhabituel de vouloir terminer une conception matérielle en une heure et demie ailleurs qu'en dehors d'un projet d'école. Vous pourriez faire valoir qu'une tâche importante peut être décomposée en plusieurs tâches plus petites, mais un contre-argument plausible est qu'il existe des coûts fixes utilisant le VHDL qui peuvent être amortis pour de nombreuses tâches.
Pour ce qui est du reste des expériences, la principale conclusion que j’en tire est que, dans l’ensemble des circonstances décrites dans les études, tout effet, s’il existe, est faible.
Passons maintenant aux études de cas. Les deux études de cas pour la recherche de bogues sont une lecture intéressante, mais elles ne justifient pas vraiment les types. L'un d'eux montre que la transcription de programmes Python en Haskell trouvera un nombre non nul de bogues de gravité inconnue qui pourraient ne pas être détectés lors de tests unitaires orientés couverture de ligne. La paire de papiers Erlang montre qu'il est possible de détecter certains bugs difficiles à détecter à l'aide de tests, dont certains sont graves, à l'aide d'une analyse statique.
En tant qu'utilisateur, je trouve cela pratique lorsque mon compilateur me donne une erreur avant d'exécuter des outils d'analyse statiques distincts, mais il s'agit d'une erreur mineure, peut-être même inférieure à la taille de l'effet des études contrôlées répertoriées ci-dessus.
L’étude de cas 0install (qui comparait différentes langues à Python et a finalement opté pour Ocaml) est une des choses les plus intéressantes que j’ai rencontrées, mais c’est le genre de chose subjective que tout le monde interprétera différemment, ce que vous pouvez voir en regardant .
Cela correspond à l’impression que j’ai (dans mon petit coin du monde, ACL2, Isabelle / HOL et PVS sont les prouveurs les plus couramment utilisés, et il est logique que les gens préfèrent plus d’automatisation lorsqu’ils résolvent des problèmes dans l’industrie). aussi subjectif.
Et puis, il y a les études qui extraient des données de projets existants. Malheureusement, je ne pouvais trouver personne qui fît quoi que ce soit pour déterminer le lien de causalité (par exemple, trouver une variable instrumentale appropriée), alors ils ne mesuraient que les corrélations. Certaines corrélations sont inattendues, mais il n’ya pas assez d’informations pour déterminer pourquoi.
La seule étude d'exploration de données qui présente des données potentiellement intéressantes sans exploration supplémentaire est l'examen de Smallshire sur les bogues Python, mais il n'y a pas suffisamment d'informations sur la méthodologie pour comprendre ce que son étude signifie réellement, et on ne voit pas pourquoi il a laissé entendre données pour d'autres langues sans présenter les données3.
Certaines des omissions notables des études sont des études approfondies utilisant des programmeurs expérimentés, sans parler des études qui ont une population importante de «bons» ou de «mauvais» programmeurs, qui examinent tout ce qui approche un projet important (là où j'ai travaillé, un projet de trois mois considérés comme petits, mais de plusieurs ordres de grandeur plus grands que tout projet utilisé dans une étude contrôlée), en utilisant des langages «modernes» à typage statique, en utilisant un typage progressif / facultatif, en utilisant des IDE classiques modernes (comme VS et Eclipse), en utilisant des IDE modernes radicales (comme LightTable), utiliser les éditeurs de la vieille école (comme Emacs et vim), effectuer la maintenance sur une base de code non triviale, effectuer la maintenance dans un environnement réaliste, effectuer la maintenance sur une base de code déjà connue, etc.
Si vous consultez les commentaires Internet de ces études, la plupart d’entre elles sont diffusées pour justifier un point de vue ou un autre. L’étude Prechelt sur les dynamiques et les statiques, ainsi que les suivis sur Lisp sont les favoris de longue date des défenseurs des langues dynamiques, et l’étude sur l’exploitation de github est récemment devenue à la mode parmi les programmeurs fonctionnels.