Statisch oder dynamisch

Seit den ersten Programmiersprachen wird gestritten. Welche Sprache die bessere und ob dynamische oder statische Typisierung besser sei – alles auf der Basis von persönlichen Erfahrungen. Jedoch gibt es eine Reihe von Erkenntnissen, die sich nicht aus der Welt reden lassen – jenseits subjektiver Eindrücke und Gefühle. Diese Erkenntnisse soll diese Artikelserie vorstellen.Neue Programmiersprachen erscheinen im Minutentakt – so möchte man meinen. Insbesondere die Entwicklung von Webanwendungen und Apps für mobile Endgeräte scheint die Neuentwicklung von Programmiersprachen enorm beflügelt zu haben.Beispiele für solche Sprachen sind JavaScript, TypeScript, Dart, Objective-C, Swift, Go, PHP, Python, Ruby, Kotlin, Groovy, Rust oder Hack. Diese spielen neben den großen Platzhirschen wie Java, C, C++ oder C# eine Rolle.Einige Sprachen werden begeistert von Entwicklern aufgenommen, bei anderen wiederum lässt der Enthusiasmus schnell wieder nach.Losgelöst von den konkreten Sprachen, die aktuell diskutiert werden, gibt es ein Konstrukt in der Programmierung, welches seit Jahrzehnten durchgängig die Gemüter erhitzt. Es ist die Frage, ob eine Variable oder ein Methodenparameter einen fest definierten Typ haben sollte – oder eben nicht.

Was hinter diesem Feature von Sprachen steckt und immer wieder für Diskussionen sorgt, sind statische Typsysteme. Statische Typsysteme stellen beispielsweise zur Entwurfszeit sicher, dass man einer Variablen vom Typ Integer keinen String zuweisen kann.Sie hindern uns auch daran, einer Methode, deren Parameter vom Typ Auto ist, ein Person-Objekt zu übergeben, und bieten darüber hinaus viele ähnliche Zusicherungen.Hinter den vielen Diskussionen um dieses Thema steckt oft allgemein die Frage, ob ein statisches Typsystem ein sinnvolles Sprachkonstrukt ist – oder aber Entwicklerinnen und Entwickler in ihrer Tätigkeit bremst.Diese Frage wird spätestens seit den 80er-Jahren des letzten Jahrhunderts – richtig, das ist knapp vierzig Jahre her – heiß diskutiert; schon zu Zeiten von LISP und Smalltalk, deren Vertreter statische Typsysteme ablehnten, wurde diese Diskussion leidenschaftlich geführt. Entsprechend wäre es an der Zeit, sich anzusehen, welche Fakten hinsichtlich der Nutzbarkeit von Typsystemen existieren.Man sollte sich klarmachen, dass die Softwareindustrie sehr dazu neigt, alte Dinge neu zu verpacken, aber dabei wenig grundsätzliche Innovationen hervorzubringen.In dieser Industrie, in der wenig bis keine messbaren Auswirkungen zu den Werkzeugen, die wir täglich nutzen, produziert und publiziert werden, wäre eine Überprüfung bestimmter Dinge auf wissenschaftlicher Ebene eigentlich umso wichtiger – egal ob zu Programmiersprachen, Patterns oder Architekturmustern.Dies wird allerdings bisher stiefmütterlich behandelt. Vieles, was Softwareentwicklerinnen und -entwickler in ihrem Alltag tun, basiert auf vermeintlich bewährten Praktiken, Gefühlen, persönlichem Geschmack und Erfahrung, aber leider selten auf empirisch belegten beziehungsweise gemessenen Ergebnissen.Entscheidungen über Millionen-Budgets werden auf dieser Wissensbasis getroffen. Und wenn man bedenkt, wie sehr die Softwareentwicklung unseren Alltag durchdringt, wird so manchem pessimistischen Zeitgenossen angst und bange ­angesichts der mangelhaften wissenschaftlichen Evaluation der verbreiteten Technologien und Techniken: Technologien und Techniken, die unter anderem hinter der Software für Finanztransaktionen, medizinische Anwendungen, Maschinen­steuerung und andere kritische Bereiche unseres Lebens stecken können.Diese Artikelreihe soll eine Einführung in den Entwurf von wissenschaftlichen Experimenten zu Programmierung geben und ein wenig in den Stand der wissenschaftlichen Forschung zu statischen Typsystemen einführen.Ziel ist es, dem Leser ein Gefühl dafür zu geben, warum echte wissenschaftliche Erkenntnisse in der Softwarebranche so schwer zu produzieren sind. Dahinter steckt die Hoffnung der Autoren, einerseits etwas Objektivität in die Diskussion zu bringen und andererseits das Interesse und das Bewusstsein für die wissenschaftliche Evaluation der Nützlichkeit vieler Dinge zu steigern, welche uns im Entwicklungsalltag als sinnvoll verkauft werden.In diesem ersten Artikel werden Grundlagen der empirischen Forschung und ihre Anwendung in der Softwaretechnik besprochen, bevor es in den nächsten beiden Teilen der Reihe um die Besprechung der konkreten Experimente gehen wird.

Häufige Argumente für oder gegen statische Typsysteme

Klassisch wird gegen statische Typen argumentiert, dass Deklarationen von Typen die Lesbarkeit von Quelltext reduzieren oder dass sich durch die Deklarationen der Schreibaufwand erhöhe.Zudem wird angeführt, dass der vermeintliche Nutzen von statischen Typsystemen – nämlich die Durchführung von Typüberprüfungen vor der Programmlaufzeit – eher gering (wenn überhaupt vorhanden) sei. Als Begründung nennen die Zweifler, dass die Fehler, die von Typsystemen identifiziert werden, eher trivial seien und sich daher der zusätzliche Aufwand für statische Typsysteme nicht lohne.Zusätzlich wird oft angeführt, dass statische Typsysteme zu Typecasts zwingen, was zum einen das Programmieren ­umständlich macht, zum anderen die Lesbarkeit des Quelltextes reduziert.Die Pro-Fraktion argumentiert, dass statische Typen ein zusätzliches Maß an Sicherheit geben, da ein Typsystem eine Reihe von Fehlern ausmerze, die während des Programmierens anfallen. Ferner wird angeführt, dass Typdeklarationen im Quelltext die Verständlichkeit erhöhen, da sie wertvolle Informationen für Programmierer darstellen.Und letztlich wird oft behauptet, dass ein Typsystem den Bau von Werkzeugen wie Codecompletion, Dokumentationsgenerierung oder Refactoring-Unterstützung vereinfache.Und weil es damit noch nicht genug ist, werden diese Diskussionen häufig um Einwände angereichert, dass zusätzliche Techniken, wie zum Beispiel Typinferenz oder optionale Typsysteme, einen Einfluss auf diese Vor- oder Nachteile haben. Gerade Vertreter von optionalen Typsystemen argumentieren häufig und gerne, dass diese „das Beste aus beiden Welten kombinieren“ – ohne darauf hinzuweisen, dass es logisch ebenfalls begründbar wäre, dass sie das Schlechteste aus beiden Welten kombinieren.Abgesehen davon, dass nicht klar ist, ob es überhaupt „das Beste“ oder „das Schlechteste“ gibt.Getragen werden diese Diskussionen in der Regel durch persönliche Erfahrungen der Diskussionsbeteiligten, häufig angereichert durch Quelltextbeispiele oder persönliche Anek­doten. Dabei sollte nicht vergessen werden, dass subjektive Einschätzungen, so plausibel sie auch klingen mögen, nicht zwangsläufig die Wirklichkeit widerspiegeln.Es sollte auch nicht vergessen werden, dass persönliche Wahrnehmungen geprägt sind von einer Reihe von Einflussfaktoren, wie zum Beispiel persönlichen Vorlieben oder Aversionen für oder gegen manche Programmiersprachen – neben einer nahezu unendlich langen Liste weiterer Einflussfaktoren. Auch wenn jeder von uns gerne den Anspruch hat, möglichst sachlich und objektiv zu urteilen, so müssen wir uns bewusst sein, dass wir es eher selten tun.Bevor wir uns dem eigentlichen Ziel widmen – nämlich der Frage, was genau über Typsysteme in der Softwareentwicklung bekannt ist –, müssen wir ein wenig ausholen und ein paar Worte über die sogenannten Wissenschaften und deren Vorgehensweisen verlieren.

Warum nicht einen Blick in die Wissenschaft wagen?

Wann immer es Kontroversen gibt, bei denen die Richtigkeit der Argumente nicht offensichtlich ist, ist es angemessen, diese Argumente auf Richtigkeit zu testen. Es scheint plausibel, dass derartige Tests von Menschen oder Institutionen durchgeführt werden, die (hoffentlich) keine persönlichen Interessen verfolgen: Die Tests sollten möglichst objektiv sein – was auch immer das nun schon wieder ist.In Disziplinen wie der Medizin, Physik, Chemie, Psychologie, Werkstofftechnik und so weiter ist es Usus, dass Aussagen nicht auf persönlichen Erfahrungen oder Urteilen, sondern auf sogenannten wissenschaftlichen Studien basieren. In derartigen Disziplinen ist es üblich, dass Tausende von Studien durchgeführt und veröffentlicht werden.Und die Wissenschaftsgemeinde ihrerseits erzeugt und erweitert sogenannte Wissenschaftsstandards, um gültige von ungültigen Studien zu unterscheiden.In vielen Bereichen, wie zum Beispiel der Medizin, geht es so weit, dass der Gesetzgeber Studien vorschreibt: Ein Arzt darf kein ungetestetes Medikament verschreiben und ein Pharmaunternehmen darf kein ungetestetes Präparat auf den Markt bringen.Die gesetzlichen Vorgaben und Wissenschaftsstandards sind darin begründet, dass ungetestete Präparate in der Geschichte einen nicht unerheblichen Schaden verursacht haben. Wissenschaftliche Studien sind im Allgemeinen sogenannte kontrollierte Experimente, mit deren Hilfe bestimmt wird, ob ein Ergebnis zufällig oder durch eine Intervention des Experimentierers zustande kommt.Ein klassischer experimenteller Aufbau ist der sogenannte AB-Test, bei dem zwei Gruppen von Versuchsteilnehmern entweder ein Medikament oder ein Placebo verabreicht wird, um dann zu testen, ob es einen Unterschied zwischen beiden Gruppen gibt, siehe dazu auch den Kasten Klassische experimentelle Designs.Ein anderer Versuchsaufbau ist ein sogenanntes Crossover-Design, bei dem jedem Probanden nacheinander die unterschiedlichen Wirkstoffe (oder ein Wirkstoff und ein Placebo) verabreicht werden.Wenn wir die anderen Disziplinen als Analogie nehmen, ist es naheliegend, sich auch für Fragen der Softwareentwicklung wissenschaftliche Studien anzusehen.Um hier ein zugegebenermaßen etwas polemisches Beispiel zu bemühen, beantworten Sie sich ehrlich folgende Frage: Würden Sie persönlich ein Medikament einnehmen, von dem Ihnen der Hersteller einerseits verspricht, dass es Ihrer Gesundheit wunderbar helfen wird, Sie aber andererseits wüssten, dass dieses Medikament nur unstrukturiert und ohne Mindeststandards an einer winzigen Gruppe von Personen ausprobiert wurde?Auch wenn es in der Softwareentwicklung glücklicherweise seltener um Gesundheit, Leben und Tod geht, stehen dort aber teilweise große Geldsummen auf dem Spiel und es geht oft um den Schutz von privaten Daten.Warum akzeptieren in der Welt der Software Entwicklerinnen und Entwickler so viel geringere Standards?

Leider ist die Wissenschaft in der Softwaretechnik nicht sehr weit

So hart es klingt, in der Softwareentwicklung spielen wissenschaftliche Studien aktuell kaum eine Rolle. Zum einen ist die Anzahl an Studien in der Softwareentwicklung marginal im Vergleich zu der in der Medizin: Laut Kaijanaho [1] gab es bis zum Jahr 2012 nur 22 kontrollierte Experimente zur Nutzbarkeit von Programmiersprachkonstrukten, während die Anzahl an kontrollierten Experimenten in der Medizin zu diesem Zeitpunkt in die Hunderttausende ging.Selbst wenn man den Fokus auf die gesamte Softwaretechnik ausweitet, kommt man, gemäß Ko, LaToza und Burnett [2] innerhalb eines Jahrzehnts nur auf wenig Dutzend Studien. Ferner sind Entwicklerinnen und Entwickler nur selten mit den wenigen Studien vertraut, die es gibt und die wissenschaftlichen Standards folgen.Und selbst wenn sie solche Studien kennen, ist unklar, ob sie diesen Vertrauen schenken: Einer Umfrage von Devanbu, Zimmermann und Bird [3] aus dem Jahr 2016 zufolge spielen wissenschaftliche Arbeiten für die Meinung von Entwicklerinnen und Entwickler keine nennenswerte Rolle. Stattdessen werden persönliche Erfahrungen weit höher geschätzt.Nun mag es eine Reihe von Gründen dafür geben, dass die Anzahl an Studien in der Softwareentwicklung sehr gering ist. Häufig hört man das Argument, dass die Informatik im Allgemeinen eine noch sehr junge Disziplin sei und entsprechend wissenschaftlich nicht weit fortgeschritten.Das geringe Alter im Vergleich zur Medizin ist zwar richtig, blendet jedoch aus, dass die meisten der hunderttausend Studien in der Medizin in den letzten dreißig Jahren durchgeführt wurden. Auch wird argumentiert, dass kontrollierte Experimente nicht auf die Softwareentwicklung übertragbar seien, da die Softwareentwicklung ein kreativer Prozess sei, den man nicht mit der rein biochemischen Wirksamkeit eines Medikaments vergleichen könne.Womit vollständig ausgeblendet wird, dass kontrollierte Experimente insbesondere in der Psychologie Anwendung finden, wo unter anderem auch vergleichbare kreative und andere kognitive menschliche Prozesse im Fokus der Betrachtung stehen.Und zu guter Letzt haben überraschend viele Menschen Vorbehalte gegenüber kontrollierten Experimenten, häufig gepaart mit Bedenken, ob experimentell gezeigte Ergebnisse sich auf die Realität übertragen lassen – hierzu werden wir abschließend noch ein paar Worte verlieren.

Experimentaufbau, experimentelle Analysen und Schließen

Eine Reihe von Ressentiments gegenüber kontrollierten Experimenten in der Softwareentwicklung rühren möglicherweise daher, dass zur Beurteilung von experimentellen Ergebnissen zusätzlich zum Wissen über Experimentaufbauten etwas inferenzstatistisches Wissen notwendig ist – was gewöhnlich in der Ausbildung keine Rolle spielt, auch nicht in einem Informatikstudium.Entsprechend verhalten reagieren oft Entwicklerinnen und Entwickler, wenn von p-Werten oder Effektgrößen gesprochen wird – auch wenn derartige Sachen kein Hexenwerk sind. Wir versuchen hier diese Dinge möglichst verständlich und kurz zu erklären.Bei einem kontrollierten Experiment versucht man alle Faktoren statisch zu halten, außer dem, der gemessen werden soll. Muss also ein neues Blutdruck-Medikament seine Wirksamkeit beweisen, würde ein Experimentaufbau dazu sinnvollerweise versuchen, für die Dauer des Experiments alle Probanden den gleichen Testbedingungen zu unterwerfen, zum Beispiel durch gleiche Ernährung, gleiches Umfeld, Schlafdauer und so weiter.Dies geschieht, um möglichst alle anderen Einflussfaktoren auf den Blutdruck gleich zu halten, damit tatsächlich möglichst nur der Effekt des gegebenen Medikamentes gemessen wird. Ein schwieriges Unterfangen.Zur Auswertung der aus einem Experiment gewonnenen Daten muss man grundsätzlich nur wissen, dass es zu experimentellen Aufbauten entsprechende Signifikanztests gibt. Diese Tests sind statistische Tests, die auf Gruppen von Daten (Zahlen) angewendet werden, deren Ergebnis ein p-Wert ist. Der p-Wert ist eine Zahl zwischen 0 und 1 und gibt an, wie groß die Evidenz (also Gewissheit) ist, dass ein Unterschied zwischen den Datengruppen real und nicht das Produkt von Zufall ist. Je näher der p-Wert an 0 ist, desto größer die Gewissheit, dass es kein Zufall ist. Wobei Werte oberhalb von 0,05 als nicht signifikant bezeichnet werden.Aus Experimentdesigner-Sicht handelt es sich in diesen Fällen um keine ausreichende Gewissheit, dass das Ergebnis von den betrachteten Faktoren abhängt. „Nicht signifikant“ bedeutet vereinfacht, dass noch zu viele Zufallsfaktoren eine Rolle gespielt haben müssen. Wie zum Beispiel, ob der gemessene Blutdruck tatsächlich durch Gabe von Medikament A oder B beeinflusst wurde oder durch andere Faktoren, die auf den Patienten eingewirkt haben.Die Sache mit der Effektgröße ist leider nicht so simpel zu erklären. Denn während ein p-Wert das Ergebnis jedes statistischen Tests ist, unterscheiden sich die Effektgrößen zwischen unterschiedlichen Tests. Hier verweisen wir der Einfachheit halber auf die Tatsache, dass Effektgrößen dazu da sind, die Größe des Unterschieds zu zeigen – wobei der Unterschied signifikant sein muss, damit diese Größe echt und auswertbar ist. Für unser obiges Blutdruck-Beispiel heißt dies beispielsweise: Wenn der p-Wert des Tests aussagt, dass das Medikament den Blutdruck signifikant beeinflusst hat, dann können wir über die Effektgröße die Stärke des Effekts einschätzen.Nun ist es so, dass Experimente lediglich Tests sind. Softwareentwickler und -entwicklerinnen sind mit dem Prinzip des Testens wohlvertraut: Auch wenn es in der Softwareentwicklung dabei meist nicht um statistische Auswertungen geht, so werden Tests durchgeführt, um zu sehen, ob ein Stück Software seine Funktion erfüllt. Ferner wissen sie, dass ein erfolgreicher Test nicht bedeutet, dass die Software korrekt läuft.Ein Test ist also kein Beweis. So verhält es sich auch in empirischen Wissenschaften. Das heißt, selbst wenn viele Experimente existieren, die den Vorteil einer Technik belegen, so bedeutet das nicht, dass damit der unumstößliche Beweis für den Nutzen der Technik erbracht wurde. Wichtig ist, dass Experimente, die nicht signifikante Ergebnisse liefern, lediglich besagen, dass ein Nutzen nicht belegt werden konnte.Was nicht bedeutet, dass dieser Nutzen nicht existiert, aber auch nicht, dass er existiert. Gerne nutzen einige Menschen den Hinweis darauf, dass ein Nutzen von etwas existieren könnte, auch wenn dieser bisher noch nicht belegt ist, dazu, um vermeintlichen Nutzen zu suggerieren – und das nicht nur in der nun etwa 200 Jahre währenden Homöopathie-Debatte.Experimentelles Schließen im Sinne der Wissenschaft funktioniert derart, dass erst durch einen experimentellen Beleg eine Aussage akzeptiert wird – allerdings nicht als bewiesen angenommen. Wenn widersprüchliche Experimente existieren, so wird eine damit verbundene Aussage als problematisch erachtet, mit dem Versuch, durch Folgeexperimente eine solche Aussage zu erhärten oder zu widerlegen.Experimente werden in ihrer Gesamtheit betrachtet, das heißt, es wird nicht der Versuch unternommen, sich einzelne Experimente herauszupicken, deren Ergebnisse der eigenen, erhofften Wahrnehmung am nächsten kommen.Letzteres Vorgehen ist höchst unseriös. Denn Einzelexperimente werden im Allgemeinen als problematisch erachtet – eine Schwalbe macht noch keinen Sommer –, sodass Experimente wiederholt werden, um zu prüfen, ob die damit verbundenen Aussagen sich abermals gewinnen lassen. Am Ende einer langen Reihe von Experimenten steht dann hoffentlich eine Theorie, die es ermöglicht, Phänomene zu erklären, ohne jedes Mal ein neues Experiment durchführen zu müssen. Sprich, experimentell argumentierenden Menschen ist es nicht nur wichtig, ob es für zu untersuchende Aussagen Experimente gibt, sondern auch, ob es viele solcher Experimente gibt und ob diese zu ähnlichen Ergebnissen führen.In den großen empirischen Wissenschaften werden danach sogenannte Meta-Studien durchgeführt, die viele Experimente gleichzeitig untersuchen, was eine große Anzahl an Experimenten voraussetzt. Mit solchen Meta-Studien ist in der Softwareentwicklung in naher Zukunft – aufgrund der ohnehin geringen Anzahl an Studien – nicht zu rechnen.Dies soll diese kurze Einleitung abschließen, auch wenn zu den Themen Experimentaufbau und -auswertung ganze Bücher geschrieben wurden. Hoffentlich ist der geneigte Leser noch bei uns und hat zumindest einen groben Eindruck davon bekommen, was empirischen Erkenntnisgewinn in den Wissenschaften zu so einer zeit- und ressourcenaufwendigen Sache macht.

Wie werden oder sollten Typsysteme studiert werden?

Doch zurück zu Typsystemen. Angesichts der wenigen Studien in der Programmiersprachenwelt kann man nicht davon ausgehen, dass Sprachkonstrukte eingehend studiert sind. Allerdings gibt es zu Typsystemen eine aus Sicht der Softwareentwicklung größere Anzahl an Studien, wobei die Anzahl noch immer klein genug ist, dass man alle Studien einzeln lesen kann, ohne dafür ein ganzes Wochenende opfern zu müssen. Bevor wir jedoch die Ergebnisse der einzelnen Studien vorstellen, sollten wir uns folgende Fragen stellen: Was sollte studiert werden? Und wie?Leider ist es notwendig, sich darüber im Vorfeld ein paar Gedanken zu machen, um nicht der Versuchung zu erliegen, etwas als gültige Studie zu titulieren, nur weil die Autoren aus einem akademischen Umfeld kommen. Und Formulierungen der Form „Wissenschaftliche Studien haben gezeigt, dass …“ sprechen auch nicht unbedingt dafür, dass der Urheber sich der Implikationen solcher Studien bewusst ist (noch dafür, dass er sich ernsthaft mit den Studien auseinandergesetzt hat).Es scheint plausibel, dass man ein Typsystem einfach dadurch studiert, dass man im Sinne eines kontrollierten Experiments eine statisch typisierte Sprache nimmt, von einer Gruppe von Menschen gemeinsam mit dieser etwas bauen lässt und von einer anderen Gruppe von Menschen gemeinsam mit einer nicht statisch typisierten Sprache etwas Gleiches bauen lässt. Dann schaut man, wo häufiger Fehler gemacht werden.Auch wenn das auf den ersten Blick plausibel klingt: Das entspräche nicht der Idee eines Experiments, und es hakt dort an vielen unterschiedlichen Stellen, sodass der vermeintliche Erkenntnisgewinn eines solchen Versuchs gering wäre. Die Gründe liegen an (a) dem Stichprobenumfang, (b) der Wahl der Messung und (c) der Wahl der Sprachen. Es gibt noch ­einen weiteren Punkt, der anzusprechen wäre, nämlich die Wahl der zu schreibenden Software. Aber diese Diskussion führen wir erst ganz am Ende, zusammen mit einer Reihe anderer zu diskutierender Punkte.

Keine Einzelmessungen, sondern Stichproben

Dass das Experiment so wie eben beschrieben nicht funktioniert, liegt an folgender Überlegung. Nehmen wir an, dass ­eine Gruppe von Entwicklerinnen und Entwicklern beim Entwickeln mit einer vorgegebenen Wahrscheinlichkeit eine Anzahl von Fehlern macht. Die Chance, dass eine zweite Gruppe unter identischen Voraussetzungen die gleiche Anzahl von Fehlern macht, ist gering: Beide Gruppen unterscheiden sich mit großer Wahrscheinlichkeit trotz gleicher Aufgabenstellung. Für den Fall, dass das Beispiel nicht plastisch genug ist: Gehen Sie fünf Kilometer joggen und messen Sie die Zeit (so präzise wie möglich). Gehen Sie in vier Wochen, nachdem sich der Muskelkater und der Trainingseffekt wieder gelegt haben, abermals joggen und messen Sie wieder die Zeit. Für wie wahrscheinlich halten Sie es, dass Sie die identische, also die exakt gleiche Zeit laufen?Die Wahrscheinlichkeit liegt bei null. Das heißt, selbst unter identischen Voraussetzungen werden sich zwei Messungen unterscheiden – der Unterschied zwischen zwei singulären Messungen ist kein Hinweis auf das Vorliegen eines Unterschieds (so seltsam sich das auch anhört).Um zu sehen, ob ein Typsystem einen Einfluss hat, benötigt man eine größere Stichprobe. Man vergleicht dazu zum Beispiel zehn Einzelpersonen, die eine Software mit einer statisch typisierten Programmiersprache geschrieben haben, mit zehn Einzelpersonen, die mit einer nicht statisch typisierten Programmiersprache die gleiche Software geschrieben haben. Auf den Einwand, dass größere Software nicht von Einzelpersonen geschrieben wird, werden wir am Ende eingehen, ebenso wie auf die Frage, wie groß denn nun eine Stichprobe sein sollte.

Fehler zu messen ist ein Fehler

Es hat in der Softwareentwicklung eine lange Tradition, von der Anzahl an Bugs zu reden. Und es scheint verführerisch, die Anzahl an Fehlern zu vergleichen. Sagen wir, ein Entwickler macht beim Bau einer Software zwei Fehler, während ein anderer nur einen macht. Was würde das besagen? Nichts. Nicht, solange wir nicht sicherstellen können, dass beide Fehler vergleichbar sind: Es macht einen Unterschied, ob ­eine Person einen Syntaxfehler, den sie innerhalb einer Sekunde behebt, oder einen Stackoverflow-Fehler begeht, dessen Behebung einige Stunden dauert. Aber was heißt „Vergleichbarkeit von Fehlern“ eigentlich? Ist ein Syntaxfehler in Java in Form eines fehlenden Semikolons vergleichbar mit dem Fehlen einer schließenden Klammer? Auch hier gibt es gute Gründe anzunehmen, dass dem nicht so ist. Aus diesem Grund wird die Anzahl an Fehlern als Metrik für den Vergleich zweier Techniken heutzutage meist (wenn auch leider nicht immer) kritisch gesehen.Worauf man stattdessen hinaus will, ist der Unterschied im Aufwand. Selbst wenn ein Programmierkonstrukt syntaktisch unhandlich wäre, sodass der Entwickler dort zahlreiche ­syntaktische Fehler beginge, das Konstrukt aber derart hilfreich wäre, dass die Entwicklung eines Programms mit dessen Hilfe weniger Aufwand bedeuten würde – trotz der höheren Anzahl an Fehlern müsste man ein solches Konstrukt positiv bewerten.Wenn es also um den Aufwand in Form von Zeit geht, warum nicht direkt diese Zeit messen? Genau das sollte man tun.

Welche Sprachen und welche Typsysteme?

Ein weiteres Problem ist die Wahl der Sprache. Wenn ausschließlich der Einfluss des Typsystems bestimmt werden soll, sollten sich Sprachen im Idealfall ausschließlich hinsichtlich des Typsystems unterscheiden. Erschwerend ist dabei allerdings, dass zu einem Typsystem in der Regel weitere Sprachkonstrukte gehören, wie zum Beispiel Typecast, Overloading, et cetera. Ferner darf man nicht vergessen, dass es nicht das eine Typsystem gibt, sondern dass Typsysteme sich zum Teil deutlich unterscheiden: Ein eher funktionsarmes Typsystem wie das von Java 1.0 weicht deutlich von einem Typsystem wie dem von ML ab.

Zusammenfassung

Puh, das war schon harter Stoff, der aber hoffentlich Lust auf mehr macht. In diesem ersten Teil der Artikelreihe wurde neben einer grundlegenden Einführung in empirische Forschung auch auf den gravierenden Mangel an empirischen Experimenten in der Softwareentwicklung eingegangen. Die Softwareentwicklung ist noch viel zu oft getrieben von persönlichen Erfahrungen, Meinungen und Ansichten, und weniger von harten Fakten.Zudem wurde auf Probleme hingewiesen, vor denen ­Experimente in der Softwaretechnik stehen. Dabei sollte ­besonders die Warnung vor Nullexperimenten hervorge­hoben werden: Aus einem Experiment, welches keine ­Unterschiede zwischen Techniken zeigt, kann nicht geschlussfolgert werden, dass es keinen Unterschied zwischen diesen Techniken gibt.In den nächsten beiden Teilen werden die existierenden Experimente und Ergebnisse besprochen, die sich explizit mit der Frage statischer oder dynamischer Typisierung auseinandersetzen. Man wird eine Reifung der Methoden in diesem Bereich sehen können und verstehen, welche greifbaren Ergebnisse zu der Frage inzwischen existieren. 

Fussnoten

1. Antti-Juhani Kaijanaho, Evidence-based programming language design: a philosophical and methodological ­exploration, http://www.dotnetpro.de/SL2002Typsysteme1
2. Andrew J. Ko, Thomas D. LaToza, Margaret M. Burnett, A practical guide to controlled experiments of software engineering tools with human participants, http://www.dotnetpro.de/SL2002Typsysteme2
3. Prem Devanbu, Thomas Zimmermann, Christian Bird, Belief & evidence in empirical software engineering, http://www.dotnetpro.de/SL2002Typsysteme3