Ich habe zwei Javascript-Bibliotheken (D3.js und p5.js) für mich entdeckt, um damit sprachliche Daten zu visualisieren. Ich lernte damit nicht nur eine Methode kennen, um ein Problem zu lösen, sondern bin nebenbei auf etwas Interessantes gestoßen: Ich glaube, es gibt einen engen Zusammenhang zwischen der Wahl einer Programmiersprache und wissenschaftlichen Denkstilen. Und dass es sich lohnt, als (auch nicht programmierende/r) Geisteswissenschaftler/in darüber nachzudenken. Doch der Reihe nach.
Einfach hässlich
Wenn Sie eine Million Tweets analysieren müssen, werden Sie auf Software zurückgreifen, um dies zu tun. Sie können die Tweets in eine Tabelle (Excel, Calc, was auch immer) schmeißen, bestimmte Features der Tweets erheben und das Vorkommen der Features auszählen. Dann wollen Sie vielleicht ein Balkendiagramm erstellen, um zu visualisieren, wie sich die Anzahl der Tweets über die Zeit verteilt. Dafür verwenden Sie den Diagramm-Assistenten, der Ihre Zahlen ruckzuck in ein Balken-, Linien- oder klaglos auch Tortendiagramm verwandelt – wenn Sie es wirklich wollen auch in 3d.
Google Bildersuche „Diagramm-Assistent“
Ihr Diagramm wird hässlich aussehen, aber das stört Sie vielleicht nicht.
Einfach komplex, ohne Fummeln
Anstelle von Excel oder Calc können Sie aber auch R verwenden. R ist eine Programmiersprache, die sich besonders gut für statistische Analysen und Visualisierungen von großen Datenmengen eignet. Eine Google-Suche „r vs excel“ deckt schnell die üblichen Argumente auf, die für R sprechen (z.B. von Isaac Petersen):
- bessere Datenmanipulation möglich
- Automatisierbarkeit von Analysen
- schneller
- Reproduzierbarkeit
- kostenlos
- OpenSource
- aktive Entwickler/innen-Gemeinde, die Pakete für spezielle (und alle möglichen) Bedürfnisse entwickelt
- …
Fast überall wird auch ein Nachteil genannt: Der Einstieg ist etwas schwierig, die Lernkurve steiler und man muss programmieren. Aber als Akademikerin müssen Sie sowieso auf R setzen, das machen alle so.
Glückwunsch, Sie arbeiten jetzt also mit R. Sie gehören jetzt zu den Informierten. Doch bald werden Sie merken: Es gibt doch noch einen Kreis von R-Nutzer/innen, die noch informierter sind. Diese verwenden nämlich für die Erstellung ihrer Visualisierungen nicht die Standardfunktionen von R, sondern jene eines speziellen Pakets, „ggplot2“:
ggplot2 is a plotting system for R, based on the grammar of graphics, which tries to take the good parts of base and lattice graphics and none of the bad parts. It takes care of many of the fiddly details that make plotting a hassle (like drawing legends) as well as providing a powerful model of graphics that makes it easy to produce complex multi-layered graphics. (http://ggplot2.org/, Hervorhebungen Herr Sprechtakel)
Interessant, wie emotional man über Programmiersprachen sprechen kann! Kein Rumfummeln und kein Ärger mehr bei der Verwendung des Pakets ggplot2 in R und trotzdem die Möglichkeit, komplexe Diagramme zu erstellen:
Google Bildersuche „ggplot2“
Die Wahl zwischen Excel oder R: The Software is the Message
Welche Auswirkungen hat nun Ihre Wahl des Werkzeugs auf das Ergebnis Ihrer Forschung? Sie könnten der Ansicht sein: Naja, Excel oder R, das sind ja nur Tools. Das eine ist vielleicht besser für den Zweck geeignet als das andere. Sie glauben aber daran, dass das Tool Ihrer Forschung untergeordnet ist. Es macht, was Sie wollen, und wenn es das nicht tut, dann suchen Sie sich ein anderes.
Falsch.
Mit der Wahl des Tools ordnen Sie sich einem wissenschaftlichen Denkstil unter und reproduzieren ihn wieder. Denn ein Tool ist weit mehr, als ein Tool. Software ist Kultur.
Der Begriff des Denkstils geht auf den Immunologen und Erkenntnistheoretiker Ludwik Fleck (1896-1961) zurück. Ein Philosophe und eine Biologin verstehen sich wissenschaftlich nicht, da sie unterschiedlichen Denkkollektiven angehören, die unterschiedliche Denkstile pflegen, die inkompatibel miteinander sind. Diese unterschiedlichen Stile äußern sich in verschiedenen Kategoriensystemen, unterschiedlichen Auffassungen über angemessene Methoden oder darüber, was eine Wahrheit ist. Sichtbar werden die unterschiedlichen Denkstile so:
Ich möchte nur noch zwei Mittel erwähnen, über die der wissenschaftliche Denkstil verfügt, um seinen Produkten den Charakter einer Sache zu verleihen.
- Eines von ihnen sind technische Termini […].
- Das zweite Mittel ist das wissenschaftliche Gerät […].
Wer es versteht, in ein Fernrohr zu schauen und an den Saturn zu denken, benutzt damit allein bereits einen bestimmten abgegrenzten Denkstil.
Fleck: Das Problem einer Theorie des Erkennens (1936)
Software, so viel ist klar, ist nach Flecks Terminologie ein wissenschaftliches Gerät. Software prägt damit Denkstile mit und ist in wissenschaftliche Kulturen eingebettet. Diese Erkenntnis existiert schon länger und wird z.B. von Lev Manovich vertreten:
Software as a theoretical category is still invisible to most academics, artists, and cultural professionals interested in IT and its cultural and social effects. […] Software is the interface to our imagination and the world – a universal language through which the world speaks, and a universal engine on which the world runs.
Manovich 2014: 80
Manovich bezieht sich auf McLuhans „The Medium is the Message“ wenn er sagt: „The Software is the Message.“ Computer sind ein Metamedium, mit dem das Schreiben von neuer Software eine kulturelle Aktivität geworden ist. Diesen Gedanken – Manovich verweist darauf – findet sich bereits bei Kay und Goldberg (1977): „the computer, viewed as a medium itself, can be all other media“.
Alan Kay mit einem Prototypen des Dynabooks. Als Metamedium sollte dieser Computer bereits Kindern ermöglichen, beliebige andere Medien damit zu nutzen oder neue zu schaffen, indem sie z.B. programmieren (Quelle: Marcin Wichary from San Francisco, U.S.A. – Alan Kay and the prototype of Dynabook, pt. 5)
Wenn Sie also Excel statt R (oder umgekehrt) wählen, um Ihre Daten weiterzuverarbeiten, fügen Sie sich damit einem der Software innewohnenden Denkstil unter. Bei Excel ist es offensichtlich – Sie sind sogar sehr beschränkt, welche Typen von Visualisierungen Sie beispielsweise erzeugen. Bei einem flexibleren Tool wie R gilt das aber nach wie vor, wie man z.B. an folgendem Zitat sehen kann, das R anpreist:
The visualizations you can create in R are much more sophisticated and much more nuanced. And, philosophically, you can tell that the visualization tools in R were created by people more interested in good thinking about data than about beautiful presentation. (The result, ironically, is a much more beautiful presentation, IMHO.) (http://www.michaelmilton.net/2010/01/26/when-to-use-excel-when-to-use-r/)
Wenn Sie R verwenden, um Ihre Daten zu visualisieren, dürfen Sie sich also nicht zuerst mit ästhetischen Kriterien befassen, sondern von den Daten her denken. Sie dürfen aber gleichzeitig sicher sein, dass die Visualisierung ambitionierten ästhetischen Kriterien genügt, gerade weil Sie sich nicht damit befassen dürfen. Aber glauben Sie mir: Wenn Sie mit R gearbeitet haben, erkennen Sie meist auf den ersten Blick, dass die Grafik von R stammt.
Und wie entsteht Software? Der Code und das Coden
Software ist eine Sammlung von Programmcode in einer bestimmten Programmiersprache (sehr lesenswert dazu: Paul Ford, What is Code). R ist bereits eine Programmiersprache. Excel wurde wahrscheinlich in Programmiersprachen wie C++ und C# programmiert. Eine Programmiersprache erlaubt die Formulierung von Anweisungen an den Computer in einer sog. Hochsprache, die in Maschinencode, der den Computer steuert, übersetzt wird. Es gibt sehr viele verschiedene Programmiersprachen, die sich nicht nur in ihrem Vokabular unterscheiden, sondern auch bestimmte Wege, wie man Software baut, begünstigen. Möchte ich eben mal ein bisschen Code schreiben, um in einer Textdatei alle Wörter, die mit „Ent-“ beginnen, auszuzählen? Oder gibt es ein ganzes Team, das nach einem genauen Plan Software erstellt, die modular aufgebaut und erweiterbar ist und die mit riesigen Datenmengen effizient umgehen können muss?
Es gibt das technische Argument, das für die Wahl einer Programmiersprache spricht. Es gibt aber auch ganz andere Argumente:
But the choice of a main programming language is the most important signaling behavior that a technology company can engage in.
Tell me that you program in Java, and I believe you to be either serious or boring.
In Ruby, and you are interested in building things quickly.
In Clojure, and I think you are smart but wonder if you ship.
In Python, and I trust you implicitly. In PHP, and we sigh together.
In C++ or C, and I nod humbly. In C#, and I smile and assume we have nothing in common.
In Fortran, and I ask to see your security clearance.
These languages contain entire civilizations.
(Ford 2015: What is Code?)
Programmiersprachen sind Ausdruck kultureller Praxis. Und genau so, wie es schwierig ist, bewusst und absichtlich neue natürlichsprachliche Varietäten zu begründen, ist es schwer, eine neue Programmiersprache zu erfinden:
Making a new language is hard. Making a popular language is much harder still and requires the smile of fortune. And changing the way a popular language works appears to be one of the most difficult things humans can do, requiring years of coordination to make the standards align. Languages are large, complex, dynamic expressions of human culture.
(Ford 2015: What is Code?)
Aus kulturwissenschaftlicher Sicht würde ich deshalb behaupten: Die Erfindung oder Weiterentwicklung einer Programmiersprache und die Wahl einer Programmiersprache hat sehr wenig mit technischen Aspekten zu tun, wie sie in der Informatik gelehrt werden. Nein, es hat viel mehr damit zu tun, ob man sich einer kulturellen Praxis, einer Coding Culture zugehörig fühlt, sich von einer kulturellen Praxis, einer Coding Culture abgrenzen möchte oder eine neue begründen will.
Allerdings ist diese Sicht noch etwas vereinfachend, denn genau genommen gibt es nicht nur Programmiersprachen und Software, sondern auch noch Entwicklungsumgebungen und Programmierstile (vgl. dazu auch Ford 2015). Ob ich mein Perl-Script in einem Texteditor erstelle oder dafür eine professionelle Entwicklungsumgebung wie Eclipse verwende, macht ebenso einen Unterschied, wie ob ich dem objekt- oder komponentenorientierten Programmierparadigma folge. Vereinfachend verstehe ich unter „Wahl der Programmiersprache“ die Kombination von Programmiersprache, Umgebung und Paradigma.
Die Wahl und der Stil: Excel, R, D3.js oder P5.js?
Programmiersprachen werden heute im Netz vorgestellt, dokumentiert und in Form von damit erstellten Programmen illustriert. Und an großen „Entwicklerkonferenzen“ versammeln sich die Anhänger/innen der Programmiersprache und vergewissern sich gegenseitig ihrer Programmierkultur.
Die Kulturen könnten nicht unterschiedlicher sein. Berühmt ist etwa folgendes Zeugnis kultureller Praxis an einer Entwicklerkonferenz von Microsoft:
Der (damalige) CEO von Microsoft, Steve Ballmer, repräsentiert eine Kultur des weißen, lauten und selbstbewussten Mannes, der mit seiner Programmierung die Firma zum Marktleader bringt. Wer mit Microsoft-Produkten programmiert, geht strategisch, systematisch und effizient vor – so das Versprechen.
Wie viel Ballmer-Coding-Culture steckt in Ihrem Excel-Diagramm?
Der Kontrast wird vielleicht sichtbar, wenn wir uns P5.js zuwenden. Das ist eine Javascript-Bibliothek (man programmiert also mit Javascript – lesenswert zu den Hintergründen dieser Sprache wieder Ford, Kapitel 5.7), die ihre Wurzeln in der Programmiersprache Processing hat. Die Hauptentwicklerin (!) Lauren McCarthy und ihr Kollege Dan Shiffman präsentieren die Programmiersprache so (Quelle: http://hello.p5js.org/):
Lauren McCarthy und Dan Shiffman präsentieren p5.js (Klick fürs Original)
Diese Programmiersprache steht für eine andere Coding Culture: weiblich, spielerisch, künstlerisch, cool könnten vielleicht die Attribute sein. Das bereits länger existierende und mit p5.js verwandte Processing präsentiert sich textlich so:
But the most important thing about Processing and culture is not high-profile results – it’s how the software has engaged a new generation of visual artists to consider programming as an essential part of their creative practice.
(https://processing.org/overview/)
Klar, man kann rein technisch mit p5.js oder Processing Dinge tun, die man mit Excel nicht machen kann. Mit C++, Java oder Python allerdings schon – aber man macht es nicht (kaum), da diese anderen Programmiersprachen nicht den kulturellen Nährboden dafür bieten. Die entsprechenden Communities sind von anderen Denkstilen durchdrungen.
p5.js ist, wie gesagt, eine Javascript-Bibliothek. Mit p5.js und Javascript, sowie weiteren Technologien wie HTML5, Canvas und SVG ist es möglich, komplexe Anwendungen für Webbrowser zu entwickeln. Das ist noch nicht lange so. Früher konnten Browser weniger (HTML ließ nicht sonderlich viel zu, außer das Erstellen von statischen Webseiten) und für komplexere Anwendungen mussten andere technische Lösungen gefunden werden, die oft auf proprietären Technologien, die jeweils nur auf einem Betriebssystem liefen, beruhten. Die modernen Webtechnologien haben es also sehr vereinfacht, komplexe Anwendungen zu entwickeln, die in jedem aktuellen Browser auf allen Betriebssystemen laufen. Google konnte z.B. dank dieser Technologien ein eigenes „Office“ fürs Web, „Google Docs“, entwickeln.
Selbstermächtigung
Bestimmte Technologien und Programmiersprachen führten also zu einer neuen Art von Softwareentwicklung, die vielleicht beschrieben werden kann als:
- (Meist) OpenSource (mit Ausnahmen wie Google Docs) – der Quellcode liegt offen da und kann (je nach Lizenz) einfach weiterverwendet und für neue Applikationen angepasst werden.
- Entprofessionalisierung: Nicht nur Informatiker/innen können ansprechende Anwendungen bauen, sondern auch informatiktechnische Laien.
- Experimentierfreudigkeit: Software wird nicht nur nach strikten Bauplänen systematisch entwickelt, sondern experimentierend und im positiven Sinn eklektisch und erratisch gebaut.
- Selbstermächtigung: Die grafischen Benutzeroberflächen vereinfachten zwar die Benutzung der Computer, nahmen den Nutzer/innen aber auch immer mehr Einflussmöglichkeiten auf das System. Die aktuellen Smartphones und Tablet-Computer in Verbindung mit App-Stores sind ein gutes Beispiel: Auf ihnen soll konsumiert und nicht Neues geschaffen werden, schon gar nicht unter Umgehung der Oberfläche. Durch die Aspekte OpenSource, Entprofessionalisierung und Experimentierfreudigkeit ist es jedoch wieder einfacher geworden, sich gegenüber dem Computer (und den Computerkonzernen) selbst zu ermächtigen, also zu programmieren.
Diese neue Art von Softwareentwicklung führte zu einer Bibliothek wie p5.js (siehe hier und hier für ein paar Beispielanwendungen).
In der Wissenschaft ist eine andere Javascript-Bibliothek, D3.js, wahrscheinlich erfolgreicher. D3.js eignet sich besonders gut, um große Datenmengen zu visualisieren. Die Website präsentiert in einem „Visual Index“ viele Beispiele für solche Visualisierungen.
„Visual Index“ auf der Website von D3.js (Ausschnitt)
Einerseits eröffnet diese Bibliothek eine enorme Vielfalt an interaktiven und neuen Formen von Visualisierungen, die weit über Visualisierungen in Excel oder auch R hinaus gehen. Auf den zweiten Blick aber sieht man selbst in sehr großen Beispielsammlungen eine gewisse Uniformität: Eine bestimmte Ästhetik, bestimmte wiederkehrende Formen und Datensatztypen als Grundlagen für die Visualisierungen. Es wird der Denkstil eines Denkkollektivs „Datenvisualisierung“ sichtbar, beeinflusst von technischen Grundlagen und einer spezifischen Programmiersprache.
Im Gegensatz zu p5.js scheint mir die D3.js-Community systematischer und weniger experimentell zu sein. Die Systematik zeigt sich beispielsweise darin, dass das Team um Jeff Heer eine „Visualisierungsgrammatik“ entwickelt hat, die eine Art Hochsprache ist, um relativ abstrakt eine Visualisierung zu definieren, die dann (unter anderem) mit D3.js umgesetzt wird. Dass sich eine solche Visualisierungsgrammatik entwickelt, liegt eben an der Eigenlogik der Denkkollektivs. Für p5.js wäre so etwas zu rigid, für Excel zu clever.
Wider den Denkstil
Um neue Wege zu finden, müssen Denkstile durchbrochen werden. Wenn Programmiersprachen Denkstile prägen und repräsentieren, ist die Entscheidung für eine Programmiersprache nicht primär eine technische Entscheidung, sondern hat weitreichende Folgen. Wählt man die dem Denkstil entsprechende Sprache wird man gut begangene, bewährte Pfade verfolgen, jedoch keine neuen Pfade finden.
Deswegen ist es gerade aus geisteswissenschaftlicher Sicht entscheidend, sich für die „Coding Cultures“ zu interessieren und sich der programmiertechnischen Prämissen bewusst zu sein, wenn ein bestimmtes Tool eingesetzt wird. Und vielleicht findet man neue Pfade, indem man eine neue Programmiersprache und damit auch eine neue kulturelle Praxis verwendet, um Daten zu verarbeiten.
Beim Experimentieren mit p5.js versuchte ich meine Twitter-Timeline zu visualisieren. Die Visualisierung ist zu unklar, um den Paradigmen der Informationsvisualisierung zu entsprechen. Aber vielleicht gehorcht sie eben eher einem anderen Denkstil, weil die p5.js-Coding-Culture dahinter steckt, nicht D3.js, R oder Excel:
Noah Bubenhofer: TweetViz – Visualisierung einer Twitter-Timeline (Klick für Originalanwendung)
Andres Wanner, Physiker, Kommunikationsdesigner, Künstler und Lehrer für digitales Design und Medienkunst (seine Berufsbezeichnung sprengt bereits verschiedene Denkkollektive), lässt die Arbeit eines Teilchenbeschleunigers auf eine Art visualisieren, wie sie die Physikerin nicht akzeptieren wird, die aber vielleicht gerade deswegen eine neue Erkenntnis bietet.
Andres Wanner: Hypothetical Beam I