Statisch typisierte Sprachen überprüfen Typ-Konformität zur Übersetzungszeit, während dynamisch typisierte Sprachen dies erst zur Laufzeit tun. Mit statischer Typisierung lassen sich eine Reihe von "dummen" Fehlern finden, noch bevor das Programm das erste Mal gestartet werden kann. Mit sorgfältig gewählten Typen kann man ein Programm noch lesbarer machen und gibt insbesondere dem Übersetzer die Möglichkeit, Unstimmigkeiten aufzudecken. Statisch typisierte Sprachen unterscheiden sich allerdings in der Vielfalt der Typen. Je feiner unterschieden wird, desto mehr Sicherheit ist möglich und um so mehr Sorgfalt verlangt die Typenwahl.

Die meisten statisch typisierten ProgrammierSprachen wie z.B. SpracheAda, SprachePascal, SpracheModula2?, SpracheModula3, SpracheOberon, SpracheCee, SpracheCpp oder die SpracheJava, zwingen den Programmierer dazu, die Datentypen aller verwendeten Variablen und Parameter von Funktionen und Methoden zu deklarieren. In der SpracheHaskell ist es ein vom Übersetzer angemahnter Schönheitsfehler, wenn Typdeklarationen weggelassen werden. Der Übersetzer kann aber auf Wunsch den Typ eines Ausdruckes berechnen.

Es ist eigentlich überflüssig zu sagen: Natürlich findet man mit diesem Konzept nicht alle Fehler, aber jeder Schutzmechanismus erhöht die Sicherheit. Die Frage sollte also nicht sein "Statische Typisierung oder nicht?" sondern "Statische Typisierung und was sonst noch?"

Aber: Statische Typisierung nimmt einer Sprache einiges an Dynamik. Und da stellt sich dann unter anderem die Frage, ob der Mehraufwand bei der Programmierung nicht auch zu mehr Fehlern führt. Ein Ausweg aus dem Dilemma stellen optionale Typannotationen dar, ein anderer sind Generics. Typecasts brechen das Konzept der Typisierung, auch beim sogenannten Autoboxing. Typinferenzer können dem Programmierer Arbeit abnehmen. Mit in das Thema spielen auch verschiedene Typ-Konzepte wie Interfaces, Mixins oder Traits.

Siehe auch TypSicherheit

• http://www.transframe.com/transframe/intro.htm, "Comparison", Abschnitt 1.8
• http://onestepback.org/index.cgi/Tech/Groovy/Closures.rdoc, Diskussion über typisierte DynamicClosures in SpracheGroovy
• http://redhanded.hobix.com/inspect/staticTyping.html, Diskussion über optionale statische Typen in SprachePython und SpracheRuby

Diskussion

Wenn ein Softwaresystem im Sinne von ExtremeProgramming mit KomponentenTests versehen wurde, gibt dies eine erheblich höhere Sicherheit vor allen Arten von Fehlern, wobei auch Typfehler mit großer Wahrscheinlichkeit erkannt werden.

Wenn der Typkonflikt bei einer Sprache mit später Bindung erst zur Laufzeit auftreten kann, muss er durch einen Test nicht sicher erkannt werden. Für Typkonflikte, die durch eine statische Analyse eines Quelltextes gefunden werden können, ist eine automatisierte statische Analyse mindestens so nützlich wie ein Test. Was tragen KomponentenTests zur Entdeckung von Typkonflikten bei? -- KurtWatzka

Ich kann das nur aus der theoretischen Sicht eines Beobachters beurteilen. Die XP-KomponentenTests sind wirklich umfassend und Testen jede Kleinigkeit. Der Aufwand dafür ist hoch. Das vielbeschriebende C3Projekt hat mehr Code in den Tests (ca. 30000 Tests?, ich hab die Zahl nicht mehr im Kopf) als im eigentlichen Programm. Ich nehme an, dass in Smalltalk und bei ungewisser Qualität der Programmierer eine andere Vorgangsweise gar nicht möglich ist. Nicht mein bevorzugter Stil, aber doch ein plausibler Denkansatz. -- HelmutLeitner

Ich habe für eine kleine Programmierübung an der TU einmal TestgetriebeneEntwicklung in der SprachePython ausprobiert. Ich habe doppelt soviel Testcode wie funktionellen Code gehabt aber dafür habe ich genau einen Programmierfehler gemacht und der war - dank der Tests - offensichtlich zu beheben.

Ein Typfehler in Smalltalk ist ein Message Send an ein Objekt, welches die gesendete Botschaft nicht versteht (oft ist das Objekt nil, eine ziemlich "dummes" Objekt der Klasse UndefinedObject?). Unentdeckte Typfehler in Smalltalk sind relativ selten. Dass sie sich erst zur Laufzeit bemerkbar machen, wird durch zwei Programmierparadigmen ausgeglichen:

Das beschriebene "test first" ist erst seit ein paar Jahren in Mode gekommen. Warum dies erst mit XP (und damit eben auch mit Smalltalk) trendy wurde, ist mir ein Rätsel. Ohne Regressionstests bekäme ich vermutlich kein stabiles C++ Programm hin.

Programmieren während das Programm läuft. Soetwas habe ich bislang nur in Smalltalk erlebt, wo man im Debugger programmieren kann; mit dynamisch typisierten Sprachen und langen Übersetzungszyklen sicher nur schwer realisierbar, in Smalltalk tägliches Brot.

In Visual Basic for Applications (VBA) kann man auch laufendes Programm im Debugger bearbeiten. Im Visual C++ kann man auch im Debugger Teile des Programms neu übersetzen und weiterlaufen lassen, allerdings klappt es nicht immer. -- GregorRayman

Siehe auch StatischOderDynamischTypisiert. -- SaschaDördelmann

Bleiben wir beim Beispiel eines Stacks. Der Fehler, bei dem ich besorgt wäre, ob er durch einen Modultest sicher gefunden werden kann, ist der, dass verschiedene Nutzer des Stacks Objekte auf den Stack packen und nicht damit rechnen, dass auch andere Nutzer (nicht Anwender sondern Module) mit dem Stack arbeiten, so daß der Zugriff auf das oberste Stackelement ein Objekt vom falschen Typ liefert.

• Der Modultest des Stacks selbst entdeckt den Fehler nicht, weil das Stack-Modul selbst gar keinen Fehler hat, sondern es nur falsch angewandt wird.
• Der Modultest eines einzelnen Moduls, das das Stackmodul verwendet, entdeckt den Fehler nicht, weil der Fehler dadurch entsteht, das der Stack versehentlich wiederverwendet wird, nicht dadurch, dass ihn ein einzelnes Modul falsch nutzt.
• Wenn es kein Modul gibt, dass für sich beide Konkurrenten so nutzt, das beide auf den Stack zugreifen, bleibt der Fehler unentdeckt, bis er zufällig als Laufzeitfehler auftritt.

Nur ein Integrationstest kann solche Fehler sicher finden. Eine Sprache, die Stacks typsicher macht, verhindert schon die versehentliche Verwendung eines Stacks von Aufträgen als Stack von Vorher/Nachher-Beziehungen --kw

• Alles was du sagst klingt logisch, und ich habe die Aussage des OP oben noch weiter als ursprünglich abgeschwächt.
• Grundsätzlich sehe ich die angesprochene Fehlerklasse aber eher als logische Fehler, denn die versehentliche Mehrfachverwendung eines Stack kann auch bei korrekten Typen unangenehme Probleme verursachen, die möglicherweise unter Testbedingungen überhaupt nicht erkannt werden.

Die Fehlerklasse --- auf dem Stack finde ich etwas, was ich nicht dorthin geschoben habe und womit ich deswegen nicht rechne --- sicher nicht, der Typkonflikt als solcher --- und hier geht es doch um TypSicherheit --- aber schon. Der logische Fehler ist durch eine Typprüfung sicher nicht --- und nicht nur nicht sicher --- zu finden. -- kw

• Ich habe da an die von dir angesprochenen Integrationstests gedacht. -- hl