Computerprogramm und Programmiersprache (3)
Wenn man Computerprogramme als speziellen Text (Sourcecode) definieren will, muß man erst einmal genauer hinsehen, wie sich Text im Computer überhaupt darstellt, um dann zu bestimmen, in welcher Weise sich „normaler” Text von Sourcecode unterscheidet.
Dabei muß man sich einmal mehr klar machen, daß jede Datei nur aus Zahlen besteht, also auch eine Textdatei. Text sieht man auf einem Computerbildschirm erst dann, wenn diese Zahlen von einem Programm als Text ausgedeutet werden. Im einfachsten Fall wird jedes Byte einer Datei als Index benutzt, der in eine Tabelle aus Buchstaben verweist (der ASCII-Zeichensatz ist die früheste Standardisierung solch einer Tabelle). In moderneren Standards, die auch außereuropäische Zeichen umfassen, kommt man mit einem Byte nicht aus. Um Speicherplatz zu sparen, werden Zeichen, deren Index mehr als ein Byte umfaßt, mit einem speziellen Steuercode eingeleitet, aus dem hervorgeht, wie viele Bytes dieses eine Zeichen definieren (Unicode, UTF-8 - die Einführung von Joel Spolsky ist sehr brauchbar). Schon an dieser Stelle wird klar, daß selbst Programme, die einfach nur eine Datei als Text anzeigen wollen, durchaus einige Intelligenz realisieren müssen.
Noch komplexer wird es, wenn man auch Formatierungen und Text-Atribute in die Ausgabe packen will. Die Datei beinhaltet jetzt nicht nur den reinen Text, sondern eben auch Formatierungen, und muß von einem entsprechenden Programm dechiffriert werden. Ein Beispiel wäre eine HTML-Datei, in der Absätze, Überschriften etc. definiert werden, was vom Parser eines Browsers interpretiert werden muß, bevor der Text auf den Bildschirm ausgegeben werden kann.
Man findet häufig die Auffassung, daß schon ein HTML-Dokument ein Programm darstellt. Demzufolge wäre aber auch ein „Word”- oder RTF-Dokument ein Programm, weil auch hier Metainformationen abgelegt sind, die von einer Engine[1] in der Textverarbeitung decodiert werden müssen. Aber schon die Ausgabe einer ASCII-Datei entspricht ja nicht dem Aufschlagen eines Buches, sondern ist die Entschlüsselung eines Codes.
Ich schlage vor, Sourcecode von übrigem Text zu trennen, indem man sagt, Sourcecode sei nicht nur lesbar, sondern für das Operieren jener Maschine verantwortlich, die (ihren eigenen) Text lesbar macht.
„Normaler” Text soll auf den Bildschirm gebracht werden, dann ist alles erledigt. Die Zahlen in der Datei werden lediglich decodiert. Sourcecode hingegen ist zwar auch auf den Bildschirm lesbar, muß aber in einem weiteren Schritt „zurück” auf die Hardware, um die Operationen des Computersystems zu bestimmen.
In beiden Fällen ist ein Programm nötig, das das Datenformat interpretiert, in dem der Text abgelegt ist (ASCII, HTML, etc.). Im Fall von Sourcecode wird ein weiteres Programm gebraucht, das Maschinencode generiert (der Compiler).
Wenn man diese Definition akzeptiert, hat man eine klare Trennung, spricht dabei allerdings all jenen Texten die Eigenschaft ab, Sourcecode zu sein, die bestimmte Aspekte lediglich steuern. Das betrifft z.B. HTML, aber auch Skripte, die das Aussehen von Websites definieren (CSS) und deren Autoren man normalerweise als Programmierer bezeichnet.
Aus der Sicht des Programmierers ist ein Programm die Differenz zwischen Programm und Sourcecode. Re-entry: ein Programm wird gebraucht, um ein Programm zu generieren.[2]
- [1] Ich verstecke mich mal hinter dem englischen Begriff. „Automat” paßt hier ebenso wenig wie „Programm”, weil mal es nicht mit einem System zu tun hat, das auf Autopoiesis beruht. In- wie Output definieren sich hier über eine klar definierte „Schnittstelle” - ein Begriff, den man in die Systemtheorie erst einfügen müßte (zumindest soweit ich das Thema überblicke).
- [2] Richtig lustig wird dieses re-entry übrigens, wenn man einen Compiler entwickelt - wenn man z.B. einen C-Compiler in C schreibt, ist der in der Lage, sich selber zu übersetzen.