|
Virtuelle Zockhalle 0.05 beta
|
Bei der virtuellen Zockhalle handelt es sich um ein Framework für die Programmierung von spielbaren Simulationen für Geldspielgeräte (nicht nur) deutscher Bauart und eine hoffentlich ständig wachsende Anzahl damit programmierter Geräte.
Ich durfte erleben, dass ein Mensch, der vor allem von der Erstellung komplexer Java-Anwendungen lebt, angsichts der Quelltexte der Virtuellen Zockhalle herablassend lächelte -- es erschien ihm alles so einfach.
Nun, genau diese Einfachheit ist ein Feature.
Jede Quelle unnützer Komplexität wird vermieden. Es wird eine Low-Level-Bibliothek für die graphische Darstellung verwendet, und darüber hinaus keine weiteren Bibliotheken. Die häufigste Datenstruktur ist das Array, also ein zusammenhängender Speicherbereich, darüber hinaus findet sich tief in der Implementation der Programmsteuerung eine verkettete Liste. (Diese könnte in späteren Versionen durch einen Heap ersetzt werden, ohne dass sich die Schnittstelle ändert, wenn hier etwas »Optimierung« erforderlich wird.) Mehr Komplexität gibt es nicht.
Ich lese gewohnheitsmäßig Quelltexte, und ich bin immer wieder darüber erschüttert, wie einfache Programmierungen von weniger erfahrenen Programmierern künstlich komplex gemacht werden. Nicht jede kleine Anwendung - und die Virtuelle Zockhalle ist eine kleine Anwendung - bedarf einer Flexibilität, die eher für die Programmierung eines Webbrowsers oder eines Office-Paketes angemessen wäre. Wo andere Menschen die Implementation ihrer Datentypen hinter Iteratoren verstecken, verwende ich eine for-Schleife, die keinen Bloat erzeugt und in performanten Maschinencode übersetzt werden kann. Sicher, das sieht ein bisschen nach den Achtziger Jahren aus, aber es ist auch hinreichend.
Ich wollte, das Feature Einfachheit in der Programmierung machte mehr Schule. Wir müssten uns alle viel weniger darüber wundern, warum die Wartezeit bei der Benutzung eines Computers scheinbar völlig unberührt von allen technischen Fortschritten konstant bleibt.
Nur ein Beispiel: Ich schreibe diesen Text auf einem Celeron mit 2 GHz, auch schon ein etwas betagtes Gerät. Um diesen Text zu schreiben, benötige ich einen guten alten Texteditor. Ich nehme zu diesem Zweck die Mutter aller Bloatware, diesen Lisp-Interpreter mit Editor-Frontend, den man GNU Emacs nennt. Dieser Editor startet trotz seiner erheblichen Komplexität auf meinem System schneller als der Standard-Texteditor des GNOME-Desktop-Projektes, obwohl letzterer bei weitem nicht so reich an Features ist. Er benötigt auch weniger Speicher und fühlt sich beim Editieren schneller an. Wie schaffen es diese freundlichen Leute, die uns GNOME gegeben haben, eigentlich, so einen Bloat aus einem einfachen Editor zu machen?
Sie schaffen es, indem sie diesen Editor »elegant« und »modern« programmieren. Das fängt mit den GNOME-Bibliotheken an, die vor allem ein Wrapper um das Gtk+-Toolkit sind, das wiederum ein Wrapper um die Bibliotheken des X-Servers ist. Schon Gtk+ ist schlecht, denn dort wird die späte Bindung realisiert, indem Messages an Objekte gesendet werden. Das ist an sich keine so schlechte Idee, aber dass man die Messages als Strings implementiert, die dann zur Laufzeit in einem großen Hash aufgesucht werden müssen, um letztlich die aufzurufende Funktion zu ermitteln, ist ein bisschen blöd gedacht (wenns auch sein Vorbild in Motif hat). GNOME wickelt eine weitere Schicht um diesen Wrapper um einen Wrapper, und zwar die fetteste. Aus dem täglichen Irrsinn nur ein Beispiel: GNOME speichert die Konfiguration der Anwendungen typischerweise in XML-Dateien, es muss also zum Einlesen einfacher Konfigurationsinfos ein fetter und auch für ganz andere Zwecke geeigneter XML-Parser gestartet werden. Und weitere Konfigurationen werden für Plugins des Editors geparst. Die Gedenksekunden zum Start des Editors wundern einen gar nicht mehr. Auf meinem System werden beim Starten eines gedit insgesamt vier Sekunden CPU-Zeit benötigt. (Die Wartezeit liegt bei für ein kleines Programm unerträglichen gut zehn Sekunden.) Bevor er auch nur sein Fenster darstellt, werden 2830 Dateien für 3083 Lesezugriffe und 186 Schreibzugriffe geöffnet. Knapp 50 MB Speicher werden von diesem Editor belegt. Das Ding mag »elegant« und »modern« sein, aber es ist auch unbrauchbar - zumal auch das Editieren von Text darin recht träge ist.
Programmiersprache ist C, ohne Postinkrement-Operator. Der Stil ist altmodisch und performant. Ein Ziel bei der Programmierung war es, dass die Virtuelle Zockhalle auch auf betagteren Rechnern gut laufen soll. Dieses Ziel ist erreicht.
Ein Funktionspointer, also die Adresse von ausführbarem Code im Speicher, ist ein elementares Konzept eines Computers, lässt sich direkt in Maschinencode übersetzen und ist damit unschlagbar performant. Jedenfalls performanter als die lustigen Konzepte der späten Bindung in C++, die langsam sind und den erzeugten Code erheblich aufblähen. Wenn sie beim Anblick eines Pointers einen kalten Schauder bekommen, denn werden sie beim Anblick der Quelltexte der Virtuellen Zockhalle aus dem Gruseln nicht mehr herauskommen.
An allen nur denkbaren Stellen werden Funktionspointer verwendet, etwa, um die Implementation eines Automaten von seiner graphischen Darstellung zu trennen oder um die Implementation des Frameworks von den konkreten Automaten zu trennen oder, oder, oder. Es ist gar nicht so schlimm, wie es auf dem ersten Blick aussehen mag. Es ist einfach nur das, was Programmierer in modernen Sprachen als Funktionsaufruf mit später Bindung coden.
Eine ausführliche Anleitung, wie bei der Programmierung eines neuen Geldspielgerätes vorgegangen wird, habe ich im Benutzerhandbuch für die virtuelle Zockhalle gegeben. Ich mag das daher an dieser Stelle nicht noch einmal wiederholen.
1.7.3