Von den kontrollierten Experimenten zeigen nur drei einen Effekt, der groß genug ist, um irgendeine praktische Bedeutung zu haben. Die Prechelt-Studie zum Vergleich von C, C ++, Java, Perl, Python, Rexx und Tcl; die Endrikat-Studie zum Vergleich von Java und Dart; und Cooleys Experiment mit VHDL und Verilog. Leider haben sie alle Probleme, die es schwierig machen, eine wirklich starke Schlussfolgerung zu ziehen.
In der Prechelt-Studie unterschieden sich die Populationen zwischen dynamischen und typisierten Sprachen, und auch die Bedingungen für die Aufgaben waren unterschiedlich. Es gab eine Folgestudie, in der Lispers aufgefordert wurde, ihre eigenen Lösungen für das Problem zu finden. Dabei wurden Leute wie Darius Bacon mit zufälligen Studenten verglichen. Ein Follow-up zum Follow-up beinhaltet buchstäblich den Vergleich von Code von Peter Norvig mit Code von zufälligen College-Studenten.
In der Endrikat-Studie wählten sie speziell eine Aufgabe aus, bei der sie dachten, dass statisches Tippen einen Unterschied machen würde, und sie zogen ihre Probanden aus einer Population, in der jeder Unterricht in der statisch getippten Sprache genommen hatte. Sie äußern sich nicht dazu, ob die Schüler Erfahrung in der dynamisch getippten Sprache hatten oder nicht, aber es ist anzunehmen, dass die meisten oder alle weniger Erfahrung in der dynamisch getippten Sprache hatten.
Cooleys Experiment war eines der wenigen, das Menschen aus einer nicht-studentischen Bevölkerung anzog, was großartig ist. Aber wie bei allen anderen Experimenten war die Aufgabe eine triviale Spielzeugaufgabe. Obwohl es bedauerlich erscheint, dass keiner der VHDL-Teilnehmer (static language) in der Lage war, die Aufgabe rechtzeitig abzuschließen, ist es äußerst ungewöhnlich, ein Hardware-Design in 1,5 Stunden außerhalb eines Schulprojekts fertigstellen zu wollen. Sie könnten argumentieren, dass eine große Aufgabe in viele kleinere Aufgaben unterteilt werden kann, aber ein plausibles Gegenargument ist, dass mit VHDL feste Kosten verbunden sind, die sich über viele Aufgaben amortisieren lassen.
Was den Rest der Experimente betrifft, so ist die wichtigste Erkenntnis, dass unter den in den Studien beschriebenen spezifischen Umständen jeder Effekt, falls überhaupt, gering ist.
Wenn wir zu den Fallstudien übergehen, bieten die beiden Fallstudien zur Fehlersuche eine interessante Lektüre, aber sie sprechen nicht wirklich für oder gegen Typen. Einer zeigt, dass beim Transkribieren von Python-Programmen nach Haskell eine Anzahl von Fehlern mit unbekanntem Schweregrad ungleich Null gefunden wird, die durch Unit-Tests mit Ausrichtung auf die Zeilenabdeckung möglicherweise nicht gefunden werden. Das Erlang-Artikelpaar zeigt, dass Sie anhand statischer Analysen einige Fehler finden können, die bei Tests, von denen einige schwerwiegend sind, nur schwer zu finden sind.
Als Benutzer finde ich es praktisch, wenn mein Compiler mir eine Fehlermeldung ausgibt, bevor ich separate statische Analysewerkzeuge ausführe, diese sind jedoch geringfügig, möglicherweise sogar kleiner als die Effektgröße der oben aufgeführten kontrollierten Studien.
Ich fand die 0install-Fallstudie (die verschiedene Sprachen mit Python verglich und sich schließlich für Ocaml entschied) eines der interessanteren Dinge, auf die ich gestoßen bin, aber es ist eine subjektive Sache, die jeder anders interpretieren wird, was Sie sehen können, wenn Sie schauen .
Dies passt zu meinem Eindruck (in meiner kleinen Ecke der Welt sind ACL2, Isabelle / HOL und PVS die am häufigsten verwendeten Prüfer, und es ist sinnvoll, dass die Leute mehr Automatisierung bevorzugen, wenn sie Probleme in der Industrie lösen), aber das ist es auch subjektiv.
Und dann gibt es die Studien, die Daten aus bestehenden Projekten abbauen. Leider konnte ich niemanden finden, der etwas unternahm, um die Ursache zu bestimmen (z. B. eine geeignete instrumentelle Variable zu finden), so dass sie nur Korrelationen messen. Einige der Zusammenhänge sind unerwartet, aber es gibt nicht genügend Informationen, um festzustellen, warum.
Die einzige Data-Mining-Studie, die Daten präsentiert, die ohne weitere Erkundung möglicherweise interessant sind, ist Smallshires Überprüfung von Python-Fehlern, aber es gibt nicht genügend Informationen zu der Methodik, um herauszufinden, was seine Studie wirklich bedeutet, und es ist nicht klar, warum er dies angedeutet hat Daten für andere Sprachen ohne Vorlage der Daten3.
Einige bemerkenswerte Auslassungen in den Studien sind umfassende Studien mit erfahrenen Programmierern, geschweige denn Studien mit einer großen Anzahl von „guten“ oder „schlechten“ Programmierern, die sich mit irgendetwas befassen, was sich einem bedeutenden Projekt nähert (an Orten, an denen ich gearbeitet habe, würde ein dreimonatiges Projekt klein sein, aber das ist um ein Vielfaches größer als bei jedem Projekt, das in einer kontrollierten Studie verwendet wird. Verwenden Sie „moderne“ statisch typisierte Sprachen, verwenden Sie schrittweise / optionale Typisierung, verwenden Sie moderne Standard-IDEs (wie VS und Eclipse), verwenden Sie moderne radikale IDEs (wie LightTable), mit alten Editoren (wie Emacs und vim), Wartung in einer nicht trivialen Codebasis, Wartung in einer realistischen Umgebung, Wartung in einer Codebasis, mit der Sie bereits vertraut sind, usw.
Wenn Sie sich den Internetkommentar zu diesen Studien ansehen, werden die meisten davon weitergegeben, um die eine oder andere Sichtweise zu rechtfertigen. Die Prechelt-Studie zu Dynamisch vs. Statisch sowie die Follow-ups zu Lisp sind beständige Favoriten von Befürwortern dynamischer Sprachen, und die Github-Mining-Studie ist unter funktionalen Programmierern in letzter Zeit im Trend.