Wenn Codegeneratoren Quelltext für Codegeneratoren erzeugen, läuft ebenso etwas falsch, als wenn man versuchte, Festplatten mit kleinen Magneten zu formatieren. In der Diskussion über Hilfe durch Frameworks und Toolkits gerät manchmal die Beherrschbarkeit eines Softwaresystems verloren.

Klein ist fein, dachte sich einmal ein namentlich nicht genannter Entwickler einer Linux-Distribution und postulierte, dass eine Webseite in ein TCP-Paket passen müsse. Außerdem wäre nur handgeschriebener Assemblercode wirklich performant. In grauer Vorzeit galt dieser Grundsatz vielleicht (einmal von den TCP-Paketen abgesehen), aber heute erzeugen Compiler meist besseren Maschinencode als solcher, den Entwickler selbst austüfteln - zu kompliziert sind die internen Abläufe in modernen CPUs, zu komplex das Timimg von Pipelines und zu unabsehbar die Auswirkungen mehrstufiger Cache-Hierarchien.

Hierarchie-Ebenen

Deshalb verwenden Entwickler mittlerweile Compiler. Aber das Prinzip lässt sich auch noch weiterdenken: Niemandkommt heute noch ohne Bibliotheken aus, zu vielfältig sind die Aufgaben, die ein Programm erledigen soll. Da ergibt es nur Sinn, immer wiederkehrende Aufgaben in eine Schachteln zu verpacken und diese zu benutzen. Klassenbibliotheken abstrahieren Funktionssammlungen, Frameworks abstrahieren Klassen und Entwurfsmuster transzendieren ganze Anwendungsarchitekturen.

Hierarchische Strukturen sind den meisten Entwicklern vertraut, machen sie doch das Leben einfach. Doch wie auch im richtigen Leben lohnt es manchmal, die Gegebenheiten zu hinterfragen und einen Schritt zurückzutreten, um das Ganze aus einem holistischen Blickwinkel zu betrachten.

Da gibt es Entwickler, die freudestrahlend davon berichten, wie sie mit wenigen Mausklicks ein Datenmodell aus einer Datenbank extrahieren und mittels Codegeneratoren persistente Java-Klassen erzeugen, die für einen Adressdatensatz später im Hauptspeicher ein knappes Megabyte dauerhaft belegen.

Hardware kostet nichts

Auf den Ressourcenhunger angesprochen kontern die Anhänger der neuen Sorglosigkeit mit dem Totschlagargument, dass man einfach einen neuen Server hinstelle, wenn der alte nicht mehr ausreiche. Hardware koste ja nichts mehr. Die Argumentation erinnert ein wenig an die Ernsthaftigkeit derer, die mit dem Hinweis auf die Steckdose die Energiekrise wegreden wollen.

Einfache Aufgaben sollten in einer einfachen Lösung resultieren. Wer einen Textstring von einer Standardeingabe lesen möchte, für den reicht in C ein »fgets(s);« oder in Perl ein »s = <>;«. Abstraktion hin oder her, aber wer kann noch plausibel vermitteln, wieso Java wie in Abbildung 1 dazu fünf Klasseninstanzen und einen Integer benötigt?

Abbildung 1: Java benötigt fünf Klassen und einen Integer um einen String aus einer Datei auszulesen. In Perl reichen dazu vier Zeichen und ein Semikolon.

Das ist übrigens kein Problem der Programmiersprache, sondern vielmehr der Attitüde, der sich mancher Entwickler hingibt. Wer Kartenhäuser aus Abstraktionsebenen baut, übersieht, dass die Ergebnisse nicht mehr handhabbar sind, sobald nur noch die Maschine, ein Build-Skript oder der Precompiler um die wirklichen Zusammenhänge im Code weiß. Übergeneralisierung ist ebenso gedankenlos wie das eingangs diskutierte Beharren, alles zu Fuß erledigen zu wollen. Bewunderswert sind daher alle Entwickler, die noch wissen, was sie tun.

Umso spektakulärer sind dann die Ergebnisse der Verbesserungen im Kleinen. Im Beitrag "Deko mit Nutzen" ab Seite 96 stellt Rainer Grimm eine Erweiterung von Python vor, die bei einigen Programmen eine dramatische Steigerung der Performance bewirkt. Die Dekoratoren sind ein ganz einfaches Sprachmittel, um übersichtlich Code in universeller Weise in Methoden einzubringen. Ein Beispiel ist ein Cache für rekursiv aufgerufe Funktionen.

Noch pragmatischer ist der Artikel "Wer liefert wann?" von Perlmeister Mike Schilli ab Seite 102. Darin zieht der bekennende Internet-Shopping-Süchtige dieSourcecodeverwaltung Git des Linux-Kernels heran, um nicht den Überblick über seine Bestellungen zu verlieren.

Wenn Codegeneratoren Quelltext für Codegeneratoren erzeugen, läuft ebenso etwas falsch, als wenn man versuchte, Festplatten mit kleinen Magneten zu formatieren. In der Diskussion über Hilfe durch Frameworks und Toolkits gerät manchmal die Beherrschbarkeit eines Softwaresystems verloren.

Kommentare (1)
von jk_com, 04.05.2010 16:16	... fünf Klassen und einen Integer... Na, da ist wohl eher der Wunsch Vater des Gedankens, oder? Wer beweisen will, dass etwas kompliziert ist, muss es nur kompliziert genug darstellen und schon fallen andere darauf herein. Ich lese meine Dateien einfach ordentlich mit einem "BufferedReader read = new BufferedReader(new FileReader("demo.txt"); Das sind genau drei Klassen (der StringBuffer mal mitgerechnet). Das Beispiel liest nicht von der Standardeingabe, das geht nämlich mit System.in. Ausserdem verkennen sowohl das C-Beispiel wie auch das Perl-Beispiel ein wie immer geartetes Encoding des Eingabestroms (UTF-8, ISO, ASCII?). Was passiert, wenn man statt ASCII plötzlich UTF-8 empfängt, sieht man an vielen kaputten ÜÄÖs auf mehr als genug Webseiten. Ausserdem lesen die angegebenen Beispiele immer den ganzen Text in den Speicher, was z.B. bei einer Filmdatei mit 4GB mir ziemlich Kopfzerbrechen machen würde. Die Abstraktion in Java hat also sehr gute Gründe und nur weil's der Autor nicht versteht, ist's nicht schlecht.