it-swarm-eu.dev

Dynamisch vs Statisch typisierte Sprachstudien

Gibt es Studien zur Wirksamkeit statisch oder dynamisch typisierter Sprachen?

Bestimmtes:

  • Messungen der Programmiererproduktivität
  • Fehlerrate

Einschließlich der Auswirkungen, ob Unit-Tests angewendet werden oder nicht.

Ich habe viele Diskussionen über die Vorzüge beider Seiten gesehen, aber ich frage mich, ob jemand eine Studie darüber durchgeführt hat.

71
Winston Ewert

Einige schlugen vor zu lesen:

Nicht genau auf statische Typisierung, aber verwandt:

Einige interessante Artikel oder Aufsätze zum Thema oder zur statischen Analyse von Programmen im Allgemeinen:

Und für diejenigen, die sich fragen würden, worum es geht:

Ich bezweifle jedoch, dass eine dieser Fragen Ihnen eine direkte Antwort gibt, da sie nicht genau die Studie durchführen, nach der Sie suchen. Sie werden jedoch interessante Lektüren sein.

Persönlich bin ich der festen Überzeugung, dass statisches Tippen über dynamisches Tippen die Fehlererkennung erleichtert. Ich verbringe viel zu viel Zeit damit, nach Tippfehlern und kleinen Fehlern wie diesen in JavaScript oder sogar Ruby Code zu suchen. Und wenn es um die Ansicht geht, dass Dynamic Typing die Produktivität steigert, kommt es meiner Meinung nach hauptsächlich auf Werkzeuge an. Wenn statisch typisierte Sprachen über die richtigen Tools verfügen, um eine Neukompilierung des Hintergrunds zu ermöglichen und eine REPL -Schnittstelle bereitzustellen, profitieren Sie von den Vorteilen beider Welten. Scala bietet dies zum Beispiel, was das Lernen und Prototypen in der interaktiven Konsole sehr einfach macht, Ihnen jedoch die Vorteile der statischen Typisierung (und eines stärkeren Typsystems als viele andere Sprachen, ML) bietet -Sprachen beiseite). Ebenso glaube ich nicht, dass ich durch die Verwendung von Java oder C++ (aufgrund der statischen Typisierung) einen Produktivitätsverlust habe, solange ich ein IDE verwende, das mir weiterhilft. Wenn ich nur mit einfachen Konfigurationen (Editor + Compiler/Interpreter) zum Codieren zurückkehre, fühlt es sich umständlicher an und dynamische Sprachen scheinen einfacher zu verwenden zu sein. Aber Sie suchen immer noch nach Fehlern. Ich denke, die Leute würden sagen, dass das Tooling-Problem ein umkehrbares Argument ist, als ob Tooling für dynamische Sprachen besser wäre, dann würden die meisten Fehler und Tippfehler zum Zeitpunkt der Codierung aufgezeigt, aber das spiegelt meiner Meinung nach den Fehler im System wider. Trotzdem mache ich normalerweise Prototypen in JRuby und werde später die meisten Dinge, die ich tue, in Java codieren.

WARNUNG: Einige dieser Links sind unzuverlässig, andere gehen über Portale verschiedener Computergesellschaften und verwenden kostenpflichtige Zugriffe für Mitglieder. Tut mir leid, ich habe versucht, mehrere Links für jeden dieser Links zu finden, aber es ist nicht so gut, wie ich es gerne hätte.

43
haylem

Erst gestern habe ich diese Studie gefunden: nit-Tests reichen nicht aus. Sie müssen auch statisch tippen.

Grundsätzlich verwendete der Autor ein Tool, mit dem ein Projekt automatisch von einer nicht statischen Schreibsprache in eine statische Schreibsprache konvertiert werden kann (Python zu Haskell).

Dann wählte er eine Reihe von Open Source-Projekten aus Python], die auch eine angemessene Anzahl von Testeinheiten enthielten, und konvertierte sie automatisch in Haskell.

Die Übersetzung nach Haskell ergab eine Reihe von Fehlern in Bezug auf die Art der Variablen: Die Fehler wurden von den Testeinheiten nicht entdeckt.

19
PBrando
  • Link zur Diskussion des ACM-Papiers " Ein Experiment über statische und dynamische Typsysteme " (2010) von Stephan Hanenberg (Artikel, auf den Lorin Hochstein in einem früheren Beitrag verwiesen hat).
  • Schlussfolgerung: Die Produktivität bei ähnlicher Qualität war in einer dynamischen Sprache höher.
  • Mögliche Verzerrungen/Validitätsprobleme: Die Versuchspersonen waren alle Studenten. Auch begrenzte Vielfalt der Programmieraufgaben (die Probanden wurden gebeten, einen Scanner und einen Parser zu implementieren).
  • ACM-Artikel " Beeinflussen Programmiersprachen die Produktivität? " (2007) von Delorey, Knudson und Chun.
  • Fazit: JavaScript, Tcl, Perl sind produktiver als C # C++ und Java. Python und PHP fallen in die Mitte.
  • Mögliche Verzerrungen/Gültigkeitsprobleme: Kein Qualitätsmaßstab (z. B. nach der Veröffentlichung entdeckte Fehler). Kein Maß an Zuverlässigkeit (ist Software, die in statisch typisierten Sprachen geschrieben ist, zuverlässiger?). Beispielbias - Alle Projekte wurden offen aus Open-Source-CVS-Repositories entnommen. Auch keine Unterscheidung zwischen schwach und stark typisierten Sprachen (d. H. Zeigern).
  • These " Empirische Untersuchung von Softwareproduktivität und -qualität " (2008) von Michael F. Siok
  • Schlussfolgerung: Die Wahl der Programmiersprache hat keinen wesentlichen Einfluss auf Produktivität oder Qualität. Dies wirkt sich jedoch auf die Arbeitskosten und die "Qualität des gesamten Softwareprojektportfolios" aus.
  • Mögliche Verzerrungen/Gültigkeitsprobleme: Beschränkt auf den Bereich Avionik. Programmiersprachen könnten alle statisch typisiert worden sein. Ich habe die These nicht gelesen, daher kann ich ihre Genauigkeit nicht bewerten.
    Meine Meinung. Obwohl es schwache Beweise dafür gibt, dass dynamisch typisierte Sprachen produktiver sind, ist dies nicht schlüssig. (1) Es gibt viele Faktoren, die nicht kontrolliert wurden, (2) es gibt zu wenige Studien, (3) es wurde wenig oder gar nicht darüber diskutiert, was eine geeignete Testmethode darstellt.
10
ahoffer

Hier ist ein Ausgangspunkt:

Das Papier stellt die allgemein verbreitete Weisheit in Frage, dass Programmierer bei sonst gleichen Bedingungen unabhängig von der Sprache die gleiche Anzahl von Codezeilen pro Zeit schreiben. Mit anderen Worten, das Papier sollte als empirischer Beweis dafür dienen, dass die mechanische Produktivität (geschriebene Codezeilen) kein gutes Maß für die funktionale Produktivität ist und sein muss zumindest durch die Sprache normalisiert werden.

6
Pi Delport

Ich habe eine statische vs. dynamische Sprachen: eine Literaturübersicht gefunden, die einige Studien zu diesem Thema auflistet und eine schöne Zusammenfassung zu jeder Studie gibt.

Hier ist die Zusammenfassung:

Von den kontrollierten Experimenten zeigen nur drei einen Effekt, der groß genug ist, um eine praktische Bedeutung zu haben. Die Prechelt-Studie zum Vergleich von C, C++, Java, Perl, Python, Rexx und Tcl; Die Endrikat-Studie vergleicht Java und Dart; und Cooleys Experiment mit VHDL und Verilog. Leider haben 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, die das Problem illustrierte, indem sie Lispers aufforderte, ihre eigenen Lösungen für das Problem zu finden, bei denen Leute wie Darius Bacon mit zufälligen Studenten verglichen wurden. 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 glaubten, dass statisches Tippen einen Unterschied machen würde, und sie zogen ihre Probanden aus einer Population, in der jeder Unterricht in der statisch typisierten Sprache genommen hatte. Sie kommentieren nicht, ob die Schüler Erfahrung mit der dynamisch getippten Sprache hatten oder nicht, aber es scheint sicher zu sein, dass die meisten oder alle weniger Erfahrung mit 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. Es scheint zwar verdammt, dass keiner der VHDL-Teilnehmer (statische Sprache) die Aufgabe rechtzeitig erledigen konnte, aber es ist äußerst ungewöhnlich, ein Hardware-Design in 1,5 Stunden irgendwo 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 es mit VHDL Fixkosten gibt, die sich über viele Aufgaben amortisieren lassen.

Was den Rest der Experimente betrifft, so ist die wichtigste Erkenntnis, die ich daraus ziehen kann, dass unter den in den Studien beschriebenen spezifischen Umständen jeder Effekt, wenn überhaupt, gering ist.

Wenn wir zu den Fallstudien übergehen, sind die beiden Fallstudien zur Fehlersuche interessant zu lesen, aber sie sprechen nicht wirklich für oder gegen Typen. Eine zeigt, dass beim Transkribieren von Python -Programmen nach Haskell eine Anzahl von Fehlern mit unbekanntem Schweregrad ungleich Null gefunden wird, die möglicherweise nicht durch Unit-Tests gefunden werden, die sich an der Zeilenabdeckung orientieren. Das Paar Erlang-Papiere zeigt dies Mithilfe der statischen Analyse können Sie einige Fehler finden, die durch Tests, von denen einige schwerwiegend sind, nur schwer zu finden sind.

Als Benutzer finde ich es praktisch, wenn mein Compiler mir einen Fehler gibt, bevor ich separate statische Analysetools ausführe. Dies ist 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 verglichen und sich schließlich für Ocaml entschieden hat) als eines der interessanteren Dinge, auf die ich gestoßen bin, aber es ist die Art von subjektiver Sache, die jeder machen wird anders interpretieren, was man sehen kann.

Dies passt zu dem Eindruck, den ich habe (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 bei der Lösung von Problemen in der Industrie mehr Automatisierung bevorzugen), 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 getan hat, um die Ursache zu bestimmen (z. B. eine geeignete instrumentelle Variable zu finden), also messen sie nur Korrelationen. Einige der Korrelationen sind unerwartet, aber es gibt nicht genügend Informationen, um festzustellen, warum.

Die einzige Data-Mining-Studie, die Daten präsentiert, die ohne weitere Untersuchung möglicherweise interessant sind, ist Smallshires Überprüfung von Python Bugs, aber es gibt nicht genügend Informationen zur Methodik, um herauszufinden, was seine Studie wirklich bedeutet, und Es ist nicht klar, warum er angedeutet hat, Daten für andere Sprachen zu betrachten, ohne die Daten zu präsentieren3.

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 allem befassen, was sich einem bedeutenden Projekt nähert (an Orten, an denen ich gearbeitet habe, würde ein dreimonatiges Projekt durchgeführt als klein angesehen werden, aber das sind mehrere Größenordnungen 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 Mainstream-IDEs (wie VS und Eclipse) und verwenden Sie moderne radikale IDEs (wie LightTable), Verwenden von Editoren der alten Schule (wie Emacs und vim), Wartung einer nicht trivialen Codebasis, Wartung mit einer realistischen Umgebung, Wartung einer bereits bekannten Codebasis usw.

Wenn Sie sich den Internetkommentar zu diesen Studien ansehen, werden die meisten von ihnen herumgereicht, um den einen oder anderen Standpunkt zu rechtfertigen. Die Prechelt-Studie zu Dynamik und Statik sowie die Follow-ups zu LISP sind mehrjährige Favoriten der Befürworter dynamischer Sprachen, und die Github-Mining-Studie ist in letzter Zeit unter funktionalen Programmierern zum Trend geworden.

1
Mr.WorshipMe

Hier sind ein paar:

  • Stefan Hanenberg. 2010. Ein Experiment über statische und dynamische Typsysteme: Zweifel an den positiven Auswirkungen statischer Typsysteme auf die Entwicklungszeit. In Proceedings der internationalen ACM-Konferenz über objektorientierte Programmiersystemsprachen und -anwendungen (OOPSLA '10). ACM, New York, NY, USA, 22-35. DOI = 10.1145/1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey, Charles D. Knutson und Scott Chun, "Beeinflussen Programmiersprachen die Produktivität? Eine Fallstudie unter Verwendung von Daten aus Open Source-Projekten", floss, S. 8, Erster internationaler Workshop zu neuen Trends in der FLOSS-Forschung und -Entwicklung (FLOSS) '07: ICSE Workshops 2007), 2007

  • Daly, M.; Sazawal, V., Foster, J.: Work in Progress: Eine empirische Studie zur statischen Typisierung in Ruby, Workshop zur Evaluierung und Verwendbarkeit von Programmiersprachen und -werkzeugen (PLATEAU) auf der ON-WARD 2009.

  • Lutz Prechelt und Walter F. Tichy. 1998. Ein kontrolliertes Experiment zur Bewertung der Vorteile der Überprüfung des Verfahrensargumenttyps. IEEE Trans. Softw. Eng. 24, 4 (April 1998), 302-312. DOI = 10.1109/32.677186 http://dx.doi.org/10.1109/32.677186

0
Lorin Hochstein

Ich glaube ehrlich gesagt nicht, dass statisches oder dynamisches Tippen die eigentliche Frage ist.

Ich denke, dass es zwei Parameter gibt, die zuerst kommen sollten:

  • das Fachwissen in der Sprache: Je erfahrener Sie sind, desto mehr wissen Sie über die "Fallstricke" und desto wahrscheinlicher ist es, dass Sie sie vermeiden/leicht aufspüren. Dies gilt auch für die jeweilige Anwendung/das jeweilige Programm, an dem Sie arbeiten
  • testen: Ich liebe statisches Tippen (verdammt, ich programmiere gerne in C++: p), aber es gibt so viel, was ein Compiler/statischer Analysator für Sie tun kann. Es ist einfach unmöglich, sich auf ein Programm zu verlassen, ohne es getestet zu haben. Und ich bin alles für Fuzzy-Tests (falls zutreffend), weil Sie einfach nicht über alle möglichen Eingabekombinationen nachdenken können.

Wenn Sie mit der Sprache vertraut sind, schreiben Sie Code und können Fehler mühelos aufspüren.

Wenn Sie entkoppelten Code schreiben und jede Funktionalität ausgiebig testen, erstellen Sie einen ausgefeilten Code und sind somit produktiv (weil Sie sich nicht als produktiv qualifizieren können, wenn Sie die Qualität des Produkts nicht beurteilen, oder? )

Ich würde daher der Meinung sein, dass die statische und dynamische Debatte in Bezug auf die Produktivität ziemlich strittig ist oder zumindest durch andere Überlegungen weitgehend ersetzt wird.

0
Matthieu M.