Letzte Änderung: 29.Mai 2014, 19:20h (Musikstück hinzugefügt)
SOUNDEREIGNIS
Zur Einstimmung der folgenden Reflexionen über das Programmieren aus philosophischer Sicht hier eine Sound-Komposition vollständig erstellt mit mathematischen Algorithmen: Sinfonia made completely by MAX Demos. Das Stück besteht aus 6 Klangspuren, wobei jede Spur einen Klang repräsentiert, der durch Softwareinstrumente erzeugt worden ist. Für alle die, die nur ‚Mainstream-Musik‘ kennen (Klassik gehört auch zum ‚Mainstream :-)) ist vom Hören abzuraten. Dies ist ein Sound für jene, die sich vom Mainstream gelöst haben und einfach Spass haben, unbekannte Klangräume zu durchwandern. Konkret habe ich mit Demoinstrumenten aus den Tutorials der Software MAX 6.1.7 sowie ableton live 9.1 und Max4Live herumgespielt.
ZWEI JUNGE MÄNNER TRETEN AUF
1. Am 22.Mai 2014 abends, nach einem sehr anstrengenden Tag, war ich Zeuge eines besonderen Schauspiels. Zwei junge Männer, beide langjährige Programmierer im Kontext innovativer multimedialer Anwendungen, Erfinder einer dafür eigens geschaffenen Programmiersprache – nennen wir sie Lx – dachten in zwei aufeinanderfolgenden Vorträgen laut nach, über das, was sie tun, wenn sie programmieren.
2. Dies ist ungewöhnlich, da diejenigen, die programmieren, es normalerweise einfach tun; sie schreiben ‚Kode‘, wie es so schön heißt. Verschachteln if’s und ‚while’s‘ und zahllose Schlüsselwörter der vielen ‚Bibliotheken‘ der fertigen Softwaremodulen, die heutzutage Programmiersprachen begleiten.
3. In der ‚reinen Lehre‘ ist s zwar anders, da gibt es Entwurfsmodelle, abstrakte Spezifikationen, seitenlange Anforderungen, die einem Programmierer sagen sollen, was er ‚eigentlich‘ zu tun hat; doch aus der Sicht eines Programmierers verschwimmen diese ganzen Texte und Diagramme sehr schnell zu einem Nezwerk von Kodierungsanweisungen, zu Seiten voller kryptischer Befehlsausdrücken, zu einem Programmtext seiner Sprache Lx. Was immer abstrakt vorher gedacht worden ist, er, der Programmierer verwandelt sich in einen ‚Kodierer‘.
4. Nicht so an diesem Abend. Die beiden Programmierer versuchten über ihr Kodieren nachzudenken.
ZUR GESCHICHTE DER KODIERUNG
5. Im ersten Vortrag ging es mehr um die historische Dimension, wie es von ersten rechnenden Maschinen (mit schönen Videoausschnitten über Konrad Zuse und seinen pionierhaften Experimenten mit seinen ersten Rechnern) mit direkter bitweiser Kodierung zu immer abstrakteren Programmiersprachen (Bits, Hexcode, mnemonischer Assemblercode, einfache Programmiersprachen wie Fortran und C, höhere objektorientierte Sprachen, und dann visuelle Kodierung). Da endete der historische Aufriss, da die Sprache Lx der beiden Programmierer solch eine visuelle Sprache war.
6. An dieser Stelle ruckelte es schon ein bisschen. Erstens gibt es ja heute schon viele verschiedene visuelle Programmiersprachen, und zum anderen war der Überblick unvollständig. Die Programmiersprachen selbst sind nur ein Teil der Geschichte; parallel mit den Programmiersprachen hat sich unter dem Oberthema ‚Softwareengineering‘ ein Denkmuster entwickelte, das die Programmiersprache nur noch als ein – wenngleich ein wichtiges – Moment sieht im Kontext von – stark vereinfachend – Problemstellung P, Anforderungsanalyse A, logisches Entwurfsmodell M und implementiertes System S. Kodierung ist Teil des implementierten Systems S bzw. steht in gewisser Beziehung zum logischen Entwurfsmodell. Der ‚Denkraum‘ des Softwareeinsatzes hat sich also erheblich ausgeweitet, und eine Geschichte der Programmierung, die diesen Denkkontext des Programmierens nicht berücksichtigt, wirkt mindestens unvollständig.
DIAGRAMMATISCHE REFLEXE ZTUM EIGENEN KODIEREN
7. Der zweite Vortrag wurde in gewisser Weise ‚persönliches‘ bis ’sehr persönlich‘. Hier sprach der Programmierende – nennen wir ihn B – in der Tat über seine Gedanken, wenn er programmiert bzw. über seine Gedankenwelt, vorher, während und nachher, und er sprach als jemand, der eine Programmiersprache entwickelt hat, sie benutzt, sie ‚warten‘ muss und sie weiter entwickelt.
8. Er benutze dazu Folien die angefüllt waren mit Handzeichnungen, Wortskizzen, Wort und Bildskizzen – fantastisch anzuschauen, eher Kunstwerken gleich, anregend, faszinierend. Seine begleitende Rede war auch keine normale Rede, keine geschliffenen Sätze, kein zusammenhängender Text; nein, es war eine Mischung aus Stammeln, Brummeln, meist mit dem Rücken zu den Zuhörer, eine Art Zwiegespräch mit den kunstvollen Linien in dem projizierten Bild; meist kryptisch, die Zuhörer/ Zuschauer meist in Lauerstellung in Erwartung, was denn jetzt kommen würde.
9. Es klingt komisch, aber ich habe es genossen, das war Denken unplugged, das war Kreativität des sich selbst reflektierenden Kodierens ‚live‘. Es dürfte nicht allzu viele ‚Programmierer‘ geben, die dies so tun würden. Als ich den Vortragenden anschließend darauf hin ansprach, wie oft er das so schon gemacht habe, sagte er auch, dass er dies so zum ersten Mal gemacht habe. Also eine Uraufführung; wunderbar.
PHILOSOPHISCHE REFLEXION
10. Schaltet man jetzt die philosophische Reflexion ein, dann ist als erstes zu bemerken, dass es offensichtlich nicht ganz selbstverständlich, keinesfalls einfach ist, etwas, was man tut, – hier das Programmieren, das Kodieren in einer Sprache Lx – in einer anderen Sprache Lxx auszudrücken. So beeindruckend und faszinierend die bildhaften und textuellen Fragmente waren, die B in seinen Folien präsentierte (für mich wahre ‚Kunstwerke‘), so wenig ließen diese vielen Fragmente einen größeren Zusammenhang klar erkennen. Dieser Eindruck verstärkte sich auch in dem anschließenden Gespräch mit den Zuhörern. Während die meisten ‚Anwender‘ waren, die die Sprache Lx (bzw. der Vorläuferversion) selbst zum Kodieren benutzten, und der Vortragende B aber gedanklich im Netzwerk seiner Konzepte ?herumirrte?, gab es auch Fragen zum ‚Denkraum‘, innerhalb dessen man Programmiersprachen entwickelt. Fragen und Antworten fanden nicht wo wirklich zueinander.
11. Während im ersten Vortrag noch ein wenig die Idee anklang, dass das Aufkommen von visuellen Sprachen eine ‚Verbesserung‘ für den programmierenden Menschen darstellt, blieb dieser reformerische, am Menschen orientierte, Ansatz immer mehr im Dunkeln. Im Zweikampf mit seinen eigenen Gedanken wurde nicht klar, ob und wie denn eine visuelle Programmiersprache Lx (zu der es, wie gesagt, viele Parallelen gibt) dem ‚menschlichen Denken‘ besonders entgegen kommt.
12. Während die Missionare des objektorientierten Programmierens zumindest versucht haben, Formen des alltäglichen Denkens mit einer ojektorientierten Sprache Lo in Verbindung zu bringen (was beim späteren sogenannten ‚modellbasierten‘ Programmieren schon nicht mehr so gelang), wurden solche Gedanken an diesem Abend nicht vorgetragen. Der Mensch in seinem Denken – hier der programmierende Mensch – blieb weitgehend außen vor. Schade. In diesem den Menschen und vorhandenen Programmieralternativen ausklammernden Denken blieben die Gedanken des suchenden Programmierers weitgehend ‚alleine mit sich selbst‘.
SOFTWAREENGINEERING IST NICHT GANZ NEU
13. Bemerkenswert an diesem Schauspiel ist die Tatsache, dass Software engineering (nicht ganz so gut: Softwaretechnik) nun ja keine wirklich ganz neue Disziplin mehr ist. An allen Universitäten/ Hochschulen, in denen Informatik gelehrt wird, gibt es seit mindestens 20 Jahren auch Softwareengineering. Und dennoch ist diese Art eines ‚zusammenhängenden Denkens‘ in den Köpfen der ‚aktiven Programmierenden‘ offensichtlich nicht präsent (als Vergleich: die Ideen eines Galilei haben ca. 100 Jahre gebraucht, bis sie zum Allgemeingut geworden sind).
14. Dennoch kamen man auch bei jenen, die Softwareengineering im größeren Zusammenhang denken, wissenschaftstheoretische bzw. philosophische Ansätze kaum bis gar nicht vorkommen, obgleich ein solches Denken hier eine Menge zu tun hätte.
15. Halten wir kurz fest: der Aspekt des menschlichen Denkens – nennen wir es hier das ‚kognitive Interface‘, die ‚Schnittstelle zum Denken‘; andere sprechen auch von ‚mentalen Modellen‘ – kam bei den beiden Vortragenden des Abends so gut wie nicht vor.
16. Der Einsatz einer Programmiersprache hat aber noch eine weitere Dimension, die nicht minder bedeutsam ist. Egal welche Programmiersprache Lx man benutzt, ein Programm in solch einer Sprache Lx – nennen wir es P(Lx) – muss irgendwann von einem realen Computer C ‚ausgeführt‘ werden. Dies bedeutet, was immer sich ein menschlicher Programmierer im Rahmen seines kognitiven Interfaces ‚gedacht‘ haben mag, als er P(Lx) erstellt hat, das, was ‚tatsächlich passiert‘, das entscheidet sich bei der realen Ausführung auf einem Computer C. Dies bedeutet, dass die Menge dieser Ausführungen von P(Lx) auf dem Computer C – nennen wir sie C(P(Lx)) – die ‚finale Bedeutung‘ von Lx darstellt. Man spricht auch von der ‚Semantik‘ (Bedeutung) der Sprache Lx mit Bezug auf C. Beispiel: mit den Ausdrücken von Lx will Programmierer B zwei ‚parallele Prozesse‘ a und b darstellen, gefolgt von Prozess c. Damit dieser Gedanke Sinn macht, muss sichergestellt sein, dass bei der Ausführung von a,b und dann c diese logische Struktur auch real umgesetzt wird, erst recht, wenn möglicherweise das Ergebnis von c z.B. dann wieder dem Prozess b als ein Teil seiner Eingangswerte zur Verfügung gestellt werden soll. Solche ‚Korrespondenzen‘ zwischen ‚intendierter‘ Bedeutung und ‚realisierter‘ Bedeutung herzustellen und zu ‚gewährleisten‘ ist generell nicht einfach und in genügend vielen Fällen unmöglich. Über diese ’semantischen Aspekte‘ der Programmiersprache Lx wurde gar nicht gesprochen. Auf Nachfrage kam eine Aussage, die so klang, also ob man darüber ’noch nicht nachgedacht habe‘.
17. Mir kommt es so vor, als ob das Thema ‚Semantik einer Programmiersprache‘ für viele Programmierenden das ist, was Tiefenpsychologen das ‚individuelle Unbewusste‘ nennen. Irgendwo wissen sie zwar, dass ihr Kode letztlich von einer Maschine abgearbeitet wird mit den daraus resultierenden Einschränkungen, aber tatsächlich berauschen sie sich lieber an ihren aktuellen Ideen und Fantasien und tun so, als ob das alles ja genau so auch umgesetzt wird. Wird es nicht. Hier gibt es viele zu klärende Fragen, also philosophisches Potential.
WITTGENSTEIN LÄSST GRÜSSEN
18. Vielen Programmierenden – den meisten? – ist nicht bewusst, dass der Denkweg von Ludwig Wittgenstein von seinem ‚Tractatus Logico Philosophicus‘ hin zu seinen ‚Philosophischen Untersuchungen‘ ein wunderbares Muster abgibt, innerhalb dessen man auch die Thematik der Bedeutung von Programmiersprachen reflektieren kann. Natürlich müsste man die Diktionen von Wittgenstein dem heutigen Sprach- und Denkgebrauch des Softwareengineerings etwas anpassen, aber die Grundideen (und die sich darin verbergenden kritischen Potentiale) sind weiterhin anwendbar.
19. Eine zentrale Idee Wittgensteins ist die Aufdeckung der Tatsache, dass die Ausdrücke einer Sprache L – und das gilt dann auch für Lx – ihre ‚Bedeutung‘ nur im Kontext sogenannter ‚Sprachspiele‘ haben. Im Fall der visuellen Programmiersprache Lx wäre ein solcher Kontext gegeben durch (i) die Programmierer, (ii) die Ausdrücke von Lx, (iii) die ausführenden Computer C (meistens mindestens mit Hardware und Betriebssystem) sowie (iv) die ‚Aktionen‘, die der programmierte Computer – z.B. als Roboter oder als Smartphone – beobachtbar ‚ausführt‘, sehr oft in ‚Interaktion mit einem (v) Benutzer‘, der ’seine‘ ‚Vorstellungen‘ (:= mentale Modelle) des Geschehens hat.
20. Das Softwareengineering versucht – im idealen Fall – die potentiellen Sprachspiele ‚vorweg‘ zu analysieren, zu modellieren, und entsprechend zu implementieren. Die Grenzen liegen bei der ‚Vorwegnahme‘ des potentiellen Benutzers.
Eine Übersicht über alle bisherigen Blogeinträge nach Titeln findet sich HIER.
