Der Stil der Sourcen Anmerkungen zur Theorie und Geschichte der Programmiersprachen
Wolfgang Hagen
(erschienen in: Coy / Tholen / Warnke:  Hyperkult, Basel u.a.:Stroemfeld 1997, 33-68; Online hier)
"Le style c'est l'homme même"
(Buffon)
"...die Prozedur, ... deren Beherrschung einen entscheidenden Einflußauf den Stil und die Qualität der Arbeit eines Programmierers ausübt."
(Wirth)
"The principles of style, however, are applicable in all languages"
(Kerningham)
"Ein Programmierstil basiert auf einer (möglicherweise spekulativen) Vorstellung von einem `Rechner' ..., der die Programme abarbeiten soll"
(Stoyan)
"Can we be liberated from the von-Neumann-style "
(Backus)
Beginnen wir mit einem Gedankenspiel.
1 Die "Library of Modern Sources"
Stellen wir uns in Gedanken eine große Bibliothek vor, genannt "The Library of Modern Sources". Wie müßte der Bauplan eines solchen Sourcen-Museums aussehen? Wir dürften Abteilungen errichten und sie nach den großen Gruppen der Programmiersprachen trennen: die prozeduralen (FORTRAN, ALGOL, PASCAL und C) von den funktionalen Sprachen (LISP, ML oder MIRANDA), diese von den deklarativen (LOGO oder PROLOG), und hätten eine neue Abteilung mit den objektorientierten (SMALLTALK, EIFFEL, C++), den parallelen und den neuronalen Sprachen gerade im Aufbau. Es sollten aber, und das wäre eine Minimalbedingung, alle je geschriebenen Sourcen als Schriften vorhanden sein, dazu die Beschreibungen und Quellen aller "Compiler-", "Interpreter-" und "Assembler"-Sprachen, die jeweils zu den Systemen gehörten, und dazu noch all diejenigen Texte, Baupläne, Tabellen und Diagramme, die die Maschinen selbst beschreiben, auf denen die Sourcen gelaufen sind. Wir würden also alles zusammentragen, was zum Symbolischen unseres Vorhabens gehört: alles geschriebene, alles je in Zeichen und Zeichnungen gefaßte Wissen der je geschriebenen Quellcodes. Würde das reichen? Umfaßt die Geschichte der Sourcen nur das, was symbolisch aufgezeichnet wurde? Ich fürchte, unsere Library müßte am Ende auch die realen Maschinen selbst inventarisieren, nebst allen
Betriebssystemen und real laufenden Entwicklungsumgebungen. Andersfalls sollte, nach Lage der Dinge, das meiste, was wir an Sourcen älteren Datums aufgehoben hätten, ganz unverständlich bleiben. Aber verfügt irgendwer auch nur noch über einen minimalen Bestand an Computern, die jemals liefen? Nein. In unserer Sammlung wären vermutlich am besten die Sourcen dokumentiert, die erklärtermaßen niemals auf einer realen Maschine liefen.
Bedauernd also müßte unser Gedankenmuseum am Eingang erklären, daß die Geschichte aller Sourcen, ihre "historia rerum gestarum", wie römische Historiker sagten, in Sachen Computer zusammefällt mit den "res gestas", mit den geschehenen Dingen selbst. Unser Gedankenmuseum ist also eine logische Unmöglichkeit.
2 Die Aufhebung der Sourcen
Ganz zu schweigen von den Beschaffungsproblemen, der Source der Sourcen. Wo sind sie aufgehoben? Ich traue den Archiven von Big Blue oder dem MIT, Xerox, Apple, Microsoft, der Navy und der Air-Force natürlich über alle Maßen, aber ob sie wirklich die Sourcecodes des UNIVAC oder BINAC, der DUAL und SHACO-Maschinen von Los Alamos, der IBM 701 oder 704 nebst Prototypen dieser Maschinen inventarisiert haben, wäre eher zu bezweifeln.
Wir erkennen ein gravierendes, weil fundamentales Aufhebungsproblem. Zwischen einem abstrakten Computer, den jedes kunst- oder "hoch"-sprachliche Programm repräsentiert, und einer realen Maschine, die gesteuert werden soll, steht, wem sage ich das, wenigstens ein Generationsprozeß einer weiteren Maschine. Einige deutsche Informatiklehrbücher nennen diese generische Maschine, die aus dem Quellcode den Maschinencode kompiliert, den "Übersetzer". Was die Sprache der abstrakten Computer betrifft, also die "Sourcen", so wirkt dieser Übersetzer wie ein Übersetzen über jenen unterirdischen Fluß, den die Griechen mit dem Reich des Todes identifizierten. Der Übergang von einem symbolischen Programmtext zum realem Maschinencode eines Programms, tötet die Sprache, die es in Gang setzt, ab. Oft genug ist der Übergang einer vom Sein (Software) ins Nichts (Hardware). Wollten oder müssen wir die laufende Maschine beschreiben, und das müssen wir ja oft genug, so behelfen wir uns meist mit einer anderen symbolischen Maschine, dem "Assembler". Sein dis-ensembelndes `Debugging' versprachlicht uns das laufende Programm in eine andere, neue Sprache, die mit der Ursprungssource nur noch wenig bis nichts zu tun hat. Dieser Weg liefert nur eine buchstäblich ideelle und trügerische Kontinuität. Realiter verläuft zwischen den symbolischen Maschinen und ihrem realen Laufzeit-Gegenstück ein Bruch, den wir auch so benennen, nämlich den "breakpoint". So heißt der Haltepunkt, wenn die Maschine noch läuft und wir unser symbolisches Vokabular dazwischen schieben. Aber wir "schieben" nicht, sondern ein maskierbarer Interrupt "trace"t und "debugge"t an diesem Ort der allerletzten Verständigung mit der Maschine. Durch eine HDL, eine Hardware Description Language mag uns per Diagramm oder "Temporal Logic Design" noch beschrieben sein, wie das Verhalten des Interrupts aussieht. Wird auch durch die "breakpoints" nicht klar, was in den pipelines der Maschinenhardware passiert, so hilft nur das letzte Mittel: der "post mortem dump" oder das "post mortem debugging". Am Ende wird bekanntlich abgerechnet, eben auch begrifflich. "Aber", sagt Hegel in der Phänomenologie des Geistes, "nicht das Leben, das sich vor dem Tode scheut ..., sondern das ihn erträgt und in ihm sich erhält, ist das Leben des Geistes" (Hegel:1807, 36).
3 "There is no Software"
Ich will Sie hinweisen auf den geheimen Idealismus, der sich längst in das Denken dieser symbolischen Verbindungen, in die Transitionen und Transformationen der abstrakten Maschinen eines Computerprogramms eingenistet hat und der so verführerisch naheliegt. Diesen Idealismus finden Sie beispielsweise bei einigen amerikanischen Philosophen der "Electric Language", ich nenne Michael Heim oder Jay David Bolter. Sie sagen, "Computerprogramme" und "Computersysteme" seien eine "anspruchsvolle Sammlung programmierter Texte, die miteinander interagieren" (Bolter:1991, 9). In realen Computer-Maschinen interagieren aber keine Texte miteinander, sondern n-Millionen Transistorzellen in n hoch 2 Wechselwirkungen; Elektronendiffusion und quantenmechanische Tunneleffekte laufen über alle Chips. Wenn man dies noch "Interaktion" nennen will, so behandelt, wie Friedrich Kittler in Anschluß an Michael Conrad zeigt, die "gegenwärtige Herstellungstechnik solche Interaktionen als Systemschranken, [als] physikalische Nebeneffekte, Störquellen usw." (Kittler:1993a, 242). Symbolische Software-Programme und reale Laufzeitaktionen von Computern eint eben nicht die Interferenz einer kontinuierlichen Universalität, wie wir sie aus der gutenbergsche Bücherwelt zu erhoffen gelernt haben, sondern sie differieren in Diskontinuitäten, oft allzu grotesk. Wäre dem nicht so, so gäbe es nicht jene wiederkehrenden Wellen schmerzlicher Software-Krisen im kleinen wie im großen. "Wäre das Programmieren ein strikt deterministischer Prozeß, der nach festen Regeln abläuft", schreibt der lakonische Eidgenosse Wirth, "so wäre [das Programmieren] seit langem automatisiert worden" (Wirth:1983, 120). Oder es gäbe eben, mit einem provokanten Wort Kittlers, "keine Software" (Kittler:1993a, 241).
4 Zur Genealogie des Computermediums
Gehen wir also zurück in die Anfangstage des Computers, dorthin, wo der Satz mit einiger Bestimmheit gilt: "There is no Software". Wir müssen hier nicht diskutieren, daß der Computer auf dem mathematischen Modell der Turing-Maschine basiert und dies Modell seit den späten dreißigern in der amerikanischen Wissenschaftlerwelt weithin bekannt war. Aber Turing hat 1937 keine "Software" angeschrieben, sondern den Negativbeweis, daß ein allgemeiner Algorithmus zur Lösung mathematischer Fragen nicht gegeben werden kann. Daraus folgt der Positivbeweis, daß berechenbar ist, was in einer endlichen, heißt endenden Beschreibung algorithmisch anschreibbar ist. Daß uns, oder zumindest doch Oswald Wiener, heute die ganze Welt als Universum gefalteter Turing-Maschine vorkommen mag (Wiener:1988), hat doch wohl weniger mit Turing zu tun, als vielmehr mit dem Eindruck, den die massive Entwicklung der digitalen Speichermedien auf uns macht. Wir dürfen wohl vermuten, daß die Menge adressierbarer Bytes auf allen Computern der Welt der Schriftzeichenmenge aller Bücher der Welt bereits eingeholt hat. Mit dieser entropischen Digression der Speichermedien wird ein anderes mathematisches Modell relevant, das ebenso für die Medienwechsel unserer Tage verantwortlich ist: ich meine Shannons mathematische Theorie der Kommunikation aus den späten Vierzigern.
Wollte man also den Computer als Medium, wie er uns heute erscheint, in ein Evolutionsmodell bringen, was ich hier als sehr grobe Skizze einmal vorschlagen möchte, so würde dieses Modell auf die Zeitachse die Bildung einer dynamischen Schnittmenge dreier differenter evolutionärer Komplexe zeichnen, welche nicht sofort begrifflich gegeneinander vertauscht werden dürfen und die auch keineswegs von Anfang an miteinander in Beziehung standen: Das sind
- die mathematischen Modelle der Berechenbarkeit
- die Ingenieurstechnik der Speicherentwicklung und -Adressierung
- die Mathematik und Physik der Nachrichtentechnik
Ich füge hinzu, daß der seltsam undurchsichtige terminus a quo unseres Problems, nämlich die Frage nach dem Ursprung und der Entwicklung der Programmiersprachen, ebenfalls in drei Einschnitten skandiert werden könnte.
- Der erste Einsatz der Programmiersprachen, zu Beginn der 50er, der aus symbolischen Kontiguitäten folgt, aber aus keinem mathematischen Modell.
- Dann, zu Ende der 50er, die Gegenbewegung der mathematisch orientierten Funktional- und Deklarationssprachen, die die Maschine, von der sie zu abstrahieren fordern, idealisieren muß.
- Und drittens, in den frühen siebzigern und noch einmal Ende der 80er: der Einschnitt der Simulation, der den Eintritt früherer Medien (Schrift, Bild, Ton) in den "Computer" markiert, was ihn selbst zum Medium macht. Dieser letzte Entwicklungsschritt führt zu den objektorientierten Sprachkonzepten, die weder eindeutig prozedural, noch eindeutig funktional definiert sind.
Vor dem Hintergrund dieses Entwicklungsprozesses wären die drei großen Stilgruppen des Programmierens zu skizzieren, die anders nicht ableitbar sind. Also unterfällt jede Theorie der Programmiersprachen, wie jede Theorie der Medien, einem, nämlich ihrem eigenen Medien-Apriori: sie ist nur als historische Theorie anschreibbar.
Ich will Ihnen im folgenden den ersten der drei Sprünge, die ich in der Programmiersprachenentwicklung erkennen kann, nachzeichnen und damit ein bischen mehr von dem zeigen, was hier Stil zu nennen wäre.
5 Exkurs: "Stilus" oder der Stil der Metonymie
Es gibt wenige Begriffe der Poetologie und Sprachwissenschaft, die eine fundamentale Eigenschaft der Sprache beschreiben und gleichzeitig Effekt dieser Eigenschaft sind. Der "Stil" gehört dazu. In der lateinischen Ethymologie von Alois Walde, Heidelberg 1910, finde ich den Hinweis, daß "stilus" ursprünglich einen "spitzigen Pfahl" bezeichnet, den man im Krieg "zum Spießen in Fallen" (Walde:1910, 738) benutzte, daraus in der "agricultura" die Bezeichnung des Werkzeugs zum Auflockern des Bodens erwächst, daraus der Name des stengeligen Werkzeugs zum Einritzen von Buchstaben in weiche Wachsplatten entsteht, ein Griffel aus Hartholz, Horn oder Metall, "an dem einen Ende spitz, an dem anderen Ende breit zur neuen Glättung des Wachses", wie die Altphilologen Menge und Güthling hinzufügen (Menge:1911, 716).
Stilus ist ein Werkzeug zum Schreiben und zu seinem Gegenteil, dem Tilgen. Hans Ulrich Gumbrecht hat den Einsatz der Metonymie markiert, der mit diesem binären Widerspruchswerkzeug im ersten vorchristlichen Jahrhundert geschieht. Da nämlich, als das alte Rom auf das Kaisertum
Griechisch-römischer Stilus für Wachstafeln
unaufhaltsam zusteuert, eine erste Bibliotheks- und Buchkultur in Rom entsteht und das schriftliche Dokument die Politik der forensischen "Oratio" zu verdrängen beginnt, da verdrehen einige auf ihren Schrifttafeln, was doch in der sichtbaren Welt die Fakten sind. "Stilus" heißt jetzt nicht nur Griffel, sondern auch "Anwendung des Griffels, ... die Übung im Schreiben, die Darstellungsweise des Schreibers", und die "Sprache des Schriftstellers" selbst, der "stilus artifex". Das Verdrehen, das Umdrehen des "stilus", wird zur ursächlichen Stilhandlung der Sprache. Gumbrecht zitiert Cicero:
"Vertit stilum in tabulis suis, quo facto causam omnem evertit suam" (Gumbrecht:1986, 731) "Er verdreht in seinen Schriften, wie er durch die Tat alles Seine zugrundegerichtet hat".
Das "Verdrehen" des Schreibgriffels, das "stilum vertere", heißt nunmehr: Unkenntlichmachen des Geschriebenen durch das Geschriebene. Das ist die Metonymie und die Sache. Das ist der Stil. Und umgekehrt. Kann in einer Software das Geschriebene das Geschriebene unkenntlich machen?
Durch Weglassen, also durch eine Ökonomie der Tilgung, die die größte Wirkung in der Rede erreicht, empfiehlt sich bekanntlich der ciceronische Stil. Es folgt eine weitgefächerte Begriffsgeschichte durch nahezu alle Rhetoriken und Poetiken der Patristik, Scholastik und Renaissance bis hin in die Aufklärung und ihrer endlichen Losung: "Der Stil ist der Mensch selbst". Ein Stil, der das bürgerliche Subjekt der Rede und des Schreibens, der den urheberrechtlich produzierenden Autor, das freie, aber bezahlte Genie, aus den Formkorsetten der Schriftvorschriften vergangener Jahrhunderte befreien soll. Es gibt auch in der Literatur der Informatik einige Bücher, die vor solchen losgelösten subjektiven Stil-Etüden warnen und doch handelt es sich nur um sehr dünne Dummheiten auf beiden Seiten. Friedrich Kittler (Kittler:1986) und Bernhard Siegert (Siegert:1993) haben in ihren Kafka-Studien gezeigt, daß Stil letztlich immer ein Abkömmling medialer Effekte ist, welche mit dem Aufkommen der technischen Medien längst auch auf die Literatur durchgeschlagen haben.
Im vorchristlichen Jahrhundert, in dem der "stilus" metonymisch wird und im Stilbegriff aus dem Gerät sein Ergebnis, ist es wiederum ein Medienübergang, ein neues Medienapriori, das diese Verschiebung in Gang setzt. Denn unter den Händen und Armen der Schreiber von Cicero, Sallust, Terenz oder Caesar liegt immer seltener die Papyrus-Charta, und immer öfter der "caudex", das verschnürte Wachstafelbuch, sowie der gebundene Codex aus Pergament. Beide, Caudex und Codex, setzen dem Geschriebenen neben der Y-Achse, der Rolle und dem Fortlauf des Textes, eine X-Achse hinzu, die Seite, und eine Z-Achse, die Zahl der Seiten. Das bringt die Schrift - historisch das erste Mal - in eine dreidimensionalen Ordnung und macht sie adressierbar. Im Codex wird Schrift als Schrift/Text anschreibbar. Dazu verhelfen Numerik und ein paar Symbole: Seitenzahlen, Absätze, Einrückungen, Marginalia, Paragraphen, Kapitel, Komma, Strich, Doppelstrich, Kolon und Semikolon. Jetzt kann man von Schrift wissen, die man nicht sieht, aber wie eine sichtbare berechnet und referenziert ist, ein virtualisierender Effekt des Codex und die Geburt des Stils.
Mit dem Aufkommen des Buchdrucks im 15. Jahrhundert wandern peu a peu alle diese Codex-Zeichen, die bis heute, zu Tschicholds (Tschichold:1949) Leidwesen, nicht ins normale Alphabet aufgenommen wurden, wie wir bei Florian Cajori (Cajori:1928) nachlesen können, eins ums andere, in ein anderes Alphabet: nämlich in das der Mathematik. Womit wir, was die Zeichenbasis betrifft, beim Stil des Programmierens wären.
6 Die Zeichen der ersten Programme
`Was war das erste Computerprogramm und was waren ihre ersten Zeichen?' Diese Frage ist so gut wie: `Was war der erste Rechner der Computergeschichte?' Auf solche Fragen gibt es bekanntlich keine
Projekt PX / "ENIAC"
zufriedenstellenden Antworten. Die MARK-Rechner von Howard Aiken, Zuses Z3, Turings COLOSSUS und ACE-Maschine, sowie Mauchly-Eckerts ENIAC haben neben einigen anderen Anteile an der Entwicklung. Es gibt eine Ubiquität von Anfängen, eine Dissipation des maschinellen Beginns von Computern.
6.1 Dissipativer Evolutionsprozeß
Wie der ingenieurstechnische Boom im amerikanischen Rechnerbau, der hier eine entscheidende Rolle spielt, zu erklären ist, setze ich als bekannt voraus. Für die massive Rechnerproduktion der 40er Jahre in den USA gibt es kein anderes Dispositiv als die anwachsende Berechnungsflut von "firing tables" aller möglichen Geschosse und Flugkörper, und was den ENIAC selbst betrifft, das sogenannte hydrodynamische "Los-Alamos-Problem". Die numerische Berechnung von Schockwellen-Gleichungen einer Implosionszündung der H-Bombe wurde in langen drei Monaten ab Oktober 1945 auf dem ENIAC tatsächlich durchgeführt (Burks:1980,334)[1].
6.2 Zuse
Dem Einzelgänger Zuse, in seinen kargen Räumen der Deutschen Versuchsanstalt für Luftfahrt um 1940, abgeschnitten von allen Forschern der Welt und verloren in der chaotischen Forschungsorganisation der Nationalsozialisten, sind dennoch am Evolutionsprozeß des Computer wichtige Anteil zuzugestehen. Dies vor allem in Bezug auf eine Tiefenstruktur des Entstehungsprozesses programmierbarer Rechner, die nicht allein auf Turings oder von Neumanns Arbeiten zu beschränken wäre, sondern bis zu den mathematischen Problemen Hilberts, Ackermanns oder Freges zurückreicht, auf die Zuse ebenso wie Turing und von Neumann direkt repliziert. Damit beantwortet sich auch die Frage mit ja, ob aus den Debatten um die Axiomatik und Grundlagen der Mathematik in den 20er Jahren ohne Turing der Computer hätte hervorgehen können. Der Unterschied zwischen der amerikanischen und der deutschen Computerentwicklung ist, nach allem was wir wissen, kein wissenschaftliches "gap" in Bezug auf die mathematischen und logischen Grundlagen, sondern der Unterschied liegt vor allem in einer völlig anderen, militärisch und industriell gestützten Forscherorganisation. In Amerika und England existierte ein bruchlos gewachsenes System des militärisch-industriell-universitären Komplexes, das zudem durch die Massivität von Los Alamos noch verstärkt wurde. Es vereint von 1942 die Amerikaner Goldstine, Mauchly und von Neumann, sowie Turing in England. Konrad Zuse dagegen arbeitet in einer von den Interessen der Wehrmacht, SS, Marine und Luftfahrt völlig zerstrittenen Forscherorganisation, die Zuses Arbeiten verkennt und nicht unterstützt. Aber schließlich wird, nach dem Krieg, über den geretteten Z4, Zuses eigene Programme und sein "Plankalkül", das Rutishauser kannte, sein Einfluß bis in die Konferenzen von ALGOL 58 und ALGOL 60 reichen (Metropolis u.a.:1980, 522).
6.3 Der ENIAC
Wir sagen immer sehr allgemein, daß John von Neumann elementare Konzepte der Turingschen Entscheidungsmaschine in den von den Amerikanern dominierten Rechner-Bauboom eingebracht hat. Aber wir können auch den historischen Ort und Zeitpunkt ausmachen, an dem das geschah, nämlich im Team der ENIAC-Konstrukteure zwischen Frühjahr und Herbst 1944. Von Neumann ist hier Teil eines Ensembles von Forschern, z.B. Brainerd, Goldstine, Eckert, Mauchly, Burks. Die `team-mates' der ENIAC-Gruppe hätten also letztlich Urheberschaftsanrechte auf das gewonnene Konzept der sequentiell gespeicherten Programmierung genauso erheben können, wie sie allgemein von Neumann allein zugesprochen werden.[2] Dies umsomehr, als die gespeicherte Programmierung ein ziemlich unumgänglicher Ingenieursfortschritt war, der sich aus der Architektur des ENIAC sozusagen zwangsläufig entwickeln mußte.
6.3.1 ENIAC-FO-Inputs
Der ENIAC war mit seinen 18.000 Röhren der erste elektronische Röhrenrechner dieser Größe, Vorbild all dessen, was in den Nachkriegs-Wirtschaftwunderjahren als "Elektronengehirn" sollte bewundert werden und Beweis, daß Röhrenschaltungen in diesen Größenordnungen möglich waren. Auch die Zeitgenossen wußten, welche großen ingenieurstechnischen Strömungen, ich nenne sie hier im Anschluß an Hagemeyer "Forschungsorganisationen" (FO's), in diesen Rechner direkt eingemündet waren.
Der Ursprung von ENIAC und des Computers mit gespeicherter Programmierung.
Hardwareseitig:
- die Elektronik-Industrie, die mit den "radio days" gerade den Peak des Baubooms an Empfängern und Sendern erreicht hatte;
- die mechanischen und elektromechanischen Industriezweige, allesamt in der Waffenproduktion tätig;
- robuste Röhren aus der Radartechnik; der ENIAC verwendete solche mit Schalttakten von 100 Kilohertz;
Auf der anderen Seite in Bezug auf die Rechner-Architektur:
- Vannevar Buschs "Differential Analyser" als Vorbild der Maschinenorganisation;
- die IBM-Schalttafeln zur Steuerung; daneben die Erfahrungen aus den Bell Labs und mit Aikens MARK I;
Dies alles ist der Forschungsorganisations-Input des ENIAC, der dann sozusagen eine lange Eigenschwingphase hat, in der das Konzept des "Stored-Programme" entsteht.
Der ENIAC hat zwei Nachfolgenerationen, den IAS, WHIRLWIND, von dem noch zu sprechen sein wird, bis hin zu der IBM-Linie 700, die ziemlich direkt dann in unsere deutsche Gegenwart führt und die mehr universitär ausgerichteten Produktlinien EDVAC, EDSAC und UNIVAC, die uns auch noch kurz begegnen werden.
6.3.2 Ausdehnung und Aufbau
Der Aufbau des Rechners: Vier Akkumulatoren, eine "Square-Rooter"-, eine "Multiplikations-Einheit", drei aufwendige Funktionstafel-Einheiten zur
ENIAC Layout
Matritzenberechnung, links unten die drei Kontroll-Einheiten und rechts die Lochkarten-Eingabe und Ausgabe[3]. Alle benannten Einheiten mußten zunächst für sich "programmiert" werden, was hieß: über Steckfelder verkabelt werden.
6.3.3 Programmierung
Die Programmierung des ENIAC zerfiel in zwei getrennte Teilbereiche, "numerical programming" und "programming proper":
6.3.3.1 "Numerical Programming"
Schaltplan einer IBM 601-Steckkarte. (von IBM [1947])
Die Abbildung zeigt eine solche "Programmierung" einer Akkumulator-Einheit, wie sie in etwa auch im ENIAC verwendet wurde. Oben sehen sie die gesteckte Berechnung "a*b + c + d". Diese Arbeit an solchen Steckfeldern hieß, wie Arthur Burks berichtet, "numerical programming" und mußte je nach Formelberechnung an allen Akkumulator- bzw. Square-Root oder Function-Einheiten in dieser Weise jeweils separat geschehen. Überwiegend Spezialistinnen-Arbeit, den ENIAC-Girls. Um die Übersicht zu behalten, wie der Verlauf solcher "numerical programmings" vonstatten gehen sollte, wurde solche Blockdiagramme angefertigt:
Die Blockdiagramme legten fest, was in welchen Einheiten des ENIAC zu geschehen hatte, welcher Akkumulator welchen Formelteil zu berechnen hatte usw. `Numerical Programming Assignment' könnte man das nennen, eine erste Art der Zuweisung also, denn die Akkumulatoren waren ja nichts anderes als intelligente Speicherstellen des Rechners. Für ihre Codierung, d.h. den Plan ihrer Verkabelung, existierte keine verallgemeinerte symbolische Schreibweise.
In solchen Ablaufdiagrammen finden wir die Vorläufer der ersten Programmierroutinen. Im übrigen handelt es sich um eine der ältesten Repräsentationen des Rechnens. In ein "diágramma" zeichneten die Griechen ihre geometrischen Figuren und deren Ableitungen. "Diágramma" hieß darüberhinaus, weil Tonfolgen als eine Ableitung kosmischer Geometrie verstanden wurden, die Tonart. Im ENIAC ist es der Umriß eines Programmablaufs, der in Diagrammen festgehalten wird; eine graphische Schnittstelle zwischen der Mathematik der zu berechnenden Formel und dem elektronischen Plan ihrer numerischen Lösbarkeit. Solche Diagramme konkret zu implementieren, wurde im ENIAC lakonischerweise "programming proper" genannt. Als wenn es sozusagen nichts einfacheres gäbe als das.
6.3.3.2 "Programming Proper"
Das "programming proper" bestand nun darin, die einzelnen Units mit dem "digit trunks", also mit dem Datenbus einerseits, und mit den "program lines", von denen es parallele sieben gab, andererseits zu synchronisieren. Dafür wurden weitere Diagramme angefertigt:
Vereinfachtes ENIAC Programm-Diagramm. (aus Burkes [1980])
Es mußten die Transmit- und Receive-Einrichtungen der Akkumulatoren miteinander verbunden werden, händisch natürlich per Steckfeld. Die pro Akkumulator drei "program control"-Einrichtungen wurden an den Bus der "program lines" angeschlossen. Im Grunde liegt in dieser busähnlichen Architektur, in diesem Busarchetyp, wenn man so will, einer der wesentlichen Neuerungen des ENIAC. Der elektromagnetische "differential analyser" und so auch Zuses Maschine, hatte letztlich, wie Schickart oder Babbage, immer noch so etwas wie eine Hauptwelle, irgendeine Art Zentralgetriebe, das von einem Motor betrieben wurde und damit die Geschwindigkeit der Berechnungen steuerte. Diese mechanisch gekoppelten Wellen ersetzte im ENIAC das völlig neuartige Konzept dieser zehn Buskabelstränge, auf denen die "Cycling Unit" einen komplizierten, parallelen Uhrentakt übertrug, der in seiner kleinsten signifikanten Pulsfrequenz bei unter 3 Mikrosekunden lag, also Schaltvorgänge mit einer veritablen 3,3 KHz-Frequenz ins System triggern konnte. Solche Pulse zu beherrschen, war wiederum nur aus der Erfahrung der Radartechnologie her möglich. Einmal eingerichtet, war der Ablauf eines Programms dann aber ein durchweg statisches System, an Rekursionen, Induktionen und bedingte Verzweigungen war nicht zu denken.[4]
6.3.4 "Mercury Delay Lines"
Daß sich aus dem ENIAC, einer Röhrenmaschine, und nicht aus den elektromagnetischen Rechnertypen das Konzept des "stored programmings", der gespeicherten Programmierung, entwickelte, liegt auf der Hand. Im ENIAC war ein im Prinzip schneller Bus geboren und die Technik war robust genug, über eine Impulssteuerung ein System, das so groß wie ein halber Ballsaal war, im 3 1/2 KHz-Takt zu triggern. Das wiederum eröffnete nun die Möglichkeit, die mechanisch nahezu unlösbaren Speicherprobleme endlich anzugehen, indem man, wie Sie wissen, alle möglichen impulsgesteuerten Verzögerungssysteme erfand, im ENIAC-Fall die "Mercury Delay Lines" zum Beispiel, die auch Turing verwendete. Niemand anders als Pres Eckert (Metropolis u.a.:1980,531) hatte sie im Frühjahr 1944 für Radareinrichtungen entwickelt, ein weiterer "Radar-Input" in den Computer also.
Diagramm des Speichers aus akustischen Verzögerungsstrecken.
Die Abfolge akustischer Pulse und Lücken, die sich durch das Quecksilber
von links nach rechts bewegen, ist schematisch dargestellt.
Die Mercury Delay Line: eine schmale, zum Beispiel zwei Meter lange Röhre, in der ein pulsierendes Ultraschallsignal um bis zu 1 Millisekunde verzögert werden konnte, und zwar durch "mercury", zu deutsch Quecksilber, mit dem das Rohr gefüllt war. Durch eine geschickte Schaltung war es möglich, mit nur zehn "tubes", also Röhren, die etwa 1000 Impuls-Bits, jeweils eine Mikrosekunde voneinander getrennt, aufzufrischen. Wodurch ein getakteter elektronischer 1K-Bit-Speicher zum Preis von ein paar Liter Quecksilber und 10 Röhren a 10 $ entstand. Die "Mercury Line" war insofern der durchschlagend revolutionäre Punkt: sie ließ den Preis und den Platz für das Speichermedium mit einem Schlag um den Faktor 100 : 1 sinken.
Eine Kaskade von 256 solcher "Mercury Lines" konzipierte das Team von März bis Juni 1945 als das 32 K große Memory für Daten und Programminstruktionen eines neuen Rechnertyps, den wir heute die "von Neumann Maschine" nennen. Die getakteten Speicherbausteine verlangten nach einer getakteten Busarchitektur, die Adresslogik des Busses verlangte nach Reduktion der verteilten Akkumulatoren, Multiplikatoren und "Square Root Units" auf einen Baustein, der zentralen Arithmetischen Einheit, und das gesamte System somit nach dem General-Takt der "Central Control". Weit ab von Turings logischer Maschine verlangte hier allein schon die Synchronisation der so beschriebenen Elektronik-Architektur nach der legendären diskreten Sequentialität, unter Preisgabe der so größzügig ausgerüsteten Parallelarchitekturen, wie sie der ENIAC noch repräsentierte. Die ab jetzt gültige "guideline" für einen der erfolgreichsten Maschinentypen, den Menschen je gebaut haben, hieß in Burks lakonischen Worten:
"One thing at a time, down to last bit!" (Burks:1980, 338). Single Instruction, Single Data.
Im Patentstreit wird John von Neumann später eingestandermaßen von einer apostolischen Botschaft sprechen, von der "es praktisch unmöglich zu sagen [ist], wer der Apostel war." (Legendy u.a.:1979, 57) Der Punkt, an dem in der Forschungsorganisation des ENIAC die Innovation der binären Speicherarchitektur und der gespeicherten Programmierung erwächst, dieser Übergang ist alles andere als eine Erfindung oder ein definierbares Patent. Und mehr noch: für keine der beiden Strömungen, weder für die Rechnerkonstrukteure Mauchly und Eckert, noch für den Mathematiker von Neumann, ist an diesem Punkt der Computer selbst ein terminus ad quem[5]. Es ging, in dem Wettbewerb der unterschiedlichen Rechnerarchitekturen, zunächst einmal darum, einen weiteren Rechner zu bauen und zwar einen, der möglichst dazu in der Lage war, nichtlineare Gleichungen, also solche mit großen Rundungsproblemen und Induktionsbedarf, numerisch zu lösen. Den Computer, wie wir ihn kennen, hat niemand im strengen Sinn "erfunden", noch wollte ihn vermutlich jemand so "erfinden", wie wir ihn jetzt haben.
Von Neumann selbst wird relativ schnell über diese Maschine, deren grundsätzliche Eigenschaften ja durch Turing hinreichend beschrieben waren, hinweggehen und wird sich das letzte knappe Jahrzehnt der Automatentheorie, der Theorie fehlertoleranter Maschinen zuwenden, wird über Zellularautomaten schreiben, über Matritzeninversion und neuronal lernende Maschinen. Das wissenschaftliche Paradigma dieser halben Kriegsdekade, in der das wichtigste Medium dieses Jahrhunderts geboren wird, ist mitnichten der Computer selbst; es ist eher das, was mit dem Namen Claude Shannon in Verbindung steht, nämlich Thermodynamik und Entropie als elementare Konzepte der Informationstheorie. Lesen Sie Claude Shannons Würdigung John von Neumanns aus den späten sechziger Jahren (Ulam u.a.:1969, 259ff) und Sie werden die Kettenglieder finden, an denen sich Informations- und Automatentheorie verbinden. Shannon und von Neumann wissen nämlich, wie alle, die je damit zu tun hatten, um das Problem der Verläßlichkeit der "von Neumann"-Computer. In ihnen muß bekanntlich, schreibt Shannon,
"jede individuelle Komponente bis zu einer extremen Verläßlichkeit hin gebaut werden, jedes Kabel muß exakt gesteckt, jede Anweisung in einem Programm muß korrekt sein. Bereits der kleinste Fehler in den Komponenten, den Verkabelungen oder der Programmierung wird typischerweise zu einem kompletten Kauderwelsch im Output führen. (...) Dieses Problem", so Shannon weiter, "ist analog zu dem der Kommunikationstheorie, wo man Codes für die Transmission von Informationen haben möchte, so daß die Verläßlichkeit für den ganzen Code sehr hoch ist, obwohl die Verläßlichkeit der Transmission eines einzelnen Symbols eher niedrig ist." (Ulam u.a.:1969, 256)
Von Neumanns Arbeit zu diesem Thema (Neumann:1956) kommt bekanntlich zu dem Schluß, daß solche verläßlichen Systeme, die aus unverläßlichen Komponenten bestehen, dann möglich sind, wenn entweder die Redundanz paralleler, aber gleichartiger Komponenten oder ihre redundante Verknüpfungen fantastisch hoch sind. Spätestens mit der nächsten, dreidimensionalen Transistorgeneration sollten, könnte man träumen, solche Maschinen vielleicht heute baubar sein.
7 Von Neumanns Partituren
Nach der Frage, wie die "von Neumann"-Maschine entsteht, wäre die Frage interessant, wie von Neumann sie programmiert hat. Mit Hilfe von Donald Knuth und Luis Pardo will ich die Frage ansatzweise beantworten. Um die Sache nicht vollends unüberschaubar zu machen, gehen wir, für alle folgenden Beispiele, von einem einfachen, ziemlich nutzlosen Progrämmchen aus, das in ALGOL60 notiert ist, und werden es dann rückübersetzen in die jeweiligen "Stile", hier also in den "Stil" John von Neumanns.
ALGOL 60:
begin
INTEGER
i; REAL
ARRAY
a[0:10];
REAL
PROCEDURE
F(t); REAL
t; VALUE
t;
f := sqrt(abs(t)) + 5 + t3 ;
for i := 0 step 1 until 10 do read(a[i]);
for i := 10 step -1 until 0 do
begin
y := f(a[i]);
if y > 400 then write(i,"Wert zu groß")
else write(i,y);
end
;
end.
Der schale Witz dieses Programms ist, das es die elffache Iteration einer Formel enthält, die den Wert eines elfstelligen Arrays aus REAL-Zahlen in umgekehrter Folge ihrer Eingabe berechnet; falls der errechnete Wert > 400 ist, gibt das Programm eine Warnung, falls kleiner das numerische Ergebnis aus. Dieses Programm würde in der Notation, die von Neumann entwickelt hat, etwa so aussehen:
Von Neumann hat in drei langen Abhandlungen für das "Research and Development Department" der US-Army die Technik der Programmierung, die wir hier sehen, erläutert: "Planning and Coding Problems for an Electronic Computing Instrument" sind diese drei großen Reports überschrieben. Das ist wahrhaftiger Stoff für mathematisch orientierte Oberseminare an Ihren Fachbereichen, den ich hier natürlich aus allen benannten Gründen nicht ausbreiten kann. Ich folge aber unserem Kollegen Jörg Pflüger, daß es sich bei dem, was Sie hier sehen, um keine Programmiersprache handelt, sondern eben um "planning", ein flußdiagrammatisches Plansystem, in das die zu codierenden Teile nur lemmatisch in wohldefinierte Boxen eingetragen sind einerseits, und um eine sehr offene, immer wieder revidierte Codiernotation, die Sie hier nicht sehen, mit der der Codierer und die Codiererin jeweils das ausführten, was in den verschiedenen Boxen dieser Flußdiagramm- Schleifen beschrieben war. Das Flußdiagramm selbst ist eine Schleife aus Schleifen, die von i nach e führt. Ich hatte schon auf eine alte, nämlich die griechische Bedeutung von diágramma verwiesen, das auch Tonart heißt. Lesen Sie also dieses Flußdiagramm eher als eine Partitur, denn als eine schriftliche Notation von Sprache. Die rechteckigen Boxen repräsentieren eine Art mathematische Orchestration des Werks, wobei die einzelnen Stimmen und Instrumentationen weitgehend frei sind.
Ich kann aus Zeitgründen hier nur ein paar Erläuterungen geben. Zunächst einmal sehen Sie, daß von Neumann die Skalierung des Speichers, also das Bitmapping seiner Zahlentypen dem Programmierer überläßt. Das ist natürlich sehr gewöhnungsbedürftig. In der zweiten Box von oben auf der linken Seite lesen Sie z.B. die Anweisung: "10*2 hoch minus 39 to C.1", was bedeutet 10 Einheiten mit jeweils 40 Bits, also 10 40-Bit-Worte anlegen im Speicherbereich C.1.
Es gibt vier Boxentypen in dieser Diagrammatik:
- "Operation boxes", die mit einer römischen Ziffer bezeichnet sind. Sehr schön zu sehen in der Box römisch III, wo ab dem 10. Bit des 40 Bit langen Worts in der Arithmetischen Einheit das Ergebnis der Formel "Wurzel aus absolut a plus 5 a hoch 3" dimensioniert wird mit der Anweisung, diesen Wert an die Stelle D in den Speicher zu verschieben.
Dann gibt es
- "Alternative Boxes", ebenfalls mit einer römischen Ziffer numeriert, die entsprechend dem Vorzeichen des "Werts" der Box verzweigen. So sehen Sie zum Beispiel in der geraden Flußlinie von i nach e eine Box römisch II mit dem Inskript "i", die dann nach rechts unten verzweigt, wenn i >=0 ist, und nach links, in diesem Fall geradeaus, wenn i < 0, also negativ geworden ist.
Drittens die
- "Substitution Boxes", die mit einem Gartenkreuz außen und mit einem Pfeil innen bezeichnet sind. Sie bedeuten keine Codeanweisung, sondern sagen dem Leser dieses Diagramms nur, wie jetzt der Wert einer Diagramm-Variable neu angeschrieben werden muß und schließlich viertens:
- die "Assertion Boxes", die einfach den Wert von Variablen mitteilen, so die letzte Box auf dem geraden Weg zu e, i = - 1, was bedeutet: die Iteration ist beendet.
Man kann also nicht sagen, daß die flow-charts von von Neumann eine grafische Programmiersprache repräsentieren. Sie repräsentieren gewisse Validierungseigenschaften und kommutative Erläuterungen, die mit Codierung nichts zu tun haben, aber der Codierin oder dem Codierer Hinweise darauf geben, was mit den operativen Variablen und Speicherwerten beim Neueinstieg in einen codierten Block geschieht.
Ich will's bei diesen Andeutungen belassen. Ich habe nur die gröbsten Auffälligkeiten dieser Flow-Chart Diagrammatik erläutert, aber das genügt, um Ihnen das Statement von Jörg Pflüger noch einmal in Erinnerung zu rufen. Von Neumann hatte wirklich mit einem Konzept von Sprache nichts im Sinn. "Planning and Coding" in diesem Sinne stellt ja nicht einmal die Frage, ob es möglich sei, einen Computer mit einer koherenten symbolischen Notation anzuschreiben. Ich zeige Ihnen diese komplizierte Flow-Chart, um Ihnen zu sagen, wie von Neumann einen Computer anzuschreiben vorschlug, nämlich durch eine Nicht-Sprache. Diese Nicht-Sprache, also die Partitur des "Planning", das wir hier sehen, hält genau die vier wesentlichen Mechanismen doppelt voneinander getrennt, die in jeder Sprache, auch der formalsten, schon zusammengehen: den Mechanismus der Operation von dem der Alternation, diesen getrennt von der Substitution und diesen getrennt von der Assertion. Es gibt keine generativen Symbole, keine Substitutionen von Zeichenwerten, keine literalen oder syntaktischen Bestimmheiten, und dies schon einfach deshalb nicht, weil das Flußdiagramm den Korrektheitsbeweis seiner selbst garnicht erst anzutreten sich bemüht. Die differente Auftrennung der Sprachstruktur verdankt sich vor allem dem vereinGeneva, Verdana, Sans-Serifen Ebenenwechsel, nämlich daß sich im Flußdiagramm konkrete Operationsbeschreibungen mit Beschreibungen der Beschreibung abwechseln. Dadurch verhindert von Neumann sehr gut, daß in eine Programm-Notation mathematischer Blödsinn hineinkommt, wie es zum Beispiel die simpelste C-Anweisung "x = x +1" in jedem C-Programm darstellt. Machen wir uns klar: Diese erste Neumannsche Anschrift eines Computers implementiert die schlichte Überzeugung, daß Programmierung keiner Sprache bedarf. Ein bedeutsamer Neumannscher Irrtum, und nicht der einzigste, der mit seinem Namen in der Geschichte der neueren Naturwissenschaft verbunden ist.[6]
Hinter "Planning and Coding" verbringt sich, wenn Sie so wollen, ein säuberlich getrenntes System von Arbeitsteilung. Die flow-charts erinnern sehr an das, was aus der Vor-Von-Neumann-Maschinen-Zeit herkam, man kann sie ja auch als eine Art Perfektion der ENIAC-Diagramme lesen, und insofern setzen sie auch auf eine Gewohnheit der CodiererInnen und Codierer auf. Und da wir wissen, daß an den Akkumulatoren und Function Tables überwiegend Frauen saßen, eben die "ENIAC-Girls", und diese Boxen-Logik der Flow-Charts nichts anderes als eine Permutation der ENIAC-Diagrammatik ist, so hat "Planning and Coding", wenn es denn nichts mit Sprache zu tun hat, so doch wenigstens etwas mit Männern, den Architekten, und Frauen, den Codierinnen, zu tun; also mit einem diagrammatischen Abgrund, wenn Sie so wollen, der so selbstverständlich ist, daß man leicht über ihn hinweggehen kann.
8 Priesterschaft und Revolution
Vielleicht sollte man noch hinzufügen, daß die "flow chart"-Programmiertechnik, wie Neumann und Goldstine sie entwickelt haben, eher theoretischer Natur geblieben ist. Jedenfalls wurde sie auf keinem Rechner regulär implementiert, sondern diente bestenfalls als konzeptionelle Hilfe in der nunmehr entstandenen Lage. Es gab also seit den veröffentlichten und vieldiskutierten Konzepten des ENIAC-Teams eine Technik der binären gespeicherten Programmierung, es gab ingenieurstechnische Lösungen, es wurden mit immensen Summen überall in den Staaten Rechner gebaut, aber es gab kein klares Konzept, wie sie anzuschreiben wären. Was also bedeutete Programmieren in den frühen 50ern?
"Programming in the early fifties", schreibt FORTRAN-Begründer John Backus, "was really fun. Der Programmierer mußte schon ein ideenreicher Erfinder sein, um sein Problem den Idiosynkrasien eines Computers beizubringen: er mußte sein Programm und seine Daten in einen winzigen Speicher stecken und unter bizarrsten Schwierigkeiten aus diesem Ding Informationen wieder herausholen, unter Zuhilfenahme eines begrenzten und oft allzu speziellen Sets an Instruktionen. Er mußte jeden denkbaren Trick anwenden, um ein Programm in der Geschwindigkeit zum Laufen zu bringen, die die riesigen Kosten rechtfertigen würden, es überhaupt laufen zu lassen. Und das alles mußte er noch auf seine eigene Eingebung gründen, denn die einzige Information, die er besaß, war sein Problem und ein schmales "manual" der Maschine. Vielleicht noch die Notation einer Subroutine und ihre Aufruf-Sequenz, darin bestand buchstäblich die einzige Kenntnis über generelle Techniken des Programmierens.
(...) Programmieren in den frühen fünfziger Jahren war eine schwarze Kunst, eine eher private Arkanpraxis, die ein paar wenige Programmierer, ein Problem, einen Computer und vielleicht eine kleine Bibliothek von Subroutinen oder einen primitiven Assembler einschloß. Existierende Programme für ähnliche Probleme waren unlesbar oder konnten für neue Zwecke nicht übernommen werden. Allgemeine Programmprinzipien waren weitgehend nichtexistent. So also brauchte jedes Problem einen eigenen Anfang beim Punkt Null, und der Erfolg des Programms hing hauptsächlich von den ganz eigenen Techniken und Erfindungen des Programmierers ab.
(...) Aber so wie die frei übers Land ziehenden Weststaatler in ihrem Gründungsfieber einen chauvinistischen Stolz und einen entsprechenden Konservatismus entwickelt haben, so fingen viele Programmierer in diesen freilaufenden 50ern an, sich selbst als Mitglieder einer Priesterschaft zu betrachten, die ihre Fertigkeiten und Mysterien für viel zu komplex hielt, als daß ein normaler Sterblicher sie hätte verstehen können. (...) Diese Haltung kühlte den Impetus für einigermaßen durchdachte Programmierungverfahren beträchtlich. Die Priesterschaft wollte und bekam zwar tatsächlich einige simple mechanische Hilfen für ihre klerikale Abschufterei, unter welcher sie litt, aber mit Abwehr und Spott bedachte sie alle ambitionierteren Pläne, das Programmieren einem weiteren Anwenderkreis zugänglich zu machen. Für sie war es ein offensichtlich dummer und arroganter Traum sich vorzustellen, daß irgendein mechanischer Prozeß an die Stelle der mysteriösen Heldentat treten könnte, die es bedeutete, ein effizientes Programm zu schreiben. Nur die Priester konnten das. Sie waren deshalb unerbittlich gegen all diese verrückten Revolutionäre, die das Programmieren so einfach machen wollten, daß jederman es tun konnte."(Backus in Metropolis u.a.:1980, 125ff, meine Übersetzung)
Sie kennen diese oft zitierte Stelle aus Backus Selbstbeichte über die FORTRAN Gründerjahre wahrscheinlich gut genug, als daß ich sie lange kommentieren müßte. Aber sie führt uns, und das war der Sinn des Zitats, mit einigen Sätzen auf einen anderen Schauplatz, nämlich den, der beginnt, neben den Maschinen sozusagen, das Medium Computer zu betreffen. Es wird zwar noch zwei, drei Jahrzehnte dauern, aber es deutet sich schon an: Hier ist etwas entstanden, das Priesterschaften, Mysterien und Revolutionäre produziert; das einen faktischen, ökonomisch gewichtigen Einfluß hat; das von technisch immenser Bedeutung ist; das bereits Ausdruck findet, ohne, verzeihen Sie, einen Sprache zu haben. Da deutet sich, so muß man Backus doch wohl verstehen, irgendwie ein Imperativ an, in dieser vehement wachsenden Rechnerwelt der frühen fünfziger, ein Imperativ, der Priester, Pioniere und Revolutionäre um ein goldenes Kalb tanzen läßt, und der Autor all dieser Metaphern ist niemand anderes als John Backus, der Autor der wohl einflußreichsten Programmiersprache der Computergeschichte, nämlich FORTRAN. Er beschließt sein `confiteor' mit dem Satz, "I am the culprit"(129), Ich bin der Schuldige, ich habe es getan.
Vielleicht mag sich für Uneingeweihte, also Nicht-Informatiker, dieses Mysterium, das ja keines ist, auch jetzt noch fortsetzen. Deshalb ein klärender Zwischenruf: John Backus schreibt das Vorgesagte 1980, nachdem er bereits die dritte wichtige Intervention in die Geschichte der Programmiersprachen eingebracht hat, nämlich die Turing-Lecture von 1979 unter dem Titel "Can we be liberated from the von-Neumann-Style?" und damit unter all die Sprachdefinitionsversuche seiner und anderer Provenienz bereits einen dicken Strich in Richtung auf mathematisch begründete Funktionalität zieht. Aber damit löst sich das Problem nicht, das er in der Retrospektion beschreibt. Denn als die Sprache zu entstehen beginnt, die er am Ende selbst spezifizieren wird und deren "Stil" über viele Jahrzehnte das Medium prägen, ja vielleicht bis heute dominant bleiben wird, da gibt es noch keine Sprache, sondern, wenn sie so wollen, ein Klima der Sprache, einen Imperativ, ein Verweigern und ein Fordern.
SHORTCODE (sugg. John W. Mauchly, by William F. Schmitt - 1950)
Memory "Variable" i = W0, t = T0, y = Y0
11 inputs werden folgenden words zugewiesen: U0, T9, T8, . . ., T0
Konstante: Z0 = 000000000000
ZI = 010000000051
Z2 = 010000000052
Z3 = 040000000053
Z4 = $$$TOO$LARGE
Z5 = 050000000051 [5.0]
"Equation number recall information" [Labels]: 0 = line 01, 1 = line 06, 2 = line 07
Short Code:
Equations Coded representation
-------------------------------------------------------------------------------
00 i= 10 00 00 00 W0 03 Z2
01 0: y = (sqrt abs t) + 5 cube t T0 02 07 ZS 11 T0
02 00 Y0 03 09 20 06
03 y 400 if<=to 1 00 00 00 Y0 Z3 41
04 i print, 'TOO LARGE'
print-and-return 00 00 Z4 59 W0 58
05 0 0 if=to 2 00 00 00 Z0 Z0 72
06 1: i print, y print-and-return 00 00 Y0 59 W0 58
07 2: T0 U0 shift 00 00 00 T0 U0 99
08 i = i - 1 00 W0 03 W0 01 Zl
09 0 i if<=to 0 00 00 00 Z0 W0 40
10 stop 00 00 00 00 ZZ 08
Code-Äquivalenzen:
01 - 06 abs value ln (n+2)nd power 59 print and return carriage
02 ) 07 + 2n (n+2)nd root 7n if= to n
03 = 08 pause 4n ifsto n 99 cyclic shift of memory
04 / 09 ( 58 print and tab
Sn, Tn, . . ., Zn quantities
Das erste implementierte hochsprachliche Programmier-Konzept, so wird es zumindest seit 1977 unwidersprochen behauptet, war das folgende, genannt "SHORTCODE":
Short-Code ist eine imperativische Sprache, die eben schlicht einem Imperativ folgt. Das Konzept stammt ebenfalls aus dem ENIAC-Team, aber nicht aus der sozusagen mathematischen Ecke Goldstine und von Neumann, sondern aus der pragmatisch-technischen Ecke des John W. Mauchly. Mauchly schlug 1949 diese sehr einfache algebraische Interpretersprache vor, in der Sie hier unseren etwas stupiden Algorithmus implementiert sehen. Sie werden feststellen, daß er bereits wieder "gut zu lesen ist". In Zeile 00 gibt es die Initialisierung von i=10, in Zeile 01 das Label 0, dahinter die Quadratwurzelformel. Dahin springt der Interpreter solange zurück, bis in Zeile 08 i den Wert "- 1" annimmt. Schon sehr klassisch und spaghetti-like.
Ich will Sie nicht mit Einzelheiten aufhalten, obwohl manche Einzelheit ganz interessant wäre. Short-Code wurde auf einem UNIVAC 1950 implementiert und bot dem Programmierer bereits, wie es im ACM-Journal hieß, ein "electronic dictionary". Jeder arithmetischen Operation war ein "Short-Code" zugeordnet, daher der Name. Sie sehen einige dieser Shortcodes im unteren Abschnitt. Short-Code kannte zwar keine Arrays, aber dafür ein zyklisches Shifting von Speicherworten, das zum Beispiel in Zeile 07 angestoßen wird. Die Vereinfachungen sind hier augenfällig: ein begrenztes "dictionary" von Computeroperationen ist geboren, die unmittelbar beschreiben, was mit den Operanden geschehen soll. Der offensichtliche Anfang einer Sprache.
"Mit Shortcode" heißt es in der Ankündigung der Firma Remington Rand, "kann jede mathematische Gleichung evaluiert werden durch das bloße Hilfsmittel, sie aufzuschreiben. Es gibt eine einfache symbolische Transformation der Gleichungen in den Code, ... die Notwendigkeit für spezielle Programmierungen wurde eliminiert. In unseren Vergleichen der Computerzeiten, was die Zeit manueller Programierungen betrifft, haben wir eine Geschwindigkeitssteigerung von mindestens 50 : 1 festgestellt." Nach dem Gewinn von 100:1, was die Speichergrößen der neuen von-Neumann-Maschine betraf, ging es nun, und zwar als Konstituens einer Sprache, um die Gewinnung von Speicher beim Menschen, nämlich um Zeit. Lacan würde sich freuen: Programmiergeschichtlich ist Sprache definiert als Instanz des bloßen Speicherzeitgewinns.
Und dann weiter: "Short Code will demonstrate its power as a tool in mathematical research and as a checking device for some large-scale problems" (Knuth:1977, 434), was doch wohl nichts anderes bedeuten kann, als daß es im Sinne Backus' auch um die Überprüfung von Priesterschaften ging, mit einem einfachen "tool", das den mathematischen Arkan-Praktikern auf den Zahn fühlen sollte.[7]
9 FORTAN und die Marinersonde
Short Code war nur zu erwähnen, weil es, als vermutlich historisch erste Interpretersprache, ebenfalls, wie von Neumanns Konzepte, aus dem ENIAC-Team herstammt. Ansonsten hat die Sache wie so vieles in den Anfangsjahren keine historische Bedeutung, obwohl es genau das repräsentiert, nachdem noch Jahre später alle auf der Suche waren, nämlich eine "algebraisch" orientierte Programmiersprache. Short Code verschwand von der Bildfläche, weil der Remington Rand UNIVAC nur von wenigen Wissenschaftlern genutzt wurde und es das nicht gab, was für die Lösung komplexer Probleme wissenschaftlich ingenieurstechnischer Art Bedingung ist, nämlich Kommunikation. Sie können es bei Jean Sammet, Grace Hopper, John Backus oder wem auch immer nachlesen, - die späten vierziger und frühen 50er Jahre sind in Amerika von der Abwesenheit dessen bestimmt, was man einen Diskurs über das Problem der sprachlichen Steuerung der neu enstandenen Digitalcomputer nennen konnte; kein nationaler oder internationaler Austausch, kaum eine Konferenz, keine periodische Veröffentlichung bis 1954. Dies ist ein weiterer Hinweis zur Stützung der These, daß der Computer als von-Neumann-Maschine eben kein den Forschungsorganisationen und der wissenschaftlichen Welt Amerikas bewußtes Ziel war.
Deshalb wird der Weg zu FORTRAN, den wir noch kurz verfolgen wollen, wiederum über ein gewaltiges Rüstungs-Projekt laufen, das, durch den inzwischen eiskalt gewordenen Krieg, zur höchster Wichtigkeit auflief. Gemeint ist der WHIRLWIND-Computer, der am MIT von 1945 bis 1952 (!) gebaut und ab 1951 zum Rückgrad des "Semiautomatic Ground Enviroment Air Defense System" (SAGE) wurde. Das erste große Computerprojekt der Navy und der Air-Force. Niemals sollte man verschweigen, daß dieses menschheitsgedenklich erste Computernetz der Urgroßvater der heutigen Internetwelt ist, dem freilich der `EMP'-Schock der Wasserstoffbomben noch bevorstand (Halbach:1996). WHIRLWIND verband nicht nur das erste Mal reguläre Radaroszilloskope, also schlicht gesagt, Fernsehbildschirme mit dem Computer, hielt nicht nur so ausgetüftelte Dinge wie den ersten Lichtgriffel ("light gun") und die vermutlich erste Eingabetastatur bereit, sondern zog, weil hier natürlich die militärisch induzierte Forschungsorganisation wieder gut funktionierte, die am Programmieren interessierten Wissenschaftler in Scharen an.
Die Sprache, deren "Stil" wir hier sehen, hieß der "Laning/Zierler Algebraic Compiler" und wurde auf dem WHIRLWIND entwickelt. Die Teilnehmer der ersten "Office of Naval Reserach"-Konferenz zum Thema Computersprachen 1954 waren davon hellauf begeistert, obwohl die Sache nach heutigen Maßstäben zumindest dem Begriff "compiler" nicht mehr standhält.
Ein kurzer Blick auf den Ablauf: Die Variablen v und a werden jeweils durch einen senkrechten Strich indiziert oder subskribiert, also arraymäßig aufgezählt, CP 1 oder 3 in Zeile 7 oder 11 bedeutet eine bedingte Sprunganweisung im besten Assembler-Stil, nämlich: ergab die vorhergehende Instruktion ein negatives Ergebnis, springe zu Label 1 oder 3. F hoch 1 ist die Wurzel- , F hoch 11 bedeutet die absolut-Instruktion, Zeile 3 bis 8 iterieren, um den Input v in die Variable a einzulesen, Zeile 9 bis 18 repräsentiert die Kernschleife. Nach ein paar Minuten werden wahrscheinlich die meisten von Ihnen dieser Laning Zierler Compiler gut lesen können.
Ich möchte jetzt John Backus von 1954 zitieren, also den Revolutionär. Wie Sie vielleicht wissen, gab der Laning/Zierler Compiler den unmittelbaren Anstoß für die Entwicklung von FORTRAN, die bei der IBM direkt nach der Konferenz von 1954 einsetzt und samt Compiler mehr als 18 Mannjahre dauern wird. Backus sagt 1954:
"Ein Programmierer mag für nicht zu unvernünftig gehalten werden, wenn er eigentlich nur die Formeln haben möchte für die numerische Lösung seines Problems, und vielleicht noch ein Plan dazu, der ihm zeigt, wie seine Daten von einer Speicher-Hierachie in die andere verschoben werden... Kein Zweifel, wenn er jetzt nächste Woche zu nachdrücklich so etwas verfolgen wollte, so würde er allerdings ein Fall für die psychiatrische Beobachtung. Aber vielleicht wird er ja nächstes Jahr dann ernster genommen." (Knuth:1977,456)
Hier also das Ergebnis, weniger als ein Jahr danach, November 1954: das IBM - FORmula TRANslation System, FORTRAN 0, mit John Backus als Chefentwickler.
"Wir meinen, das FORTRAN eine zweckmäßige Sprache bietet für die Formulierung von Problemen, die einer maschinelle Lösung zugeführt werden sollen ... Nach einem einstündigen Kurs in der FORTRAN-Notation wird der durchschnittliche Programmierer vollständig die Schritte verstanden haben, wie eine Prozedur in FORTRAN zu schreiben ist und zwar ohne alle zusätzlichen Kommentierungen" (Knuth:1977, 460).
Ihnen brauche ich über FORTRAN natürlich auch nichts mehr zu sagen, die DIMENSION-Deklaration in Zeile 1 verlangt ein 11-stelliges Array von REAL-Zahlen, Zeile 2 liest das irgendwie ein, Zeile 3 zeigt uns das legendäre DO-Statement von FORTRAN, das in der 0-Version die Besonderheit hat, die Anfangs- und Endlabel zu bennen, also auf deutsch heißt Zeile 3: Iteriere ab Zeile mit Label 3 bis Zeile mit Label 8 solange, bis die Variable J den Wert 11 angenommen hat, dann gehe zu Label 11 und Schluß. Das IF-Statement war damals nur zweiwegig, aber ansonsten ist es einfach FORTRAN.
In FORTRAN, der Sprache des "lazy character"s, wie Backus sich gelegentlich nannte, finden Sie auch jene legendäre Fehlprogrammierung, die der Software-Krise der 70er Jahre ihren Stempel aufdrückte und bekanntlich die Mariner-Sonde weit an der Venus hat vorbeifliegen lassen:
 (Horning:1979)
Dieser Fehler konnte auch vom 18 Mannjahre-Compiler des IBM-FORTRAN, auf dessen Schnelligkeit Backus noch 1980 stolz ist, nicht erkannt werden, da in der Sprachdefinition von FORTRAN Leerzeichen nicht signifikant sind, was wiederum mit der simplen Tatsache zu hat, daß FORTRAN vor allem eine Lochkartensprachen war, auf welchen Leerzeichen ebenfalls keine Rolle spielen. So daß also, wegen des Punktes statt des Kommas zwischen der 1 und der 3 der Ausdruck als implizite Deklaration der Variable DO3I verstanden wurde, der der Realwert 1.3 instantan zugewiesen wird. Richtigerweise hätte die Anweisung eine dreifache Iteration anstoßen müssen, all der Programmzeilen nämlich, die wir hier jetzt nicht sehen bis zur Sprungmarke CONTINUE oder dem Label 3. Nun gut, das ist Computer-Folklore, aber nicht nur.
10 Epilog
Die Genesis der Sprachstile des Programmierens bis einschließlich FORTRAN ist bekanntlich die Genesis der prozeduralen oder imperativen Sprachen. Die grundsätzliche Schwäche solcher Sprachen muß ich mit Ihnen wahrhaftig nicht diskutieren, das zu lehren ist Ihr täglich Brot. Es ist uns auch allen klar, daß die deklarativen und funktionalen Sprachen den hier gezeigten primitiv imperativen Konstrukten zumindest logisch weit überlegen sind, und ich finde die These von Jörg Pflüger absolut korrekt, daß die objektorientierten Sprachen der neueren Generation eine interessante Synthese zwischen prozeduraler Strukturierbarkeit und einem eher funktionalen logischen Design darstellen.
Ich habe Ihnen einen ersten diskursanalytischen Versuch vorgestellt, der eine Hypothese enthält, wie die Programmiersprachen entstehen. Seltsamerweise entstehen die Sprachen nicht aus dem Rekurs auf ein logisches Modell, obwohl die Maschine, die sie zu steuern haben, ganz explizit auf einem solchen Modell basiert. Das ist und bleibt ein Widerspruch, den es aufzuklären gilt. Ebenso die Frage, warum diejenigen, die das Design der Maschine, im vollen Wissen um das basale logische Modell, entwickelten, nicht gesehen haben, daß es einer effektiven und wohldefinierten Sprache bedarf, diese Maschine anzuschreiben. Meine These ist: Es war bei dem Archestrukt der von-Neumann-Maschine über Jahrzehnte nicht erkennbar, daß es sich um mehr als eine neue Rechen-Maschine handeln sollte, um mehr als ein mächtiges Kopfarbeitszeug, nämlich um ein Medium der Kommunikation. Die Entwicklung von FORTRAN zeigt überdeutlich, wie der Kommunikationsimperativ gleichsam von allen Seiten an die Maschine heranwuchs. Nur im Archestrukt der Maschine selbst war er offensichtlich nicht zu entdecken. Er wuchs aus der Ökonomie heran, aus der Arbeitsorganisation, vielleicht aus der Verführungskraft einer primitiven Numerik, die die Maschinen boten, aus dem Zahlenspiel, aus einem Spiel mit Stellen, Platzhaltern, Fort-Da-Mechanismen und dem sprachähnlichen Quid-Pro-Quo ihrer Binnenstruktur.
Kommunikationsmedien jedenfalls haben immer Sprachstruktur, wie wir spätestens seit Freud wissen. Sie sind, diesseits und jenseits explizit gesprochener Sprachen, von dem "Drängen" der Signifikanten in ihnen, also von Kontiguitäten und Substitutionen geprägt, für deren Wirken und Spuren man Diagramme und Graphen finden kann, also kaum logische, wohl aber probabilistische Generationsregeln.
[1] Die Berechnungen verzehrten, um Rundungsfehler zu vermeiden, eine imense Menge an Speicherplatz. "I have often been asked, "How big was the ENIAC storage?" The answer is, Infinite. The punched-card output was not fast, but it was as big as you wished. Every card punched out could be read into the input again, and indeed that is how Metropolis and Frankel managed to handle cycle after cycle of the big problem from Los Alamos."(Mauchly:1984, 547)
[2] Das Ende der Arbeit des ENIAC-teams markiert ein Gerichtsverfahren, das genau diesen Urheberstreit zum Gegenstand hat, vgl. Goldstine:1972.
[3] ...aus der, wie Mauchly berichtet, Ende 1945, bei der Berechnung des Los Alamos Problems, als ein Teil eines virtuellen Memory-Konzeptes stapelweise die Karten herauskamen, um dann per Hand gleich wieder in den daneben liegenden IBM-Card-Reader eingelesen zu werden.
[4] Arthur W. Burks räumt in seiner Beschreibung, die ich hier weitgehend übernommen habe, ein, daß der ENIAC alles andere als ein einfaches und leicht zu programmierendes Gerät war. Das "programming proper" erschien sogar den Zeitgenossen umständlicher und obskurer, als es die "zentrale Programmierung" der ähnlich aufgebauten Units des elektromagnetischen "differential analysers" war. Für dessen fest verdrahtete Rändelrädchen und Wahlschalter am Control Panel gab es längst, übrigens auch bei Zuse, recht fortgeschrittene Ideen einer programmierten Lochkarten-Steuerung, die durch entsprechende Relais die Stellungen des Control-Panels hätten setzen können. Die aberhundert Steckfelder des ENIAC, die die wüsten Kabel-Lianenbäume produzierten, die wir auf allen Photos sehen, schienen für eine zentrale, oder gar gespeicherte Programmierung also eher unbrauchbar zu sein.
[5] Friedrich Wilhelm Hagemeyer, ein theoretischer Physiker aus der alten DDR, der in den späten siebziger Jahren als Soziologe bei Lepenies promoviert hat, gibt uns in seiner Arbeit über Claude Shannons mathematische Kommunikationstheorie eine exemplarische Vorstellung von den Verwicklungen, die die Genesis wissenschaftlicher Entwicklungen in diesen vierziger Jahren auszeichnet. Diese Verwicklungen binden die Momente: Industrieforschung und -entwicklung, zivile Technikentwicklung, Kriegsforschung und Kriegswirtschaft, theoretische Physik und Mathematik, die Bildung von faktischen, autopoietischen und geplanten Forschungsorganismen zu einem wissenssoziologischen "Evolutionsmodell der technischen Entwicklung" (Hagemeyer:1979, 8ff) zusammen. Die Modell hat im Fall von Shannons revolutionärer Arbeit den Vorteil, auf einen einigermaßen konzisen terminus ad quem zusammenzulaufen.
[6] Der wohl wichtigere Irrtum von Neumanns liegt in seiner mathematisch unkorrekten Widerlegung der quantenmechanischen Theorie der "verborgenen Variablen", ein Fehlbeweis, der viel zur lang anhaltenden Geltung des "Kopenhagener Modells" der Quantentheorie beigetragen hat. Vgl. Gribbin:1995, 219ff
[7] Hoare:1980, 61
[^] top |
 |
