BASIC übersetzen Teil 2

Der Tumbau zu Babel

(Teil 1)

Als ich 1984 meinen ersten Heimcomputer bekam, den gebrauchten VideoGenie I meines Vaters, gehörte ich endlich dazu – zu denjenigen, die ihre Freizeit mit Spielen und Programmieren verbringen konnten. Einem Freund aus meinem Dorf, der einen C64 besaß, erzählte ich sofort von meinem neuen Computer und bat ihn, mir ein paar seiner Kassetten mit Spielen und BASIC-Programmen auszuleihen, damit ich sie über den eingebauten Datenrecorder meines Computers laden konnte. Was für eine Enttäuschung, als ich feststellte, dass es nicht funktionierte: Mein Computer konnte nichts mit den C64-Programmen anfangen – ja, er konnte nicht einmal das Format der Speicherungen auf der Kassette lesen. Es war, als würden die Systeme zwei völlig unterschiedliche Sprachen sprechen.

Es dauerte eine Zeitlang, bis ich begriff, dass sie das tatsächlich taten. Ich versuchte BASIC-Programme aus der Zeitschrift HC – Mein Home-Computer, die für Schneider CPC, Atari XL, Spectrum oder C64 entwickelt worden waren, in meinen TRS-80-Clone einzugeben. Schon beim Eintippen stellte ich fest, dass viele der Befehle in meinem BASIC gar nicht vorhanden waren oder anders funktionierten. Eine endlose Kette von „Syntax Errors“ bestätigte dann meinen Verdacht: Mein Computer und sein BASIC waren einfach nicht kompatibel …

Konvertiten

Was ich damals nicht wusste: Ich war mit meinem Problem nicht allein – vor allem nicht in der TRS-80-Gemeinde. Als Ende der 1970er Jahre die „Trinity“ (Apple II, PET 2001 und TRS-80) erschien, entstanden kurze Zeit darauf Usergroups, Newsletter und Zeitschriften, die sich mit diesen Systemen beschäftigten – jedoch zumeist nur mit einem davon. In der Regel wurde über diese Papier-Netzwerke auch Software übertragen – in Form abgedruckter BASIC-Listings. Und da der Markt noch jung war, gab es noch kaum professionelle Software für jeden Bedarf und für jedes der drei Systeme. Also wurde vieles selbst programmiert. In Zeitschriften, die alle drei Plattformen abdeckten, erschienen auch BASIC-Programmlistings für jede der Maschinen. Und genau an dieser Stelle dürfte bei den Hobbyisten der Wunsch entstanden sein, BASIC-Programme eines fremden Systems auf das eigene anzupassen.

Ab Anfang der 1980er Jahre erschienen Bücher, die Computerbesitzer dabei unterstützen sollten, BASIC-Programme zu adaptieren. Die Motive, Strategien und Werkzeuge unterschieden sich dabei von Autor zu Autor. In meinem Beitrag möchte ich die Geschichte dieser Anleitungen, ihre Vorgehensweisen und das, was sie über die BASIC-Dialektologie mitteilen, zusammenfassen. Dabei werde ich auch ein paar Überlegungen zu der Frage anstellen, welchen Erkenntniswert solche Übersetzungshilfen und die Übersetzungen selbst besitzen – und welches Bild von Sprache dahinter steht.

Tatsächlich richten sich die ersten Bücher zum Thema zunächst ausschließlich an die Besitzer der drei ersten kommerziellen Heimcomputer-Systeme. Zwar sind schon ein paar Jahre zuvor in Informatik-Sammelbänden Beiträge erschienen, die die Dialektvielfalt von BASIC kritisierten und gängige Mainframe- und Minicomputer-BASIC-Dialekte miteinander vergleichen. Doch diese Vergleiche behandelten erstens Spracheigenschaften, die heimischen Anwendern fremd gewesen wären (etwa die Berechnung der Determinante einer Matrize) und sie verglichen BASIC-Implementierungen für Maschinen, die weit außerhalb der Reichweite von Privatanwendern lagen. Ziel dieser Darstellungen war es vor allem, Unternehmen eine Orientierung zu bieten, welcher Computer für sie geeignet sein könnte – basierend auf dem jeweils verfügbaren BASIC-Dialekt und dessen Funktionen, die für das geplante Einsatzgebiet erforderlich waren.

Warum Übersetzen?

Tatsächlich wurde dieses Motiv auch in den später für Heimcomputer erscheinenden Büchern angegeben. Immerhin stand mit dem Erwerb eines Computer eine Investition ins Haus, die kostspielig war. Und wollte man beispielsweise Tabellenkalkulation mit seinem Computer machen, dann wäre es vielleicht unnötig gewesen, wenn dieser über Grafik- und  Soundfähigkeiten verfügte. Einkaufshilfe zu leisten, war jedoch nur einer der Gründe, BASIC-Dialekte miteinander zu vergleichen. Manch einer mag sich den Computer angeschafft haben, weil er professioneller Software-Entwickler werden wollte. Dann wäre es gut, nicht nur für ein System programmieren zu können, sondern für möglichst viele – auch dieses Motiv wird in den Büchern genannt und von ihnen bedient.

Das Verstehen und Übersetzen von fremden Programmen, um sie auf dem eigenen Computer zum Laufen zu bringen, steht jedoch bei allem Publikationen im Vordergrund (manchmal auch das Übersetzen von Programmen für die eigene Plattform auf andere Systeme – quasi als Dienstleistung für andere Computerbesitzer). Nicht zuletzt bedienten die Bücher aber auch Computerinteressierte, die einfach erfahren wollten, wie stark der jeweilige BASIC-Dialekt ist – und wie stark er vom (damals bereits veralteten) ANSI-Minimal-BASIC-Standard abweicht. Hier galt: Gutes BASIC ist voll abwärtskompatibel zu ANSI-MIN, fügt dem Standard-Befehlssatz aber auch möglichst vieles hinzu. Je mehr Computer in den folgenden Jahren erscheinen, desto stärker rückte der Vergleichsaspekt aber in den Hintergrund und desto häufiger dienten die Bücher (und später auch Poster) als Plattform-übergreifende Referenzwerke zum Nachschlagen von BASIC-Funktionen. Denn mit einem Buch, das – wie das in drei Auflagen erschienene BASIC Handbook von David A. Lien – möglichst viele Dialekte abdeckt, kann die größte Käuferschicht adressiert werden.

Referenzwerke

Und so wuchs der Umfang der behandelten Dialekte von Publikation zu Publikation an: Zu den Büchern über die Trinity-BASIC-Dialekte gesellen sich schon bald Darstellungen, die auch TI-99/4-, Atari-, IBM-PC-, C64- und Sinclair-BASIC zum Vergleich heranzogen. Kleine Publikationen, wie das 1985 erschienene BASIC-Dialekte verstehen und vergleichen des deutschen Autors Hans-Joachim Sacht wagen sich dann schon 20 zu dieser Zeit populäre Heimcomputer in den Fokus zu nehmen. Und die letzte Auflage des oben erwähnten 1986 erschienen Buchs von Lien ist mit 862 Seiten nicht nur mehr als doppelt so dick wie die erste (die 1979 mit 360 Seiten publiziert wurde), sondern nimmt für sich in Anspruch sämtliche zu dieser Zeit existierenden BASIC-Dialekte in seinen 600 Beiträgen enzyklopädisch abzudecken.

Mit dem Anwachsen der behandelten Dialekte ändern sich aber auch Stil und Aufbau der Publikationen. War es anfangs noch möglich jeden der drei Dialekte mit den beiden anderen detailliert zu vergleichen (die noch 1984 in Deutschland verspätet erschienene Publikation BASIC-Dialekte im Vergleich leistet dies für die Trinity in seinen drei Großkapiteln), so werden die Gegenüberstellungen bald schon tabellarisch und als selbst dafür der Platz auf einer Buch-Doppelseite nicht mehr ausreicht, alphabetisch. Einige Autoren machen sich noch die Mühe die Schlüsselwörter systematisch zu gruppieren, so dass nicht Sinus-Funktion zwischen Diskettenformatier- und Zeilen-Renumerierungsanweisung steht. Mit dem Anwachsen der Schlüsselwort-Menge werden die Anmerkungen pro Eintrag jedoch kürzer, bis sie zu bloßen Schlüsselwort-Tabellen schrumpfen, wie etwa auf dem berühmten Poster BASIC Converter Chart ’84, das einer Ausgabe der Zeitschrift Personal Computer World beilag. Schon fast absurd mutet diesbezüglich der Faltplan Die große BASIC Referenztabelle der 51 Dialekte, im selben Jahr beim deutschen Luther-Verlag erschienen, an: Nur schwer handhabbar versammeln sich darauf neben weitläufig bekannten Dialekten (Atari, TRS-80, Apple, …) Darstellungen zu BASIC-Versionen von Taschenrechnern, Minicomputern und Exoten (PSI 900 Kontron, …). Auseinandergefaltet ist die Karte über ein Quadratmeter und groß mit nahezu mikroskopischer Schrift bedruckt.

BASIC Literacy

Um zum Ausgangsproblem zurückzukehren: Die meisten Publikationen haben in ihrem Zentrum Angebote zur Lösung des Übersetzungsproblems. Kaum einer der Autoren greift dafür auf Methoden der Übersetzungswissenschaften (Komparatistik) zurück – obgleich alle BASIC wie eine Sprache behandeln und seine Dialektvielfalt mit der natürlicher Sprachen vergleichen: „Wenn Sie dachten, dass jeder Computer, der BASIC ausführt, jedes BASIC-Programm ausführen würde, haben Sie inzwischen festgestellt, dass Sie leider falsch lagen. Ähnlich wie Franzosen, die nur ‚französisches Französisch‘ akzeptieren und ‚Frenglisch‘ offen verachten, wird Ihr Computer keine BASIC-Programme akzeptieren, die nicht in seinem spezifischen Dialekt geschrieben sind“, so Bill Crider etwas augenzwinkernd in der Einleitung seines Buchs BASIC Program Conversions. Larry Noonan sieht in hinter der Arbeit sogar eine bildungspolitische Aufgabe, wenn er im Vorwort seines Buchs Basic BASIC-English Dictionary schreibt: „Wir hören immer öfter, dass Menschen ‚computerliterat‘ werden sollten, damit Computer von jedermann genutzt und genossen werden können. Das Basic BASIC-English Dictionary behandelt zwei Aspekte der Computerkompetenz: Computersprache und Programmierung.“

Einige Autoren listen, bevor sie ihre Übersetzungsleitfäden darlegen, zunächst einmal die Gründe auf, die eine Übersetzung erst notwendig machen: die Unterschiede der Hardware-Plattformen, der BASIC-Sprachentwickler aber auch der Programmierstile des Autors und Lesers, womit sie schon gleich schon andeuten, dass es auch schwierig bis unmöglich zu übersetzende Programm(teil)e geben könnte: Etwa PEEKs und POKEs oder gar Maschinensprache-Hex-Kolonnen von einem System auf ein anderes zu übertragen. So etwas „erfordert erhebliches Nachdenken“, wie Sacht in seinem bereits erwähnten Buch etwas euphemistisch warnt. In seinem nur ein Jahr später publizierten Buch BASIC-Dialekte liefert er eine interessante Liste von 32 Testprogrammen, mit denen ein Nutzer herausfinden kann, zu was sein BASIC überhaupt in der Lage ist. Auch diese Vorarbeit ist lohnenswert – kann man als ‚ordentlicher‘ Programmierer doch noch einige ‚dirty tricks‘ seines Dialektes lernen – etwa, dass man bei einigen BASIC-Dialekten zur Speicherersparnis die Sprungziel Zeile 0 nach GOTO einfach weglassen kann.

Übersetzungsschritte

Interessanterweise beschäftigt sich nur einer der Autoren mit der Frage der Rechtmäßigkeit von Programmübersetzungen. Zwar sind die häufig in deutschen Zeitschriften publizierten BASIC-Listings anzutreffenden “Copyright”-Hinweise nur “Papiertiger”, zeigen jedoch, dass der Autor es nicht möchte, dass sein Programm kopiert wird (was eine Übersetzung mit einschließt). Hier empfiehlt Crider in einem eigenen Unterkapitel den Autor zu kontaktieren und um Erlaubnis zu bitten oder juristischen Rat einzuholen – vor allem dann, wenn man mit der Übersetzung vorhat, Geld zu verdienen. Von der Übersetzung kommerzieller Programme rät er gleich ganz ab oder empfiehlt eine Vertragsvereinbarung mit dem Hersteller einzugehen. Die Tatsache, dass ein BASIC-Listing irgendwo abgedruckt wurde mit der Intention, dass die Leser es abtippen und nutzen ist also noch längst kein “Public Domain”-Freibrief. Dies gilt es übrigens auch heute noch zu beachten.

Die konkrete Übersetzungsarbeit habe ich aus allen mir vorliegenden Publikationen zu einer To-Do-Liste amalgamiert. Der Übersetzungsprozess lässt sich in drei große Teile gliedern: Am Anfang steht die Analyse des zu übersetzenden Programms. Hierbei sollte der grundsätzliche Zweck des Programme be/erkannt sein (was selbstverständlich ist, denn sonst würde man es ja nicht konvertieren wollen). Dann schlagen fast alle Autoren vor, das fremde Listing in logische Blöcke aufzuteilen und sich den Aufbau (etwa durch Flussdiagramme) jedes Blocks grafisch zu vergegenwärtigen. Nicht unwichtig erscheint es auch, vorab einzuschätzen, ob der RAM-Speicher des eigenen Systems überhaupt groß genug ist, um die Übersetzung aufzunehmen. Um hier Probleme zu vermeiden, schlägt Herwig Feichtinger in seinem 1982 erschienen Buch Basic für Mikrocomputer „Radikalkuren“ (sic!) vor: „In bestimmten Fällen ist der Programmierer gezwungen, jede Rücksichtnahme auf Änderungsmöglichkeiten, Editierbarkeit, Übersichtlichkeit und System-Kompatibilität fallen zu lassen, um ein recht umfangreiches Programm ‚mit Gewalt‘ in einen Computer mit eingeschränktem Speicherplatz zu pressen.“

Zur Analyse gehört die intensive Arbeit mit dem Programmausdruck des Source-Listings dazu. Gut wäre es, wenn Screenshots des Programms daneben lägen – insbesondere, wenn man keinen Zugriff auf den fremden Computer hat. So lassen sich Ausgaben/Ergebnisse des zu adaptierenden Programms besser abschätzen. Das Listing sollte dann auf problematische Elemente (maschinennahe Befehle wie POKE, USR usw.) und ähnlich lautende, aber anders funktionierende Schlüsselwörter (RND funktioniert auf einigen Systemen unterschiedlich) untersucht werden. Mehrbefehlszeilen sollte man gedanklich gleich in Ein-Befehls-Zeilen umwandeln und – ganz wichtig – eine Variablenliste erstellen, aus der auch die Bedeutung der Variablen für das Programm hervorgeht.

Die Übersetzung selbst als zweiter Schritt kann auf vier unterschiedlichen linguistischen Ebenen stattfinden: Man kann einfach die Programm-Semantik übertragen, das heißt, das fremde Programm auf Basis seiner Ein- und Ausgaben auf dem eigenen Computer emulieren, ohne dem fremden Code dabei allzu viel Beachtung zu schenken. Man kann aber auch die analysierten Programm-Module einzeln in Module des eigenen Dialekts übersetzen (und dabei feststellen, dass es für manche mehrzeilige Routinen im eigenen BASIC dedizierte Befehle gibt – oder umgekehrt, zum Beispiel beim Variablenwert-SWAP). Als drittes kann man versuchen, Programme auf der Befehlsebene zu übersetzen und einfach für jedes fremde Schlüsselwort eines im eigenen Dialekt zu finden. Von dieser Vorgehensweise wie auch vom zeilenweisen Übersetzen des Programmcodes raten aber alle Autoren ab, weil dies zu ineffizienten und manchmal dysfunktionalen Ergebnissen führt. Schließlich kann man – und muss man manchmal – auch die jeweilige Maschinenfunktion, die der fremde Befehl auf seinem System ausführt, auf dem eigenen emulieren. Dies ist insbesondere bei audiovisuellen Ausgaben und peripheriespezifischen Befehlen angebracht. Das fremde System hierfür zu kennen oder gar zu besitzen, wird dabei als Vorteil beschrieben – wie man sich unschwer vorstellen kann. 

Beim Schreiben des Programms sollte man ausreichend Platz zwischen den Zeilen lassen (10er-Abstände), Subroutinen bei glatten Hunderter- oder Tausenderzeilen beginnen und mit REMs nicht sparen. Diese helfen beim späteren gedanklichen Nachvollzug des eigenen Programms und können nach erfolgter Arbeit wieder gelöscht werden. Der Vergleich des fremden mit dem eigenen BASIC-Dialekt kann schließlich aber auch ergeben, dass sich das Programm überhaupt nicht auf den eigenen Computer portieren lässt – etwa, weil wichtige Hardware-Funktionen fehlen, zu wenig Speicher vorhanden ist, das eigene System/BASIC zu langsam ist oder die Maschinensprache-Funktionen unbekannt sind. Dann – und das verschweigt keiner der Ratgeber – sollte man lieber früher als später aufgeben und sich professionelle Hilfe (beim Übertragen) suchen bzw. ein Programm mit ähnlicher Funktion kaufen – oder gleich einen neuen Computer.

Der dritte große Schritt ist nun das Testen und Debuggen des übersetzten Programms. Hier kann man zum Glück auf die Ausführung(en) des eigenen Computers zurückgreifen: Welche Fehler tauchen wo auf? Wie und wo verändern sich Variablenwerte? Wie sehen die Ausgaben auf dem Bildschirm (im Vergleich zur Vorlage) aus? Hier können Hilfstools eingesetzt werden – etwa Programm-Tracing mit TRON/TROFF sofern vorhanden, PRINTen von Variablenwerten, einfügen von Test-Befehlen und BREAK-Kommandos, um das Programm an bestimmten Stellen zu unterbrechen. Auch hier wird vorgeschlagen, das Debugging modulweise durchzuführen, um nicht den Überblick zu verlieren. Dabei zeigt sich, dass es sich gelohnt hat, die Ratschläge bei der Programmerstellung berücksichtigt zu haben.

END

Im Ergebnis einer solchen Programmkonvertierung hat man nicht nur ein neues Programm für den eigenen Computer, sondern auch einiges gelernt – über die Möglichkeiten/Unmöglichkeiten des fremden und des eigenen BASIC-Dialekts. Vieles, was sich nicht direkt oder nicht einmal indirekt übersetzen lässt, ist „Lost in Translation“ und zeigt, dass BASIC-Dialekte hier ein weiteres mal Ähnlichkeiten zu natürlichen Sprachen haben. Noonan anerkennt dies schon in seinem Buchtitel Basic BASIC-English Dictionary: Englisch (oder wahlweise Deutsch) ist die Zwischensprache, die Pivot-Sprache, wie man in der Informatik sagt: Eine sprachliche Brücke, über die die Elemente des einen BASIC-Dialektes zum anderen System hinüber getragen/übertragen werden, wobei einiges links und rechts herunter fallen kann. Insbesondere dann, wenn man nur den papiernen Ausdruck des fremden Programms vor sich hat, zeigt sich, wie der menschliche Sprachverstand über BASIC nachdenkt – und manchmal daran scheitert. Insbesondere der Umstand, dass Computerprogramme nicht linear gelesen/verstanden werden können, sondern im Kopf – mit allen Sprüngen, Schleifen und Rekursionen – vor-vollzogen werden müssen, verdeutlicht den Unterschied zu Übersetzungen natürlichsprachlicher Texte.

Mir wurde das bewusst, als ich anfing die in der HC-Zeitschrift abgedruckten Programme auf meinen VideoGenie I zu übertragen. Relativ bald schon habe ich die Finger von Spielelistings für Atari-, Commodore-, Schneider- und Sinclair-Computer gelassen und mich Programmen zugewendet, die eher mit Textein- und -ausgaben arbeiten. Dabei kam mir dann entgegen, dass doch irgendwie die meisten Computer mit einem BASIC-Interpreter von Microsoft ausgestattet waren, der auch unter der Haube meines Systems arbeitete. Tatsächlich – und das wurde mir erst bewusst, als ich dann meinen VideoGenie I gegen einen Atari 800 XL austauschte – hatte ich sogar den Computer besessen, der quasi als „Inbegriff“ des Microsoft-BASIC-Systems galt, wie Sacht schreibt: Das TRS-80-BASIC sei „eine Art ‚BASIC-Hochsprache‘, die auf (fast) allen Computern läuft.“ Damit konnte ich den Atari vom ersten Tag an gut programmieren. Wenn bloß diese verflixte Zeichenketten-Behandlung nicht gewesen wäre …

(Zuerst erschienen in RETURN, Ausgabe 64.)