Statisch versus dynamisch

Nachdem es im ersten Teil ausführlich um Experimentaufbau, -durchführung und -auswertung ging, beginnt nun die Umsetzung. Es wird eine Reihe von Experimenten besprochen, die von ihrem Aufbau und von der Methodik her durchaus unterschiedlich sind.Die Ergebnisse dieser Experimente sind allerdings sehr mit Vorsicht zu genießen. Sie haben aber alle stark zu einer Reifung der empirischen Forschung in der Softwaretechnik beigetragen. Dank ihrer Hilfe konnten Experimentaufbauten gefunden werden, die in neueren Experimenten dann auch zu sauber verwertbaren Ergebnissen geführt haben.Aus wissenschaftlicher Sicht ist es in der Regel sinnvoll, Experimente sehr detailliert zu besprechen. Dennoch bemühen wir uns, die Experimente und deren Ergebnisse hier möglichst stark zusammenzufassen und vereinfacht darzustellen.

Gannon (1977): Fehlerzahl und Häufigkeit der Programmdurchläufe

Erste Veröffentlichungen zu Experimenten zum Thema Benutzbarkeit von Typsystemen gab es im Jahr 1977 durch John D. Gannon [1]. Gannons Methode bestand darin, durch Experimentteilnehmer Programme erstellen zu lassen, diese Programme dann durchlaufen zu lassen und die gegebenenfalls auftretenden Fehler den Teilnehmern mitzuteilen, damit diese ihr Programm korrigieren – um dann den ganzen Prozess zu wiederholen.Gemessen wurden die Anzahl und Summe der Fehler im Quelltext, die Anzahl und Summe des Auftretens von Fehlern zur Laufzeit sowie schließlich die Anzahl an fehlerhaften Durchläufen. Wenn zum Beispiel einer Prozedur im Code siebenmal die falsche Parameterzahl übergeben wurde, wurde dies einmal als Fehlertyp in der Anzahl, aber siebenmal in der Summe der Fehler gezählt.Gannon führte das Experiment mit 38 Teilnehmern durch. Diese teilte er in zwei Gruppen und ließ eine Gruppe eine Aufgabe in einer Sprache mit, dann die gleiche Aufgabe mit einer Sprache ohne statisches Typsystem bearbeiten. Bei der anderen Gruppe lief es in umgekehrter Reihenfolge. Die Aufgabe bestand darin, eine Zeichenkette zu invertieren und
n-malig auszugeben, wobei n in der Zeichenkette selbst codiert war. Anhand der veröffentlichen Daten lassen sich die Ergebnisse nachrechnen. Kurzum: Für alle Kennzahlen stellt sich heraus, dass die Gruppe mit dem statischen Typsystem durchweg geringere Werte hat, also sowohl hinsichtlich der Anzahl (10 versus 15) und Summe der Fehler (16; 25) im Code, der Anzahl (34; 73) und Summe der Fehler (39; 111) in den Durchläufen als auch in der Anzahl der Durchläufe (10; 17).Aus heutiger Sicht noch immer innovativ sind bei diesem Vorgehen die kontrollierte Durchführung von Programmierexperimenten, die Verwendung von Crossover-Designs und die Verwendung inferenzstatistischer Methoden zur Beurteilung der Studienergebnisse.Was aus heutiger Sicht eher schwierig erscheint, ist das technische Szenario: 1977 wurden Programme auf Lochkarten gestanzt, um von Computern ausgelesen und durchgeführt zu werden: Das Gerät, auf dem man die Programme entwickelte, war entsprechend nicht das Gerät, auf dem man Programme ausführen konnte.Angesichts dessen ist es aus heutiger Sicht schwer vorstellbar, wie sich das Entwickeln angefühlt haben muss.Ein konkreter Kritikpunkt ist die Wahl der Messpunkte: Anzahl der Fehler und Häufigkeit der Durchläufe. Aus heutiger Sicht scheint die Anzahl an Fehlern kein nennenswertes Problem zu sein, wenn man überlegt, dass Syntaxfehler ebenfalls Fehler sind, aber deren Behebung in der Regel keine zeitliche Rolle spielt. Damals hingegen scheint es sinnvoll gewesen zu sein, die Anzahl an Fehlern zu zählen, wenn man den Aufwand zwischen Entwicklung und Ausführung berücksichtigt (Lochkarten).Und letztlich sind die verwendeten Programmiersprachen ein Kritikpunkt. Zum einen unterscheiden sie sich stark von heutigen Sprachen, zum anderen waren beide Sprachen hinsichtlich ihres Funktionsumfangs unterschiedlich.Es scheint daher angebracht, davon auszugehen, dass die statisch typisierte Sprache hinsichtlich ihres Funktionsumfangs angemessener war als die dynamisch typisierte – aber nicht aufgrund des Typsystems.Aus heutiger Sicht würde man sagen, dass das Experiment erste Hinweise gegeben hat, dass ein statisches Typsystem vorteilhaft ist, jedoch sind wir weit davon entfernt, von überwältigender Evidenz sprechen.

Prechelt und Tichy (1996): Entwicklungszeit und Anzahl an Fehlern

Es dauerte knapp 20 Jahre, bis ein weiteres Experiment zu Typsystemen in der Literatur auftauchte. In der Zwischenzeit nahm die Bedeutung der Objektorientierung zu: C++ hat die Vorherrschaft in der objektorientierten Programmierwelt und setzt sich gegen das dynamisch typisierte Smalltalk durch.Die statisch typisierte Programmiersprache Java steht in den Startlöchern, um bald C++ als führende Sprache abzulösen. Ferner wird Software – anders als zu Gannons Zeiten – an einem Rechner entwickelt, der die entwickelte Software auch ausführt: Auch wenn hinsichtlich der zur Verfügung stehenden IDEs Unterschiede existieren mögen, so ist diese Form der Softwareentwicklung der heutigen ähnlich.Prechelt und Tichy [2] führten ein Experiment mit 33 Teilnehmern anhand zwei sehr ähnlicher Programmiersprachen (K&R C und ANSI C) durch, die sich darin unterschieden, dass Erstere die Typen von übergebenen Parametern nicht statisch überprüft, die zweite hingegen schon. Das Wesentliche an diesem Experiment ist, dass nun neben Fehlern, die unterschiedlich kategorisiert wurden, auch die Entwicklungszeit gemessen wurde.Ferner wurde eine Reihe von Maßnahmen durchgeführt, wodurch mögliche Kritikpunkte im Vergleich zur Gannon-Studie reduziert werden sollten. Zwar folgte das Experiment weiterhin einem Crossover-Design – jeder Teilnehmer bekam sowohl die dynamisch als auch die statisch typisierte Programmiersprache im Experiment –, jedoch wurden zwei unterschiedliche Aufgaben A und B vergeben, um dem Lerneffekt entgegenzuwirken.In beiden Aufgaben musste eine grafische Oberfläche erstellt werden. Aufgabe A bestand aus dem Erzeugen einer grafischen 2 x 2-Matrix bestehend aus Textfeldern, die invertiert werden konnten, und ein Button ermöglichte das Schließen der Anwendung. In Aufgabe B sollte ein Fenster erscheinen, mit dem man eine Datei auswählen konnte. Einen Beenden-Button sollte die Anwendung ebenfalls haben.Die Ergebnisse des Experiments waren etwas ernüchternd. Ein Unterschied in der Entwicklungszeit wurde nicht gemessen. Lediglich wenn Teilnehmer eine Aufgabe zum zweiten Mal bearbeitet hatten, waren sie mit den Typchecks schneller – wenn sie vorher also eine Aufgabe ohne Typchecks gelöst hatten. Insgesamt – das heißt über beide Aufgaben hinweg – war dieser Effekt nicht messbar.Hinsichtlich der Fehler stellt sich das Ergebnis wenig homogen dar: Manche Metriken zeigten weniger Fehler bei der Sprache mit Typchecks, andere nicht.Aus Sicht der Frage des Nutzens von Typisierung lässt sich anmerken, dass die Unterschiede zwischen den verwendeten Sprachen nicht so groß waren, wie heutzutage vorzufinden, denn in beiden Sprachen wurden Typen deklariert. In K&R C wurden sie lediglich nicht für den Typcheck verwendet.Insgesamt kann man sagen, dass das Experiment ein paar Tendenzen zeigte: Wenn es messbare Vorteile gab, so lagen diese bei der Sprache mit Typcheck. Mehr konnte nicht he­rausgefunden werden, da sehr häufig keine Unterschiede gemessen wurden. Und ein Unterschied in der Entwicklungszeit hat sich wie gesagt auch nicht offenbart.

Hanenberg (2010): Anzahl an Fehlern – ohne ­Ergebnis

Es dauerte knapp 15 Jahre, bis das nächste Experiment zu Typ­systemen in der Literatur zu finden war [3]. In der Zwischenzeit hatte Java die Sprache C++ auf dem Markt abgelöst, aber seit vielen Jahren gab es den Trend zu dynamischen Programmiersprachen, angefangen mit JavaScript, PHP, Python, Ruby et cetera.Leider hilft auch dieses nächste Experiment mit 49 Teilnehmern nicht bei der Beantwortung der Frage, ob statische oder dynamische Typsysteme vorteilhaft sind.Das Experiment war stark davon beeinflusst, zwei nahezu gleiche Sprachen zu verwenden und ein möglichst objektives Kriterium dafür zu schaffen, ob Fehler vorliegen oder ob nicht. Es wurden zwei Sprachen gebaut, die sich lediglich hinsichtlich des Typsystems unterschieden. Experimentteilnehmer mussten einen Mini-Java-Parser bauen. Nach knapp 25 Stunden Arbeitszeit erfolgte die Abgabe des Parsers und es wurde getestet, wie viele Testwörter seitens des Parsers akzeptiert wurden. Knapp zusammengefasst wurde kein Unterschied gemessen.

Stuchlik, Hanenberg (2011): Typecasts erhöhen Entwicklungszeit

Das Experiment von Stuchlik und Hanenberg [4] entstand aus der Einschätzung, dass die bisherigen Aufgaben unangemessen waren, weil sie sich nicht auf die Eigenschaften beziehungsweise mögliche Probleme von Typsystemen bezogen. Da Entwickler, die für dynamische Typsysteme argumentieren, häufig Typecasts als Probleme ansprachen, schien es angemessen, ein Experiment durchzuführen, dessen Aufgaben sich auf Typecasts bezogen.Das Experiment folgte Gannons Versuchsaufbau: Teilnehmer mussten die gleichen fünf Aufgaben in einer statisch und einer dynamisch typisierten Sprache lösen. Dazu bekamen die Teilnehmer eine Anwendung, die um einzelne Methoden erweitert werden musste, deren Parameter in der statisch typisierten Sprache zwingend gecastet werden mussten, da der übergebene Typ zu generell war. Dies war entsprechend bei der dynamisch typisierten Variante nicht der Fall.Die Aufgaben waren sehr einfach, das heißt, sie konnten mit wenigen Zeilen Code gelöst werden, wobei mit steigender Aufgabennummer die Anzahl an erwarteten Casts (und erwarteter Zeilenlänge) stieg.Die Aufgaben waren jedoch nicht identisch. Stattdessen wurde das den Aufgaben zugrunde liegende Programm durch Austausch von Klassen, Methoden und Variablennamen verändert, um Lerneffekten entgegenzuwirken.Als Programmiersprachen wurden Java und Groovy verwendet, wobei Groovy den Versuchsteilnehmern nur als „eine Java-Version, in der man Typdeklarationen weglassen und durch das Schlüsselwort def ersetzen kann“ vorgestellt wurde. Siehe dazu auch Listing 1. Das heißt, es wurden keine Sprachmerkmale von Groovy verwendet, die über das Weglassen von Typdeklarationen hinausgingen.

Die Experimentteilnehmer lösten die Aufgaben ohne eine Entwicklungsumgebung (IDE), weil befürchtet wurde, dass eine IDE einen zusätzlichen Einflussfaktor darstellt, der die Experimentergebnisse beeinträchtigt.Gemessen wurde die Arbeitszeit, die benötigt wurde, um eine Reihe von Testfällen erfolgreich zu erfüllen.Das Ergebnis des Experiments, welches mit 21 Teilnehmern durchgeführt wurde, war, dass es nur für eine der fünf Aufgaben eine Art Lerneffekt gab, und dass für zwei der fünf Aufgaben ein Vorteil der dynamisch typisierten Sprache gemessen werden konnte: 400 s zu 970 s für die einfachste Aufgabe beziehungsweise 690 s zu 960 s für die dritteinfachste Aufgabe. Insbesondere konnte das Experiment keinen Unterschied zwischen den größeren Aufgaben feststellen, deren durchschnittliche Bearbeitungszeit mit einer dynamisch typisierten Sprache bei rund 1000 beziehungsweise etwa 1500 Sekunden lag.Das Experiment war dahingehend erfolgreich, dass für ­einige Aufgaben ein echter Unterschied zwischen den Typsystemen gemessen werden konnte, ohne einen Lerneffekt zu haben. Dies konnte auf die Unterschiede in der Entwicklungszeit zurückgeführt werden, welche nicht unerheblich waren. Nun könnte man geneigt sein, dieses Experiment als Beleg dafür aufzufassen, dass dynamische Typsysteme generell vorteilhaft sind. Dennoch war die Interpretation der Autoren eine andere.Ihre Interpretation war, dass sich primär der Versuchsaufbau als vorteilhaft gezeigt hat: Anzahl unterschiedlicher Aufgaben; Verwendung von Crossover-Designs, ohne identische Aufgaben zu wiederholen; Konzentration der Aufgaben auf eine besondere Eigenschaft des Typsystems.Gleichzeitig stellten sie fest, dass der Unterschied nur bei den sehr kleinen Aufgaben mit sehr wenigen Typecasts messbar war. Somit argumentierten die Autoren, dass der Unterschied zwischen statischen und dynamischen Typsystemen hinsichtlich des Auftretens von Typecasts lediglich – wenn überhaupt – bei Kleinstprogrammen auftritt und auch nur dann, wenn das Typsystem zwangläufig zu Casts führt.Aus Sicht der Autoren kann das Experiment bestenfalls als Argument herhalten, warum Shellsprachen, die dazu geschaffen wurden, Programme mit sehr wenigen Zeilen Code zu schreiben, keines statischen Typsystems bedürfen.

Mayer et al. (2012): Unterschiede bei der Verwendung von APIs

Angetrieben vom erfolgreichen Experimentaufbau und weniger von der Beantwortung der eigentlichen Frage, folgten weitere Überlegungen über den möglichen Zusammenhang von Typsystemen und Entwicklungszeit. Eine davon war, dass statische Typen möglicherweise durch die Typdeklaratio­nen einen Dokumentationsvorteil bringen.In einem ersten Experiment mit 27 Probanden wurden von Mayer et al. Aufgaben derart gestaltet, dass die Entwicklerinnen und Entwickler kleinere Methoden schreiben sollten, innerhalb derer auf ein API zugegriffen werden musste [5].Um zu sehen, ob dieser mögliche Dokumentationseffekt existiert, wurde zu diesem API keinerlei Dokumentation außer dem (unkommentierten) Quelltext gegeben.Abermals wurden Java und Groovy eingesetzt, abermals haben Entwickler Aufgaben mit und ohne Typsystem gelöst, wobei die Aufgaben wieder leicht transformiert wurden, mit dem Ziel, Lerneffekte zu vermindern.Insgesamt wurden fünf Aufgaben gestellt. In einer ersten Aufgabe musste lediglich eine Klasse instanziert werden – auf die Bearbeitungszeit hatte das Typsystem überraschend keinen Einfluss.Fortan galt es, Aufgaben wachsender Komplexität unter Nutzung des API zu lösen. Beispielsweise sollten Methoden beziehungsweise Konstruktoren aufgerufen werden, deren notwendige Parameter man sich aus dem API zusammensuchen musste.In der zweiten Aufgabe wurde für das dynamische Typsystem ein Zeitvorteil gemessen (Groovy = 954 s, Java = 1 573 s), in der vierten (Groovy = 3 027 s; Java = 1 669 s) und fünften Aufgabe (Groovy = 1 541 s; Java = 934 s) ein Vorteil für das statische Typsystem. Aufgabe drei zeigte keine Unterschiede.Die Annahme beim Experiment war, dass sich der Dokumentationsvorteil des statischen Typsystems beim Suchen von API-Elementen zeigen sollte. Jedoch stellte sich heraus, dass die Ergebnisse keinesfalls so klar waren, wie man es aus Sicht des Experimentierers gerne gehabt hätte. Das Ergebnis der zweiten Aufgabe wirkte im Gesamtkontext seltsam: schnellere Lösung mit dem dynamischen Typsystem.Was ferner in dem Experiment erstmalig als Idee auftauchte, war, dass man versuchte, eine Erklärung für den Unterschied der Zeiten bei Nutzung von statischen und dynamischen Typsystemen zu finden.Grundidee war, dass das Fehlen eines deklarierten Typs dazu führen müsste, dass Entwickler den Quelltext mühsam manuell nach etwas Passendem durchsuchen müssen.Im Experiment wurde dazu gemessen, wie häufig die Teilnehmer Klassendefinitionen geöffnet haben. Die Analyse der Häufigkeit des Öffnens von Klassendefinitionen deckte sich mit der Analyse der Entwicklungszeiten – jedoch auch in der Aufgabe, in der Groovy sich als vorteilhaft erwies.Trotzdem wähnten sich die Experimentierer auf dem richtigen Weg und entschlossen sich dazu, unter gleichen Voraus­setzungen das Experiment nochmals mit neuen Aufgaben zu entwerfen und durchzuführen. Die Annahme war, dass das Ergebnis von Aufgabe zwei eher zufällig im Sinne einer Aufgabenstellung, die zufällig die Groovy-Gruppe bevorteilt hat, zustande kam.

Kleinschmager et al. (2012): Messbare Unterschiede bei Typfehlern

Der Versuch der Experimentwiederholung von Kleinschmager et al. [6] muss aus heutiger Sicht so betrachtet werden, dass sie keine neuen Erkenntnisse brachte. Abermals zeigte eine Aufgabe einen messbaren Vorteil von Groovy zu Java, für alle anderen Aufgaben war der Lerneffekt zwischen den Aufgaben zu groß. Allerdings wurde von Kleinschmager et al. zusätzlich eine andere Aufgabe ins Spiel gebracht – eine Aufgabe, bei der die Probanden einen Typfehler beheben mussten.Während für die statisch typisierte Variante dieser Typfehler zur Kompilierzeit auftrat und innerhalb weniger Sekunden behebbar war, führte er bei der dynamisch typisierten Variante zu einem schwer nachvollziehbaren Laufzeitfehler. Bei dem Typfehler handelte es sich um einen Methodenaufruf mit vertauschter Parameterreihenfolge.Geschuldet war diese Aufgabe dem häufig angeführten Argument für dynamisch typisierte Programmierung, dass Typfehler ähnlich schnell behoben werden können wie bei statisch typisierten Programmen.Der Unterschied stellte sich jedoch als immenser Vorteil des statischen Typsystems dar: Während in der Java-Variante 147 s beziehungsweise 236 s benötigt wurden, benötigten die Groovy-Programmierer 928 s beziehungsweise 849 s.Das entspricht einem Unterschied von Faktor 6,8 beziehungsweise 3,6.Leider sind die beiden letztgenannten Arbeiten in ihren Veröffentlichungen etwas irreführend: Sie interpretieren die Ergebnisse sehr stark pro statischer Typsysteme – erst eine Neuberechnung der Ergebnisse offenbart, dass sie – abgesehen von den genannten Vorteilen beim Beheben von Typfehlern – wenig konkrete Ergebnisse vorzuweisen haben.

Ein Resümee: Gibt es keinen Unterschied?

Bis zum Jahr 2010 lagen lediglich drei Experimente zu Typsystemen vor und bis 2012 nur sechs. Im ersten konnte ein Vorteil statischer Typisierung hinsichtlich der Anzahl der Fehler nachgewiesen werden, jedoch haben wir diskutiert, dass die Anzahl der Fehler nicht für die Beurteilung herangezogen werden sollte. Ferner unterschied sich das erste Experiment von 1977 sehr stark von der heute praktizierten Softwareentwicklung.Im zweiten Experiment, in welchem unter anderem die Entwicklungszeit gemessen wurde, konnte kein Unterschied in der Zeit festgestellt werden. Das dritte Experiment ergab keine Resultate.Wenn wir uns der Interpretation der Autoren hinsichtlich des vierten genannten Experiments von Stuchlik und Hanenberg anschließen, dass nämlich der Unterschied dort nicht nennenswert ist, und wir ferner beim Experiment von Kleinschmager et al. die Aufgabe mit dem Typfehler nicht berücksichtigen, so kommen wir zum Schluss, dass diese ersten sechs Experimente eigentlich nicht zur Beantwortung der Frage beigetragen haben, ob statische Typsysteme für Entwickler von Vor- oder von Nachteil sind. Trotz großem Aufwand wurde kein echter Unterschied zwischen der Verwendung einer dynamisch typisierten oder einer statisch typisierten Sprache gefunden – und man darf sich die Frage stellen, ob es überhaupt einen solchen Unterschied gibt.Es gibt Fälle in der Wissenschaftsgeschichte, in denen immer wieder versucht wurde, den Beleg für den Nutzen einer Technik zu belegen, ohne dass es gelang. Als Beispiel sei die Homöopathie genannt, deren Nutzen seit Jahrhunderten erfolglos zu belegen versucht wird. Und wenn man sehr, sehr oft mit derartigen Versuchen gescheitert ist, ist es angemessen davon zu sprechen, dass ein solcher Nutzen wahrscheinlich nicht existiert.Eine solche Interpretation ist zwar nicht konsistent zum wissenschaftlichen Schließen, welches besagt, dass auch nicht messbare Unterschiede möglicherweise trotzdem existieren können, aber aus praktischer Sicht ist es sinnvoll, irgendwann aufzuhören und sich Dingen zu widmen, die wahrscheinlich einen nennenswerteren Einfluss haben.In unserem Fall ergibt es Sinn, sich vor Augen zu führen, dass die Situation anders ist: In der Softwaretechnik ist man nicht sehr weit mit dem Experimentieren und es gibt noch keinen großen Erfahrungsschatz von empirischer Forschung in der Softwareentwicklung, auf den man zurückgreifen könnte. Das kann bedeuten, dass die wenig aufschlussreichen Ergebnisse möglicherweise lediglich auf problematische Experimentaufbauten und -durchführungen zurückzuführen sind.Es wurden also zu diesem Zeitpunkt eventuell einfach noch nicht die richtigen Experimententwürfe gefunden, die sich für die Softwareentwicklung eignen. Ferner kann man kaum von einer Fülle an Experimenten sprechen: Über einen Zeitraum von knapp 36 Jahren wurden lediglich sechs Experimente dazu durchgeführt. Das ist nicht sehr viel. Auch lange nicht genug, um einen breiten Erfahrungsschatz aufzubauen.Glücklicherweise wurde nicht an dieser Stelle damit aufgehört, sondern es wurden Folgeexperimente durchgeführt, die klare Ergebnisse vorzuweisen haben. Man sollte somit heute eher davon sprechen, dass diese ersten Experimente nicht bei der Beantwortung der Frage zur Nützlichkeit von Typsystemen geholfen haben. Sie haben es allerdings ermöglicht, Erkenntnisse über Experimentaufbauten zu ziehen und darauf Folgeexperimente aufzubauen.Was nach den ersten drei Experimenten folgte, war ein Räsonieren darüber, warum die Experimente vielleicht bisher keinen Unterschied gezeigt haben. Eine Überlegung war, dass vielleicht die Art der Aufgaben nicht angemessen war, weil sie nicht auf Typsysteme beziehungsweise deren Fehlen ausgelegt waren, ohne zu wissen, wie man die Aufgaben darauf abstimmt.Hinzu kam, dass die Wahl der Sprachen in einigen Experimenten nicht angemessen erschien: Lediglich im zweiten Experiment wurden zwei echte Sprachen verwendet, die sich allerdings nur hinsichtlich einer Kleinigkeit, nämlich der Typüberprüfung von Parametern, unterschieden.Wenn man sich heutige Sprachen jedoch ansieht, so unterscheiden sich dynamisch typisierte von statisch typisierten Sprachen dadurch, dass dynamisch typisierte Sprachen im Allgemeinen keine Typen im Code verwenden, während statisch typisierte Sprachen im Allgemeinen Typdeklarationen erzwingen.Die drei Experimente, die dann folgten, lieferten ebenfalls keine echten Erkenntnisse – mit Ausnahme, dass das Beheben von Typfehlern in dynamisch typisierten Programmen sehr viel mehr Zeit benötigt. Allerdings scheint selbst das nur eine schwache Erkenntnis zu sein, denn Menschen, die pro dynamisches Typsystem argumentieren, würden dagegenhalten, dass zum einen Typfehler nur selten auftreten – wofür es keinen Beleg gibt.Andererseits würden diese Nachteile die Vorteile des dynamischen Typsystems, für die wir bisher schwerlich Indizien gefunden haben, nicht aufwiegen.Und man stünde damit wieder an der gleichen Stelle, nämlich der Frage, ob es hinsichtlich der Nutzbarkeit von Typsystemen einen Unterschied gibt.Leider war es nun nicht so, dass ein weltweiter Trend für Experimente zu Typsystemen losgetreten wurde. Aber immerhin – es gibt Folgeexperimente. Folgeexperimente mit Ergebnissen. Über diese Folgeexperimente sprechen wir im nächsten und letzten Teil dieser Serie.

Fussnoten

1. John D. Gannon, An experimental evaluation of data ­type conventions, http://www.dotnetpro.de/SL2003Typsysteme1
2. L. Prechelt, W.F. Tichy, A controlled experiment to assess the benefits of procedure argument type checking, http://www.dotnetpro.de/SL2003Typsysteme2
3. Stefan Hanenberg, An experiment about static and dynamic type systems: doubts about the positive impact of static type systems on development time, http://www.dotnetpro.de/SL2003Typsysteme3
4. Andreas Stuchlik, Stefan Hanenberg, Static vs. dynamic type systems: an empirical study about the relationship between type casts and development time, http://www.dotnetpro.de/SL2003Typsysteme4
5. Clemens Mayer, Stefan Hanenberg, Romain Robbes, Éric Tanter, Andreas Stefik, An empirical study of the influence of static type systems on the usability of undocumented software, http://www.dotnetpro.de/SL2003Typsysteme5
6. Sebastian Kleinschmager, Romain Robbes, Andreas Stefik, Stefan Hanenberg, Érik Tanter, Do static type systems improve the maintainability of software systems? An empirical study, http://www.dotnetpro.de/SL2003Typsysteme6