Inwiefern sind Programmiersprachen Sprachen?

Im Funktionssystem der Technik spielt die Programmiersprache eine entscheidende Rolle. Es gibt kaum mehr eine technische Entwicklung, die nicht durch Computer unterstützt oder gar ermöglicht wird. Die Programmier-Sprache ist eine eigenständige Erfindung, die die massenhafte Verbreitung der Computer überhaupt erst möglich machte. Die Programmiersprache entspricht in gewisser Hinsicht dem Buchdruckes von Gutenberg oder dem Benzinmotores von Otto, die beide eine bereits vorhandene Ware, nämlich das Buch und das maschinell angetriebene Fahrzeug massentauglich machten. Wenn wir die Computer – wie in den Anfängen – ohne Programmiersprachen programmieren müssten, würden sie heute noch in den Forschungslaboratorien statt auf jedem Schreibtisch stehen.

Computer sind programmierbare Automaten, und in ihrer entwickelten Form werden sie durch Programme programmiert, die ich einer Programmiersprache wie etwa Cobol oder Pascal zurechne. Computerprogramme werden als Texte in einer Programmiersprache geschrieben. Als “Schweizer” könnte man bezüglich der Programmiersprache fragen, wer hat “es” erfunden? Ich habe diese Frage einmal K. Zuse gestellt, worauf er in der ihm eigenen Selbstverständlichkeit antwortete: “Ich”, was mir auch zeigte, dass er die Frage gar nicht verstanden hat.

Die Frage, die ich jetzt stelle, ist etwas subtiler: Was hat der Erfinder der Programmiersprache erfunden. Eine erste Antwort lautet: Es gibt DIE Programmiersprache gar nicht, es gibt nur ProgrammierspracheN. Cobol und Fortran gehören zu den ersten Programmiersprachen, die als solche bezeichnet wurden. Die Entwickler dieser Programmiersprachen sagten explizit, dass man von einem Programmierer nicht erwarten könne, dass er so komplizierte Maschinen begreifen könne. Deshalb kann von einem Programmierer kaum verlangt werden, dass er über die zu verwendende Zahlendarstellung oder gar über die Eigenschaften der Speichervorrichtung entscheidet. Man wollte das Programmieren so einfach machen, dass auch weniger begabte Menschen diese Tätigkeit ausführen können. Nachdem die Entwickler Fortran geschaffen hatten, erkannten sie, dass es zuvor schon eine Art Computersprache gab, die sie dann im Unterschied zu der “höheren” Computersprache als Maschinensprache bezeichneten.

K. Zuse hat seine “Programmiersprache” erst viel später überhaupt veröffentlicht, nämlich erst als praktisch jedermann erkannt hatte, wie wichtig die Programmiersprache ist – was er als vermeintlicher Erfinder offenbar nicht gemerkt hat. Er sprach aber auch dann noch von einem Kalkül und nicht von einer Sprache – was die Sache wohl auch heute noch besser bezeichnen würde.

Das Anliegen der IBM-Intelligenzia – die K. Zuse auch in jeder anderen Hinsichht den Rang abgelaufen hat – war gerade nicht eine treffende Bezeichnung für den Sachverhalt zu finden, sondern viel mehr im Gegenteil für kognitiv nicht sehr belastbare Fliessbandprogrammierer eine idiotensichere Metapher zu prägen. Die “Programmiersprache” Cobol – die IBM-komerziell noch viel erfolgreicher war als Fortran – wurde bewusst möglichst “sprach-ähnlich” konzipiert. Erst sehr viel später dämmerte die Einsicht, dass Programmiersprachen einer eigene Logik gehorchen, die pädagogisch gerade durch Programmiersprachen vermittelt werdenmuss. Die Programmiersprache Pascal wurde an der Hochschule zur Ausbildung einer kognitiv hochschultauglichen Programmierelite entwickelt. Im soziologischen Fachjargon wechselte genau in dieser Zeit die Einschätzung darüber, wie sich die Automatisierung auf die Qualifikations der Arbeitenden auswirkt. Vorher glaubten die Soziologen – wie die IBM-Informatiker – dass Automatisierung zu einer Dequalifikation führe, nachher glaubten sie wie die Hochschul-Informatiker, dass die Qualifikation zunehme.

Als Erfindung teilt die Programmiersprache das Schicksal vieler genialen Erfindungen. Sie liegen im Nachhinein so sehr auf der
Hand, dass sie gar nicht als Erfindungen wahrgenommen werden. Der naiv interpretierte Wortteil “-sprache” verleitet zusätzlich zur
Annahme, dass Programmiersprachen wie unsere Sprachen zwar konkret geformt sind, aber als Sprache überhaupt immer schon da waren. Die Sprache kennt ja auch keine Erfinder. In diesem Sinne werden Programmiersprachen auch oft als künstliche Sprachen bezeichnet, wobei das Attribut “künstlich” nicht auf die Sprache als erfundenes Produkt bezogen wird, sondern lediglich darauf, dass die Syntax oder die Form der Sprache eindeutig und eingeschränkt ist.

Die Frage, worin die Erfindung DER – begrifflich gemeinten – Programmiersprache besteht, kann ich für jede einzelne oder jede konkrete Programmiersprache beobachten. Ich frage dazu, was ich beim Programmieren egal in welcher Sprache mache. Vordergründig schreibe ich Texte. Aber eigentlich lege ich die Steuerung eines Prozessors fest. Ich richte den Prozessor so ein, dass sein Schaltungszustand ganz bestimmte Sequenzen durchläuft. Als primitivste Form eines Programmes betrachte ich die Nockenwalze einer Musikdose. Wenn ich eine solche Nockenwalze herstelle, schreibe ich nur sehr bedingt einen Text. Ich stecke vielmehr die Nocken an die richtigen Stellen der Walze. Ich kann in einer Spieldose – was üblicherweise gemacht wird – die tongebenden Zungen so angeordnen, dass sie eine Tonleiter bilden. Dann muss ich die Nocken auf der Walze so setzen, dass sie die Tonzungen in der richtigen Reihenfolge bewegen, damit eine bestimmte Melodie zu hören ist.

Wenn ich die Tonzungen nach der Tonleiter anordne, bestimme ich, wie die Nocken für eine bestimmte Melodie angeordnet werden

müssen. Ich kann aber natürlich umgekehrt zuerste die Nocken auf der Walze anordnen und damit die Anordnung der Tonzungen für eine bestimmte Melodie bestimmen. Das scheint zunächst ein relativ unsinniges Verfahren darzustellen, es ist aber genau dieses Verfahren, dass der Programmiersprache zugrunde liegt. Die Idee – nachdem man sie einmal hat – ist ganz einfach. Ich baue die Maschine so, dass die Programmierung einfach wird. Die Maschine wird dabei erheblich komplizierter, aber das Programmieren wird dafür erheblich einfacher.

Jetzt stellt sich die Frage, inwiefern das Programmieren einfacher gemacht werden kann, erneut. Und wieder besteht die Vereinfachung in einer memotechnischen “Spachähnlichkeit”, die ich anhand eines Beispiels illustriere. Eine Stadt könnte so gebaut werden, dass ein Pilot lesen kann, lesen kann, wie sie heisst, wenn er über die Stadt fliegt. Man würde dazu die Häuser entsprechend anordnen, so wie man Nocken auf der Musikwalze beliebig anordnen kann, wenn die Tonzugen erst nachher angeordnet werden. Die Stadt wär durch eine solche Anordnung der Häuser kaum betroffen und die Menschen in der Stadt würden davon kaum etwas mitbekommen. Nur die Piloten könnten sich leichter orientieren.Ich habe einen Video von einem Piloten, der während des Anfluges auf Aosta in Italien den Fluggästen sagt, dass er im Begriff ist, in Sitten im Wallis zu landen, wohin der Flug eigentlich auch gehen sollte.

Der Steuerungsmechanismus eines Computers kann so eingerichtet werden, dass die Programmierung in diesem Sinne sekundär lesbar wird. Eine Addition von zwei Zahlen wird dann beispielsweise durch ein Programmteil bewerkstelligt, dass die “Nocken” so angeordnet hat, dass ADD lesbar wird. Der Anschaulichkeit halber, kann man sich Lochkarten vorstellen, deren Löcher nach dem Muster von Buchstaben verteilt sind. Dabei lege ich also zuerst die Programme fest und konstruiere die Maschine dann entsprechend, dass die Programme die richtige Melodie spielen.

Als Programmiersprache erscheint so ein entsprechend eingerichteter Prozessor. Die Programmiersprache ist also eine Maschine, die es mir erlaubt, Programme herzustellen, die ich als Texte lesen kann. Die Maschine versteht oder interpretiert also keine Programmiersprache, sie IST die Programmiersprache. Die Programmiersprache hat demnach mit Sprache nichts zu tun – was K. Zuse ahnte -, als Programmierer kann ich aber die Programme trotzdem wie Texte lesen.

Die “Technische Intelligenz” hat mit ihrer “Sprach”-Metapher einen inversen Grund gelegt, Sprache überhaupt zu verstehen. Nachdem ich verstanden habe, was eine Programmiersprache ist, kann ich die Richtung der Metapher drehen. Wir werden sehen.

Post a comment or leave a trackback: Trackback URL.

Comments

  • PB  On April 22, 2012 at 9:37 PM

    Gute Argumentation! Noch zwei Anmerkungen:

    1) Kann nicht einfach gesagt werden, daß ein Computerprozessor die “technische Realisierung” der Booleschen Algebra vermittels “Schaltalgebra” darstellt [siehe dazu auch die Masterarbeit von Claude Shannon: http://en.wikipedia.org/wiki/A_Symbolic_Analysis_of_Relay_and_Switching_Circuits%5D?
    Wobei in der Folge dann von der maschinennahen Realisierung immer weiter “abstrahiert” wurde -> Maschinensprache -> Assembler-Mnemonics -> diverse Programmiersprachen höherer Generationen bis hin zur heutigen model-driven Entwicklung, bei der die Programmierung als “visuelle Modellierung” erfolgen soll.

    Und läuft das im Kern nicht auf Deine Argumentation hinaus? Das heißt: wir haben es bei Programmiersprachen letztlich nur mit einem geregelten “Inventar von maschinellen Steueranweisungen” (einem kybernetischen Mechanismus) zu tun, wobei mit zunehmender Abstraktion und Einsatz immer performanterer Tools (Assembler, Compiler, Interpreter, etc.) nicht nur die Programmier-Produktivität erhöht werden konnte, sondern Probleme, die programmiertechnisch gelöst werden sollen, auch immer näher an das Verständnis der jeweiligen “Problemdomänen” heranrücken können (Stichwort im Enterprise-Sektor: narrowing of the business – IT gap, z.B. durch Geschäftsprozeßmodelle, die in technische Modelle und dann in ausführbaren Programmcode transformiert werden sollen).

    2) Die “Vereinfachungsthese” (also: höhere Programmiersprachen sind einfacher als das Hantieren mit maschinensprachlichen Befehlssequenzen) ist nur die eine Seite der Komplexitätsmedaille. Es ist sinnvoller, von der “Figur der Komplexitätsreduzierung (durch Abstraktion, Ausdifferenzierung von Ebenen, wechselseitigen re-entries von kontingent-notwendig) und der gleichzeitigen Steigerung von Komplexität” auszugehen. Also:

    a) Einerseits wird von maschinen- und betriebssystemnahen Details immer weiter abstrahiert

    b) Andererseits steigt die Komplexität auf der jeweiligen Programmier- und Modellierungsebene immens an.

    Bspl.: eine objektorientierte Programmiersprache wie “Java”. Die Syntax der Basisausgabe “(Standard Edition) ist geschenkt und kann in einigen Stunden gelernt werden. Aber die Komplexität steckt in:
    * den Tausenden von Klassen und Interfaces der zugehörigen Sprachbibliothek (in der Standard und Enterprise Edition) – der API -,
    * in unzähligen Frameworks, die höhere Funktionalität zur Verfügung stellen,
    * in “Design Patterns” (die Vorschläge machen, wie Klassen / Interfaces am besten bei der Lösung typischer Realisierungsprobleme zusammenspielen sollten),
    * in Programming-Best Practices (Stilvorgaben, Refactorings, Unit-Tests, usf.)
    etc.

    Fazit: Wer glaubt, daß die Programmierung “einfacher” wird, weil oft nicht mehr maschinennah programmiert wird, hat Recht und Unrecht zugleich.

  • kybernetiks  On April 23, 2012 at 10:33 AM

    > “Kann nicht einfach gesagt werden, daß ein Computerprozessor
    > die “technische Realisierung” der Booleschen Algebra darstellt?”

    Nein, das Problem der boolschen Algebra besteht darin, dass sie nicht in der Zeit arbeitet. Sie steht für ahistorisches Denken, also für ein Denken das durch die Kybernetik/Systemtheorie ersetzt wurde.

    > ….auch immer näher an das Verständnis der jeweiligen
    > “Problemdomänen” heranrücken können

    nein, das betrifft einen sehr wichtigen Punkt. Ich kann den Computer als Maschine, also als kybernetischen Mechanismus betrachten und ich kann unabhängig davon – also ohne einen Computer zu verwenden – einen Unternehmens/Organisationsprozesse kybernetisch modellieren.
    Das sind zwei völlig verschiedene Dinge – wenn ich sie nicht heil- und begriffslos vermenge, wie es die übliche IT-Redeweise tut.

    > 2) Die “Vereinfachungsthese” (also: höhere Programmiersprachen
    > sind einfacher als das Hantieren mit maschinensprachlichen
    > Befehlssequenzen) …

    Eine “Vereinfachungsthese” stammt von den Cobol/Fortran-Erfindern, sie zielte auf idiotische Programmiere.

    Eine ganz andere Vereinfachungsthese beruht darauf, dass Prozesse modularisiert und dann hinter die Sichtbarkeitsgrenze gesetzt werden. Ich muss mich beim Programmieren beispieslsweise nicht mehr darum kümmern wie eine “while-Schlife” realisiert wird. Aber ich muss mich darum kümmern wie ich sie verwende. Das heisst ich werde von bestimmten Aufgaben entlastet und kann deshalb andere Aufgaben übernehmen. Meine Tätigkeit wird dadurch wohl anspruchsvoller nicht einfacher.

    Auch hier geht es also um zwei sehr verschiedene Ideen von Vereinfachung. Deine Folgerung vermengt die beiden Aspekte – die in der Automatisierungs-Soziologie (Qualisfizierungs/Dequalifizierung-Diskussion in den 1970er) ausführlich behandelt wurden.

Trackbacks

Feedback ist erwünscht!