Eigentlich weiß ich das ja schon länger, aber heute ist es mir wieder schmerzhaft bewußt geworden: Interpretierte Sprachen sind zur Entwicklung ernsthafter Programme ungeeignet. Für Prototypen, einen schnellen Hack, oder als Shell-Skript-Ersatz sind sie eine feine Sache, aber nicht für echte Programme.
Man hört oft, Computer sind heutzutage so schnell, daß das schlechtere Laufzeitverhalten nicht ins Gewicht fällt, und falls doch ein paar Stellen kritisch sind, so ist das auch kein Problem: die Sprache kann C-Routinen aufrufen. Aber darum geht es nicht. Die echten Nachteile liegen nicht in der Ausführungsgeschwindigkeit, sondern in der fehlenden statischen Prüfung des Codes. Wenn man in einer kompilierten Sprache Quatsch schreibt, dann kann man darauf hoffen, daß der Compiler das bemerkt. In manchen strengeren Sprachen läßt der Compiler weniger Quatsch durchgehen als in nachgiebigeren, aber es gibt erstaunliche viele Sorten Quatsch, die jeder Compiler findet. Interpretierte Sprachen kennen keinen Compiler, deswegen finden sie den Quatsch erst zur Laufzeit. Wenn sie ihn finden: Es gibt viele Pfade durch ein Programm, und einige davon werden nur selten benutz; deshalb ist es einfach, völlig vergurkte Programme zu schreiben, zu installieren, und zu benutzen. Es heißt dann oft Deshalb brauchen wir Tests, aber so nützlich Tests auch sind, so haben sie doch gewichtige Nachteile (jedenfalls wenn sie die einzige Möglichkeit sind, Fehler zu finden: Zuerst müssen sie überhaupt geschrieben werden. Ein Compiler versteht die Sprache, aber der Entwickler muß alle nötigen Testcases von Hand schreiben. Dabei kann man leicht etwas übersehen, und noch leichter aus Bequemlichkeit zu wenige (oder gar keine) Tests schreiben. Zweitens braucht das Abarbeiten der Tests Rechenzeit -- wahrscheinlich mehr, als man durch den fehlenden Compilerlauf gespart hat; und das Schreiben kosts Entwicklerzeit, und zwar eine Menge. Schließlich findet der Compiler oft einfach andere Fehler als Tests, und wenn man beides einsetzt, findet man mehr Fehler.
Ja, und dann gibt es noch das Problem mit externem Code. Bibliotheken, Module, oder wie man ihn auch nennen will. APIs sollten sich nicht ändern (jedenfalls nicht ohne guten Grund), aber manchmal tun sie es eben doch. Für gewöhnliche, binäre Programme gibt es wohldefinierte Mechanismen, um verschiedene Versionen einer Bibliothek gleichzeitig vorzuhalten, damit ältere Programme immer noch laufen. Einen entsprechenden Mechanismus für Python kenne ich nicht, und so ungewöhnlich ist es nicht, wenn ein sauber installiertes Modul mit ImportErrors um sich wirft. Wenn man eine solche Methode entwickeln wollte, hätte man auch mit einem zusätzlichen Problem zu kämpfen: Wenn ein Programmierer eine shared library verlinkt, dann nimmt der Linker automatisch die neueste installierte Version dieser Bibliothek. Die Versionsnummer wird dann in dem kompilierten Programm verewigt, und wenn man es irgendwann später startet, wird die richtige Bibliothek benutzt. Es liegt aber gerade im Wesen einer interpretierten Sprache, daß der Programmcode nur vom Programmierer verändert wird. Wenn dieser also nicht von Hand eine bestimmte Bibliotheksversion anfordert, dann tut das auch keine andere Instanz.
Im Ernst: man sollte Werkzeuge verwenden, die für die Aufgabe geeignet sind, anstatt sich verzweifelt an seinen Hammer zu klammern und überall Nägel zu sehen.
Kommentare deaktiviert für Lessons learned • english
