Interaktivität und Benutzerfreundlichkeit sind die Hauptmerkmale heutiger Mikrocomputersysteme. Ihre Entwicklung läßt sich an dem zunehmend größer werdenden Prozentanteil an Hardwarekosten und Prozessorzyklen messen, die diesen Funktionen zugordnet sind. Während die Benutzerschnittstelle hier eine Revolution durchmacht, bleiben die Programmierverfahren davon relativ unberührt auf dem Stand des hergebrachten Edit-Compile-Link-and-Go-Zyklus (ECLG). Dies verhindert, daß der Programmierer optimal in seinem Produktivitätsprozeß vom Computer unterstützt wird. Mit Hilfe der heute vorhandenen interaktiven Kriterien ist eine wesentlich effektivere Programmierung möglich. Außerdem kann die Diskrepanz zwischen Programmierung und Anwendernutzung dadurch entscheidend verringert werden. Als Beispiel eines interaktiven Ansatzes dient das Programmiersystem "Forth".
Interaktion ist durch Kommunikation bedingt. Kommunikation erfolgt über Kanäle. Der wesentliche Kommunikationskanal ist die Bildschirmdarstellung. Heute, wie vor zehn Jahren, hat man zur Informationsdarstellung einen Bildschirm mit der Standard-Kapazität von 2000 alphanumerischen Zeichen zur Verfügung. Trotz der gewaltig gestiegenen Prozessorleistung, die nun einem einzigen Bildschirm zur Verfügung steht, hat sich dieser Parameter nicht geändert. Es ist lediglich ein Grafik-Modus hinzugekommen, mit etwa 700 mal 300 Punkten, Tendenz in Richtung 1000 mal 1000 Punkte. Das ist aber nur ein statischer Wert. Um einen solchen Bildschirm aufzubauen, braucht der Prozessor ein bis zwei Sekunden. Mit schnell wechselnden Bildschirminhalten wie etwa der "Filmdarstellung" ist sogar der Hochleistungsprozessor MC68000 der Lisa überfordert.
Kriterien des Dialoges
Trotz der offensichtlichen Einschränkung des Bildschirms ist dieser noch das schnellste Interaktionsmedium des Mikros. Eingaben des Menschen sind notorisch langsam, und um einige Zehnerpotenzen langsamer als das Reaktionsvermögen der Maschine. Tastaturen sind immer noch am schnellsten, aber schwer zu beherrschen. Maus und Spracheingabe sind bequem, aber erlauben heute noch nur sehr geringe Datenübertragungsraten. Andere Ausgaben des Computers, etwa Sprache, sind nur für Sonderfälle von Interesse. Es ist unmöglich für einen Menschen, sich eine sprachliche Ausgabe von etwa 1000 Zeichen im Gedächtnis zu behalten, die vom Computer gebotene Information muß nicht nur schnell kommen, sondern sie muß auch einen Grad von Permanenz haben. Mit diesen eng begrenzten Parametern muß also das Optimum von Interaktivität entwickelt werden. Daher geht die Hauptentwicklung in die Strukturierung der visuell dargestellten Information. Software-Engineering nimmt eine neue Komponente an, die sich sonst eher in den Bereichen der Kunst aufhält: Ästhetik. Eine gelungene Mischung von Komponenten, wie Gewürze in einer Speise.
Was ist der Effekt von Ikonen in den Lisa- oder Macintosh-Menüs? Eine Ikone ist ein grafisches Zeichen, also ein Bild. Während man bei dem Standard-ASCII-Zeichensatz, den zum Beispiel CP/M-Computer darstellen können, nur etwa 100 Zeichen zur Verfügung hat, Blockgrafik mit eingerechnet etwa 200 Zeichen, kann man bei einer Ikone beliebig viele Bilder erzeugen. Eine Ikone ersetzt typischerweise einen ganzen Namen (etwa die Ikone des Abfalleimers, um das Verwerfen eines Textes oder einer Datei zu bezeichnen.) Sie enthält damit auch ein Konzept.
Eine Theorie der Ikonen
Der Vorteil von Ikonen liegt in der Kürze. Es ist sehr leicht möglich, am Rand des Bildschirms einige 20 Ikonen aufzureihen, als Anzeige für alle Möglichkeiten, die der Benutzer in der augenblicklichen Situation zur Verfügung hat. In einem Programm wie Wordstar zum Beispiel, wo man dasselbe mit dem Hilfs-Text in alphabetischer Schreibweise versucht, ist der Unterschied schnell zu sehen: Der alphabetische Text nimmt so viel Platz ein, daß der verbleibende Rest des Bildschirms ungemütlich klein erscheint. (Dies kann man auch als ein Problem des Informations-Abstands bezeichnen. Je mehr Buchstaben auf einem Schirm sind, desto schlechter kann man die einzelnen Worte voneinander unterscheiden, und da Hilfstexte generell wichtige Information sind, gehen sie sozusagen "unter".) Die vielen Worte, die im oberen Drittel des Bildes erscheinen, wirken nicht hilfreich, sondern verwirrend. Der Benutzer hat Schwierigkeiten, sich auf den Text zu konzentrieren, an dem er arbeitet, und wenn er Hilfe braucht, hat er Probleme, sich aus den angebotenen Hilfen die herauszusuchen, die er benötigt. Folge: Sobald er kann, schaltet er das Hilfsmenü für immer aus.
Schlußfolgerung: Der Bildschirm heutiger Computer ist zu klein, als daß sich Hilfstexte und Arbeitsfeld miteinander vertragen könnten. Wenn das Programm zwischen Hilfstext und Arbeitsfeld hin- und herschaltet, braucht es meist zu lange um von einem zum anderen zu kommen (Diskettenzugriff), und der Benutzer hat, bis er in dem anderen Modus ist, schon wieder vergessen, was es eigentlich war, was er brauchte.
Ein Menü, ob es nun in alphabetischer Schreibweise oder als Ikonensammlung vorliegt, ist Teil einer Hierarchie von Funktionen. Nach dem Eingangsmenü folgen meist noch einige weitere Stufen, in denen zu weiteren Funktionen verzweigt wird. Alphabetische Menüs werden bei mehr als sieben Auswahlmöglichkeiten unübersichtlich. Wie das Lisa-Menü zeigt, können an den Rändern des Schirms zwanzig bis dreißig Ikonen noch komfortabel unterschieden werden. Damit muß man bei alphabetischen Menüs bei gleicher Funktionszahl mehr Stufen des Menüs durchlaufen, was längere Zeit dauert. Sind mehr als drei Ebenen einer Hierarchie zu durchlaufen, wird die Hierarchie selber unübersichtlich und für den Benutzer verwirrend.
Logische Hierarchien
Es ist wichtig, daß der Benutzer immer einen Überblick hat, auf welcher Ebene der Hierarchie und in welchem Zweig er sich befindet. Gebräuchliche Menüs haben zum Beispiel meist die weniger erfreuliche Eigenschaft, daß sie zwar anzeigen, wo der Benutzer hingehen kann, aber sie sagen ihm nicht, wo er gerade herkommt.
Es gibt keine Anzeige für die logische Ebene in der Hierarchie, weder absolut, noch in Relation zu anderen Möglichkeiten, auf der er sich befindet. Das aber ist nur für den Programmierer eine klare Sache, für den Benutzer nicht. Generell ist so etwas, wegen der geringen Informationsdichte eines alphanumerischen Bildschirms, nicht mehr darstellbar.
Ikonen und Fenster geben die Möglichkeit, den Kontakt zu anderen Ebenen der Hierarchie zu behalten. Effektiv hat der Benutzer mehrere logische Ebenen seines Programms im Zugriff. Die Ikone markiert in augenfälliger Weise den Unterschied. Das Zeichen hat nicht nur seine Bedeutung, sondern es markiert noch den logischen Unterschied. Es kennzeichnet die andere logische Ebene der Hierarchie. Erst, wenn der Benutzer mit dem Cursor auf die Ikone geht und mit dem Druck auf den Knopf der Maus diese öffnet, wechselt er die Ebene, steigt sozusagen in die Ebene der Ikone herab. Die Ikone expandiert, und wird damit zur "Jetzt-Realität" (siehe auch Hofstadter, Little Harmonic Labyrinth, S. 103). Diese Faktoren zu beherrschen, macht die spezielle Kunst der heutigen Softwareerstellung aus.
Nun haben Programmlistings ganz andere Eigenschaften als Textverarbeitungsfunktionen oder Business-Graphic. Wie kann man Kriterien die in diesen Anwendungen entwickelt worden sind, in die Programmierung nutzbringend einbeziehen?
Sprachen wie Fortran, Cobol und Basic beruhen auf dem Next-Instruction-Schema der Maschinensprache des Von-Neumannschen Computers. Der Programmzähler läuft automatisch eine Folge von Instruktionen entlang und verzweigt, wenn er einen entsprechenden Befehl findet, zu einer anderen Adresse. Der Computer, also die CPU, arbeitet die Instruktionen sequentiell ab, so wie sie durch den Programmzähler gegeben werden. Die Struktur eines Programms ist damit ebenfalls sequentiell, und dies drückt sich auch in den unterschiedslosen Folgen von Programmstatements in diesen Sprachen aus, die ihnen auch den Namen "Spaghetticode" eingebracht haben.
An dieser Situation hat sich auch durch Timesharing- und Online-Methoden nichts geändert. Auch wenn Programme mit dem Editor erstellt wurden, wird ein Stapel Lochkarten lediglich auf dem Papier mit einer Programmanweisung pro Zeile abgebildet. Die Bildschirmdarstellung eines Programms in einer solchen Sprache hat allerbestens eine gewisse Erleichterung des Editierens zur Folge, und ohne langwieriges Blättern im Programmlisting ist es nicht möglich, in einem Programm irgendetwas von seiner Funktion zu erraten.
Blockorientierte Sprachen wie Pascal ermöglichen ein gewisses Konzept der Strukturierung, da einzelne Blöcke andere aufrufen können, und diese wiederum andere. Damit kann man die Funktion einer Zentral-Kontrollstation in einem Block darstellen, eine Methode, die gegenüber dem linearen Modell der alten Programmiersprachen "eine Erinnerung" behält, wo auch Pascal ist zeilenorientiert, das heißt, es wird eine Anweisung auf eine Zeile geschrieben. Die einzelnen Programmblöcke sind daher meist zu groß, um auf einen einzigen Bildschirm zu passen. Da compilierte Programme in verschiedenen Arbeitsgängen editiert und getestet werden, ist der Bildschirm für die Programmerstellung von untergeordneter Bedeutung und lediglich eine Editierhilfe.
Vieles ist noch ungelöst
Die heutige bedienerfreundliche Software macht durch vielerlei Hilfestellungen das Lebens des unbedarften Benutzers leichter. Ein Programmierer hat zwar viele der dort gebotenen Hilfestellungen nicht nötig, aber auch Programmierung kann noch weiter vom Computer unterstützt werden. Vor allem im Bereich des Testens und Debuggens von Programmen ist noch viel möglich. Herkömmliche Programmiersprachen erlauben aus verschiedenen Gründen nur mit Mühe eine weitere interaktive Unterstützung, und sind deshalb schlecht in diese Richtung weiterzuentwickeln. Die Gründe dafür sind:
a) Die sehr geringe Darstellungsfähigkeit des Bildschirms, bei der mit der gebräuchlichen zeilenorientierten Darstellung der Programmiersprachen gerade 25 Anweisungen auf einen Bildschirm passen, 50 daß der Programmierer ohne Listing kaum etwas mit dem Bildschirminhalt anfangen kann. Dies ist ökonomisch in den nächsten Jahren zu ändern, da fast alle Systeme auf die 80x24-Darstellung genormt sind, und größere Bildschirme nicht nur wesentlich teurer sind, sondern auch größere Anforderungen an die Kanalkapazität der Ausgabehardware des Computers stellen (9600 Baud seriell ist schon für jetzige Darstellung langsam).
b) Herkömmliche Programmiersprachen sind zeilenorientiert, und die Anweisungen haben eine geringe Informationsdichte, was das Problem a) weiter akut macht.
c) Compilierte Sprachen, haben Probleme in der Arbeitsunterstützung des Programmierers in Form von Trace- und Online-Debugging. Nur ein interpretierendes System kann Online-Debugging-Unterstützung geben. Die meisten der heutigen interpretierenden Systeme unterstützen keine strukturierte Programmierung und sind im Verhältnis zu compilierten Systemen zu ineffizient in der Ausnutzung der Maschine.
Ein System, das interaktive Programmierung unterstützt, muß Trace ..auben, und eine relevante Darstellung von Programm-Information auf dem Bildschirm ermöglichen. Weiterhin muß es interpretativ arbeiten, und erlauben, die am Bildschirm erstellten Programmodule ohne weiteren Aufwand gleich zu testen.
Für interaktive Programmentwicklung kommen die Sprachen APL, Mumps, Forth und Logo in Frage. APL und Mumps haben den Titel "Write-only"-Sprachen erhalten, weil sie zusätzlich zur interpretativen Abarbeitung noch einen außerordentlich knappen Telegrammstil der Kommandos aufweisen (so ist der Zeichensatz von APL praktisch ikonisch, aber die Zeichen haben nur für geübte Mathematiker eine Bedeutung), und es ist möglich, ein ganzes, komplexes und funktionsfähiges Programm auf einem Bildschirm darzustellen. Die besondere Beliebtheit, die diese Sprachen in Insiderkreisen haben, erklärt sich aus dieser Eigenschaft.
Das Problem von APL und Mumps liegt in der fehlenden Strukturierung. Weder APL noch Mumps sind modular strukturierte Sprachen. Eine Anweisungsfolge kann nicht unter einem Namen vermerkt werden, und über den Namen aufgerufen werden. Eigenschaften dieser Art findet man aber in den Sprachen Logo und Forth. Beide Sprachen erlauben die Zusammenfassung von komplexen Anweisungsfolgen unter einem Namen. Die Auswirkung dieser Möglichkeiten soll an dem Beispiel von Forth weiterverfolgt werden.
Damit kann man an jedem Punkt eine Anweisungsfolge unter einem Wort zusammenfassen. Man hat damit den Charakter einer Ikone, die die Bedeutung der Operation in ihrem Zeichen enthält. Die Beziehung einer Ikone zu einem Ideogramm ist offensichtlich. Beide drücken eine komplexe Bedeutung aus. In einer Ikone ist das eine bildliche Projektion, in einem Ideogramm mehr eine logische oder abstrakte.
Der magische Screen
Das Wesentliche an dem Ikonengedanken ist, zu erkennen, wenn man ein Pascal-Programm, also eine moderne Programmiersprache, ansieht im Vergleich zu einem Lisa-Menü. Der Unterschied ist, daß in dem Programm die Information zwar (bei guter Programmierung) logisch strukturiert ist, aber sich diese Struktur über Seiten und Seiten von Programmlistings hinzieht. Ein Lisa-Menü - oder überhaupt ein Menü - gibt die Information, die es enthält, auf einem Blick, oder genauer gesagt, auf einem Screen des Video-Displays wieder.
Es gibt eine hierarchische Unterteilung von Menüs, die nacheinander durchlaufen werden, wo immer ein kompletter Informationssatz mit einem Blick zu erfassen ist und eine Auswahl getroffen werden kann. Die logische Unterteilung der Information ist bei Pascal wesentlich weiträumiger und bringt einen besonderen Nachteil mit sich, nämlich, daß die relevante Information, die man sucht, über viele Seiten Programmlisting verteilt ist und es einen höheren Aufwand erfordert, sie herauszufinden.
Es ist ein Prinzip der Forth-Programmierung, eine Unterscheidung in das Was und das Wie eines Programms zu machen und diese Unterscheidung auch räumlich zu trennen. Abstrakt heißt das: eine Kontrollstruktur und eine Verarbeitungsstruktur. In Pascal ist diese Unterteilung in Kontrollstruktur und Verarbeitungsstruktur zwar möglich, durch Module und Blocks, aber sie ist mit der Verarbeitungsstruktur vermischt.
In Forth hat sich der Programmierer durch die Besonderheit des Forth-Virtual-memory-Systems daran gewöhnt, seine Information in "Screens" unterzubringen, Blöcken von 1000 Zeichen, mit 16 Zeilen mal 64 Zeichen, noch ganz im Stil der ersten Dampfmikros, als der Computer noch maximal tausend Zeichen von ihrem sowieso sehr beschränkten Memory für ein "memory-mapped" Video erübrigen konnten.
Eleganz durch Einschränkung
Von diesen Screens waren, aus Gründen der Übersichtlichkeit etwa zwei Drittel als Füllraum freizulassen, so daß nur etwa 300 Zeichen zur Darstellung der relevanten Information übrigblieben. Dies hat die Programmierung in Forth in eine sehr ausgeprägte Strukturierung geführt. (Nebenfaktor: bei den frühen Mikrocomputern gab es auch keinen Drucker, bestenfalls ein ausrangiertes Teletype, so daß man auch tunlichst nicht viele Programmlistings machen wollte.)
Diese Struktur heißt: Komprimiere die relevante Information auf einen Screen von 300 Zeichen, und sorge dafür, daß Du dein Problem lösen kannst, ohne das Listing all der anderen Screens zur Verfügung zu haben, eine außerordentlich wirksame Methode des Trainings im Strukturierten Programmieren. Sie führte dazu daß man nicht nur strukturiert programmierte (Goto gibt es in Forth nicht), sondern auch noch, daß man hierarchisch programmieren lernte.
Hierarchische Programmierung
Das heißt: Das Problem mußte nicht nur maximal in Module unterteilt werden, sondern diese Module mußten auch noch in ihren Kommunikationsforderungen in 300 Zeichen erschöpfend beschrieben werden. Bei Programmiersprachen die mit Variablen arbeiten, ist dies einfach nicht machbar, aber mit dem Stack-Konzept war es möglich. Zudem war nur mit dem Return-Stack die Methode der geschachtelten Definitionen praktikabel. So fügten sich also viele verschiedene Bestandteile von denen die meisten Einschränkungen waren, zu einem Bild.
Hierarchische Programmierung heißt: Zu der Modularisierung in Funktionen, auch noch eine Unterteilung in logische Ebenen von Funktionen. Eine logische Typisierung. Allein Funktionen gleichen logischen Typus können miteinander in Kommunikation treten. Wenn man keine Variablen verwendet, ist nur der Stack als Datenverkehrsmedium zwischen Forth Worten (Unterprogrammen, ähnlich C-Funktionen) vorhanden, die in derselben Forth-Definition vorkommen, also, die auf derselben hierarchischen Ebene stehen. Es ist, in anderen Worten, ein orthogonales Kommunikationsmodell.
Fenster und Ikonen
Eine Hierarchie dieser Art ist es auf die sich heute die Fenster-Software hin entwickelt. Ein Fenster und eine Ikone stehen in einer graduellen Beziehung. Wenn man ein Fenster maximal verkleinert, wird es zur Ikone, bevor es völlig verschwindet.
Natürlich ist heutige Fenstersoftware noch nicht dort angelangt, und ein Fenster schrumpft schon lange vorher zu einem völlig nichtssagenden Stück Bildschirm zusammen, was leider bei all der Euphorie über diese Methodik noch nicht aufgefallen ist. Zum Beispiel hat es sehr wenig Sinn in einem Texteditor mehr als ein Split-screen-Schema einzuführen, weil kleinere Fenster nur in den wenigsten Fällen noch eine Aussagekraft haben. Betrachtet man aber den logischen Zusammenhang von Ikone und Fenster, wird klar, in welche Richtung die Entwicklung gehen muß und welchen Weg sie noch vor sich hat.
Die Ikone enthält die Information, die auf der entsprechenden typologischen Ebene der Kontrollstruktur relevant ist. Es ist eine Hierarchisierung von Informationsebenen, und eine Spezifizierung in bezug auf das Level in der Kontroll- oder Verarbeitungsstruktur, unter der Maßgabe, daß es in einem Blick erfaßbar sein muß.
Das Problem ist also das der Informationsverdichtung, eben der hierarchischen Informationsstrukturierung. Was muß an Darstellung noch vorhanden sein, wenn man die Ebenen der Abstraktion herauf- und hinuntersteigt?
Diese Elemente, die hierarchische Strukturierung der Information, und die Möglichkeit, immer alle relevanten Information auf einem Blick zur Verfügung zu haben, macht einen wesentlichen Faktor der Interaktivität aus.
Die Interaktivität von Forth drückt sich ebenfalls in seiner Entstehung aus. Forth ist ein Programmiersystem, das nicht hätte entstehen können, wenn es nicht in Interaktion gewachsen wäre.
Forth - Das Ein-Mann-Programmiersystem
Die Geschichte von Forth unterscheidet sich so gravierend von der Entstehung der anderen Programmiersprachen, daß sie auch hier erwähnt werden soll, und sie ist auch charakteristisch für seine speziellen Qualitäten.
Forth ist als Ein-Mann-Produktivitätssystem entstanden. Es ist das Werk einer einzigen Person - Charles Moore. Später beschrieb er sich und das Ergebnis seiner Arbeit als "der erste computerunterstützte Programmierer". Er hatte ein System geschaffen, mit dem er in optimale Interaktion treten konnte oder, wie man heute sagen würde, mit dem er in einen geschlossenen Feedback-Loop treten konnte. In der Biologie heißt dieses Konzept Symbiose oder Co-Evolution. Er trat mit seinem System in Interaktion, und verbesserte es dynamisch, bemerkte, daß er mit seinen eigenen Fähigkeiten an seiner Kreation gewachsen war, und gab sofort das Feedback, indem er diese Eigenschaften des Systems weiterentwickelte oder wieder einschmolz.
Eine solche Vorgehensweise war natürlich im Bereich der institutionellen Programmierung undenkbar. Diese Methodik ist aber die Wurzel von Forth und sie erklärt alles, was Forth heute ist.
Forth interaktives programmieren
Um das Bild des Interaktiven Programmierens noch abzurunden, soll hier ein Auszug aus einem Leserbrief in BYTE Magazine, in der Kolumne von Jerry Pournelle gebracht werden:
"Forth wird compiliert wie Modula-2 und Pascal, aber in Forth erfolgt die Compilation direkt nach der Definition des Wortes, und das neue Wort wird einfach durch seinen Aufruf aktiviert.
Die Direktheit der Compilation und die Kürze der Definition, die damit ermöglicht wird, versetzt den Programmierer in die Lage, mit dem Programm zu interagieren, während es geschrieben wird. In Situationen, in denen das Feedback der Aktionen im selben Augenblick erfolgt, kann man einen Bewußtseinszustand erreichen, in dem die Anstrengungen und die Erbgebnisse sich gegenseitig beeinflussen und das Bewußtsein mit dem Prozeß verschmilzt, so daß man in der Arbeit "aufgeht" - ein maximal produktiver Bewußtseinszustand. Dieser Bewußtseinsstand ist den meisten Künstlern vertraut. In ihrer Arbeit mit Pinsel, Bleistift oder Ton sind sie in direktem Kontakt mit ihrem Medium - sie können etwas ausprobieren, sich ansehen, was herauskommt, und das Resultat den nächsten Schritt beeinflussen. Es ist ein vertrautes Gefühl für Schauspieler, für Sportler, für alle, die ein direktes Feedback bekommen, während sie arbeiten.
Den meisten Programmierern ist das unbekannt, weil die meisten Programmiersprachen in einer Weise strukturiert und implementiert sind, daß eine Barriere für das direkte Feedback exisitiert, eine Mauer von Zeit und Prozeduren zwischen der Idee und dem Resultat. . .
Mit diesen Sätzen ist das Erlebnis des interaktiven Programmierens wohl angemessen beschrieben. Seine produktiven Auswirkungen können, zum Glück, sehr einfach und empirisch bewiesen werden: Man nehme einen Homecomputer, lade das Forth-System und fange an zu programmieren. . .
Empirisches Programmieren
Damit sind der Empirie alle Wege offen. Forth braucht keine 200 000-DM-Maschine, wie Lisp (als einzige vergleichbare Sprache), um überhaupt zum Laufen gebracht zu werden, sondern steht auf jedem Homecomputer zur Verfügung. Alle Eigenschaften von Forth lassen sich leicht nachprüfen, indem man sich an den Computer setzt und es ausprobiert.
Es ist erst in wenigen Arbeiten untersucht worden, daß die Produktivität der Programmierung durch empirische Vorgehensweise steigen kann, (Weinberg, Psychology of Programming) und interaktive Programmierung war bisher eher ein Anathema für alle Verfechter strukturierter Logik des Programmierens. Daß die interaktive Methode auch für die Programmierung Ergebnisse bringen kann, wird durch die Arbeiten an Sprachen wie Logo und Smalltalk, und durch die neuesten Entwicklungen auf dem Bereich der Benutzerunterstützung deutlich.
Und genau das ist Forth. Es ist ein empirisches Programmiersystem.
Interaktive Programmierung und selbstorganisierende Systeme
Dies sind also einige Ansätze zu dem Pradigma der interaktiven Programmierung. Das Besondere an dem Prinzip ist eine leicht zu zerstörende Balance. Es ist eine Balance zwischen vielen verschiedenen, und widersprüchlichen Faktoren. Diese Balance zeichnet Systeme aus, die wir allgemein als Leben bezeichnen, also die Welt der Organismen. Viele der Konzepte, die man zur Beschreibung lebendiger Systeme gefunden hat, lassen sich auch in Forth wiederfinden. Diese Konzepte kann man auch mit dem Oberbegriff: "selbstorganisierende" Systeme belegen.
Die Natur mit ihren Organismen ist das Paradebeispiel für ein selbstorganisierendes System. In der organischen Natur ist alles sozusagen "natürlich" geregelt. Die Prinzipien dieser Regelung sind also die Schlüssel zur Schaffung technischer selbst-organisierender Systeme. Ein sehr wichtiger Beitrag hierzu ist Douglas Hofstadters Buch "Gödel, Escher,
Bach", in dem er die Verbindungen der Computer und der natürlichen Systeme aufzeigt.
Ein Kernpunkt von Hofstadters Buch ist die Selbst-Referenz, ein Grundprinzip, das sich in allen selbstorganisierenden Systemen wiederfinden, läßt. Es bedeutet, daß alles sich durch Rückbezug von einfachen Kopien von sich selbst aufbaut, oder andersherum gesagt, es gibt kleine, universelle Bausteine, die sich regelmäßig zu immer größeren Komplexen zusammenfügen. Von diesem Punkt ist es dann kein weiter Weg mehr zu Forth. Hofstadter beschreibt die Regelmäßigkeit dieser Ordnung mit den Worten "Schrödingersche aperiodische Kristalle" und bringt als Beispiele einer solchen Ordnung Fractals und die Musik von Bach. Beide Strukturen sind aber in ihrer Esszenz Stack-Konstrukte. Damit ist die Stack-Struktur von Forth eine Widerspiegelung oder ein Morphiums der Organisationsprinzipien natürlicher Systeme.
Das Feedback-Prinzip, das Hofstadter auch Selbst-Referenz nennt, ist das Grund-Ordnungsprinzip der organischen Natur. Feedback ist das Element, mit dem der Programmierer in der Interaktion mit seinem Werkzeug sein Werkzeug erst schafft, es immer neu definiert, es seinen Vorstellungen anpaßt. Dies ist das Kriterium der CO-Evolution. Es ist ebenso das Kriterium eines neuen wissenschaftlichen Paradigmas, das nicht mehr objektivistisch, newtonisch und karthesisch ist, sondern relativistisch, und synergistisch. Es ist das Paradigma des Wissenschaftlers und seines Studiums als geschlossenes System, in dem der Forscher nicht das Objekt erforscht, sondern seine Interaktion mit dem Objekt, und erlebt, wie das "Objekt" zum Partner und Lehrer wird - ein Wachstumsprozeß.
Weiteres Prinzip: Duale Komplementarität
Ein weiteres Erfolgsrezept aller selbstorganisierenden Systeme ist die duale Komplementarität. Hochentwickelte Organismen haben immer zwei Nervensysteme, einerseits ein autonomes, lokales, das vegative Nervensystem, und andererseits ein motorisches, hierarchisches, das Zentral-Nervensystem.
Ein Beispiel in Forth sind die beiden Stacks. Der Datenstack und der Kontrollstack erfüllen dual komplementäre Funktionen. Der Datenstack ist lokal, dezentral, und auf die Produktionsstruktur bezogen, der Kontrollstack hierarchisch und mit der Kontrollstruktur verbunden.
Ein höher organisiertes System kann nicht ohne beide Komponenten funktionieren.
Stichwortsammlung System:
Ein Aggregat von interaktiv zweckdienlich vernetzten und separierbaren Einheiten. Dem angesprochenen Zweck entsprechend, eine komplette Menge.
Objekt-System:
Das System unter Betrachtung
Subsystem:
Innerhalb eines Systems, einem bestimmten Zweck zugeordnetes Teilsystem
Produktions-System:
Subsystem, das eine sichtbare Leistung bringt
Steuerungs-System:
Subsystem, das die Steuerung des Produktions-Systems besorgt Typologische Staffelung:
Eine Russellsche Hierarchie von Typen
Meta-Sydem:
System auf einer höheren typologischen Ebene als das Objekt-System. Die Transaktionen des Meta-Systems sind von übergeordneten logischen Typus zu denen des Objekt-Systems. Das Steuerungssystem ist ein Meta-System zu dem Produktionssystem.
System-Katalyse:
Das Metasystem wirkt katalytisch auf das Objekt-System. Es vergrößert seine Arbeitsgeschwindigkeit Beispiel: Computersysteme bewirken, als qualitativ neue Technologien im Steuerungssystem, einen Wachstumsschock ihrer Objekt-Systeme. Folge: Proliferation der Komplexität.
Systembegrenzung, Tragfähigkeit:
Die strukturelle Grundlage des Meta-Systems wirkt als Begrenzungsfaktor in der Proliferation des Basis-Systems. Beispiel: Die Computersysteme werden selber so komplex, daß sie unüberschaubar und unwartbar sind. Logische Ursache: Vermischung der logischen Typen. Die Meta-Eigenschaften des Steuerungs-Systems läßt sich nur innerhalb einer bestimmten Komplexitäts-Bandbreite aufrechterhalten.
System-Aushilfe:
Das Meta-Meta-System Errichten einer weiteren Ebene in der Hierarchie der logischen Typen. Also: Organisation der Computeranwendungen Konzeptueller Blind Spot:
Das Halteproblem der Informatik. Bedeutet: Eine Maschine, oder ein Programm, auf sich selbst angewandt, ist theoretisch unsinnig. Folge: Niemand hat sich damit beschäftigt was herauskommt, wenn man ein System auf sich selbst anwendet. (Siehe auch: Appendix II in dem Forth-Artikel)
Reales Gegenbeispiel:
Die Mikro-Elektronik Industrie ist eine Technologie, auf sich selbst angewandt. Ohne CADX CAM-Systeme wäre die ökonomische Produktion von Mikrochips nicht möglich
Schlußfolgerung:
Systematische Erforschung auf sich selbst angwandter Systeme (Siehe Hofstadter: Goedel Escher, Bach)
Direkte Anwendung:
Meta-Computersysteme
Zum Beispiel Computer-Expertensysteme (nicht Expertensysteme, die auf Computern laufen, sondern Expertensysteme über das Computersystem, auf dem sie installiert sind. Selbsterklärende Computer).
Allen bestehenden supermodernen Datenbanksystemen zum Hohn ist die Dokumentation dieser Systeme, und aller Computersysteme um sie herum, noch so organisiert, wie zu Gutenbergs Zeiten: biblisch (als Buch) Idealziel:
Jeder Computer enthält sein eigenes Expertensystem.
Hindernis:
Was ist Meta-lnformation? Forschungslücke Außerdem Profitfrage. Hersteller halten zwar zum Teil intern ihre Dokumentation als Datenbank, aber sie sehen es als äußerst profitschädigend an, diese Strukturen den Kunden zur Verfügung zu stellen (Wer würde da noch Kurse besuchen!).
* Andreas Goppold ist Diplom-Informatiker MSc und Mitbegründer der Forth Gesellschaft Deutschland in Hamburg, einer Non-profit-Vereinigung zur Förderung dieses Programmiersystems.