Inverse Sapir-Whorf und Programmiersprachen

• Inverse Sapir-Whorf richtet den Fokus nicht darauf, was Sprache schwer denkbar macht, sondern darauf, worüber sie es schwer macht, nicht zu sprechen, und welche Informationen sie offenzulegen erzwingt
• Das englische Präsens, geschlechtsspezifische Pronomen im Englischen, geschlechtliche Substantive im Französischen und die türkische Vergangenheitsform mış drängen Sprecher dazu, Informationen wie Vorläufigkeit, Geschlecht sowie Quelle oder Verlässlichkeit von Informationen auszudrücken
• Auch in Programmiersprachen wird Entwicklerinnen und Entwicklern oft aufgezwungen, Themen in den Code aufzunehmen, die sie vielleicht gar nicht interessieren, etwa Reihenfolge der Berechnung, ob etwas async ist, Speicherallokation und -freigabe, Scope oder Typen
• async in Python oder Javascript, Speicherverwaltung in C, Lifetimes in Rust und Typannotationen in statisch typisierten Sprachen machen es nötig, bestimmte Entscheidungen explizit zu machen; Haskell kann mit nicht-strikter Semantik und Striktheitsanalyse einige Entscheidungen der Sprache überlassen
• Zugänglichere Programmiersprachen könnten eine niedrigere Inverse-Sapir-Whorf-Barriere haben und dadurch weniger dazu zwingen, über Themen zu sprechen, die man noch nicht verstanden hat oder zu denen man noch keine Meinung hat

---

Was Inverse Sapir-Whorf bedeutet

• Die Sapir-Whorf-Hypothese ist vereinfacht die Idee, dass die verwendete Sprache das Denken beeinflusst
• Die starke Form von Sapir-Whorf, insbesondere der sprachliche Determinismus, nach dem Sprache das Denken kontrolliert oder bestimmte Gedanken eine bestimmte Sprache voraussetzen, wird in der heutigen Linguistik nicht breit ernsthaft vertreten
• Aus der Tatsache, dass einer Sprache grammatische Tempora fehlen, folgt nicht, dass ihre Sprecher eingeschränkter über Zeit denken; es gibt immer andere Wege, Zeit auszudrücken
• Es gibt durchaus Hinweise darauf, dass gesprochene Sprache Wahrnehmung, Fertigkeiten und Einstellungen in bestimmten Bereichen beeinflussen kann, aber große direkte Effekte lassen sich meist nur schwer nachweisen
• Inverse Sapir-Whorf fragt nicht danach, was Sprache schwer sagbar oder denkbar macht, sondern danach, was sie schwer nicht sagbar macht
• Im Zentrum steht dabei, zu welchen Informationen Sprache einen drängt und welche Gedanken sich nur schwer vermeiden lassen

Erzwingung in natürlichen Sprachen

• Vorläufigkeit und Dauerhaftigkeit im englischen Präsens

  • „I’m living in London“ und „I live in London“ bedeuten beide, dass man in London wohnt, aber die erste Form legt zusätzlich offen, dass dieser Zustand vorläufig ist
  • Nicht-Muttersprachler bemerken diesen Unterschied womöglich nicht, und selbst Muttersprachler nehmen ihn oft nur unbewusst wahr
  • Die Bedeutung „vorläufig“ kann eher damit zusammenhängen, wie sehr jemand London mag, als mit der tatsächlichen Dauer des Aufenthalts
  • Im Englischen muss man ein Tempus wählen, und weil das meist unbewusst geschieht, bringt die Sprache einen dazu, Informationen etwa über Aufenthaltsdauer oder Gefühle preiszugeben

• Geschlechtsspezifische Pronomen und Substantive im Englischen, Türkischen und Französischen

  • Im alltäglichen Englisch muss man bei Bezug auf eine bestimmte Person normalerweise „he“ oder „she“ verwenden
  • „singular they“ existiert zwar, wirkt aber wenig natürlich, wenn man über eine konkrete Person spricht, deren Geschlecht man kennt oder vermutet
  • Im Türkischen gibt es mit „o“ nur ein Wort für he/she/it; das Fehlen solcher geschlechtsspezifischen Pronomen verhindert aber nicht, dass man über das Geschlecht einer Person nachdenken oder sprechen kann
  • Das stützt Sapir-Whorf im üblichen Sinn kaum, aber es zeigt deutlich Inverse Sapir-Whorf: Englische Pronomen drängen einen dazu, Geschlecht mitzuteilen, ob man will oder nicht
  • Selbst wenn man über eine bekannte Person anonym sprechen will, kann ein unbedachtes „him“ oder „her“ das Geschlecht verraten und die Identifizierung erleichtern
  • Im Französischen haben Substantive ein Genus; bei der Übersetzung von „my friend“ muss man sich etwa zwischen „mon ami“ und „mon amie“ oder zwischen „mon copain“ und „ma copine“ entscheiden und gibt dadurch Information preis
  • Possessivpronomen sind sowohl im Englischen als auch im Französischen geschlechtlich markiert, aber englisches his/her verrät das Geschlecht des Besitzers, französisches son/sa dagegen das Genus des Besessenen und legt damit andere Informationen offen

• Die türkische Vergangenheitsform „mış“

  • Im Türkischen gibt es stark vereinfacht zwei wichtige Vergangenheitsformen: eine allgemeine Vergangenheit ähnlich dem englischen simple past und die Form „mış“
  • Die Form „mış“ hat mehrere Funktionen; wenn man über vergangene Ereignisse spricht, wird sie verwendet, wenn Informationen vom Hörensagen stammen oder weniger verlässlich sind
  • Auf die Frage „Kam Fred am Montag zur Arbeit?“ würde man bei direkter Beobachtung die gewöhnliche Vergangenheitsform „geldi“ verwenden, bei gehörten Informationen dagegen „gelmiş“
  • Im Englischen kann man mit dem simple past sprechen, ohne Quelle oder Verlässlichkeit der Information festzulegen; im Türkischen wird man in bestimmten Situationen dagegen gezwungen, den Grad der Gewissheit oder direkte Zeugenschaft mit auszudrücken
  • Weil es die Form „mış“ gibt, ist die gewöhnliche Vergangenheitsform keine neutrale Wahl; wenn keine der beiden Optionen ganz passt, wirkt die Äußerung schnell unnatürlich
  • Da das Suffix „mış“ im Türkischen oft am Ende des letzten Wortes eines Satzes steht, kann sich sogar die Gewohnheit entwickeln, einen englischen Satz zu beenden, dann zu merken, dass man noch nicht markiert hat, dass die Information nur vom Hörensagen stammt und nicht direkt beobachtet wurde, und gedanklich am Ende ein „mış“ anzuhängen
  • Auch im Englischen lässt sich dasselbe leicht mit Wörtern wie „apparently“ ausdrücken, aber das Englische erzwingt diese Angabe nicht, das Türkische in erheblichem Maß schon

• Sprachliche Erzwingung, die Muttersprachler oft übersehen

  • Solche Unterschiede fallen oft erst auf, wenn man eine andere Sprache lernt oder die eigene Sprache Fremdsprachlern beibringt
  • In den meisten Situationen, in denen man zwischen simple present und present continuous wählt, denkt man nicht bewusst darüber nach, was diese Wahl impliziert
  • Wenn Sprache etwas erzwingt, geschieht das nicht immer nur dadurch, dass etwas hinzugefügt werden muss; auch durch Auslassung kann Bedeutung festgelegt werden
  • „I love cake“ bezieht sich auf Kuchen im Allgemeinen, „I love the cake“ auf einen bestimmten Kuchen
  • Im ersten Satz wird gerade durch das Fehlen von „the“ klar, dass Kuchen allgemein gemeint ist; wäre ein bestimmter Kuchen gemeint, müsste man „the“ oder einen Marker wie „this“ verwenden
  • In anderen Sprachen gibt es für diese Unterscheidung möglicherweise keine direkte Entsprechung

Inverse Sapir-Whorf in Programmiersprachen

• Bei Programmiersprachen könnte das gewöhnliche Sapir-Whorf eher zutreffen
• In Sprachen wie Python oder Haskell ist es schwierig, aber nicht unmöglich, über Speicherallokation zu sprechen
• Über die Grenzen von Programmiersprachen wird normalerweise in Bezug auf das gesprochen, was sich in ihnen nur schwer ausdrücken lässt
• Hillel Waynes Sapir-Whorf does not apply to Programming Languages behandelt dieses Thema ausführlicher
• Aus Inverse-Sapir-Whorf-Sicht ist entscheidend, ob eine Programmiersprache einen dazu zwingt, auch über Dinge zu sprechen, die einen eigentlich gar nicht interessieren
• Solche Zwänge werden oft erst sichtbar, wenn man mehrere Sprachen lernt und dadurch eine Art Fremdsprachenlernenden-Perspektive einnimmt

Wichtige Beispiele aus Programmiersprachen

• Reihenfolge der Berechnung

  • Die meisten Sprachen zwingen dazu, die Reihenfolge auszudrücken, in der Berechnungen ausgeführt werden
  • x = some_func(y + 1, z + 2) in Python sagt aus, dass zuerst y + 1, dann z + 2 berechnet und anschließend beide Werte als Argumente an some_func übergeben werden
  • Man muss sich dieser Reihenfolge nicht bewusst sein, aber in Python gibt es keine Möglichkeit, diese Berechnung auszudrücken, ohne gleichzeitig auch eine Reihenfolge festzulegen
  • Das gilt für die meisten Sprachen ähnlich, auch wenn die Auswertungsreihenfolge in manchen Sprachen sehr kompliziert wird
  • Ein äquivalenter Ausdruck wie some_func (y + 1) (z + 2) in Haskell legt wegen nicht-strikter Semantik überhaupt keine Auswertungsreihenfolge fest
  • Diese Eigenschaft ermöglicht Techniken wie Tying the knot, bei denen auf noch nicht definierte Werte Bezug genommen wird

• Die Farbe von async-Funktionen

  • Die Farbe von async-Funktionen ist ein gutes Beispiel
  • In Sprachen mit explizitem async-Keyword wie Javascript oder Python muss man sagen, ob Code synchron oder asynchron ist
  • In synchronen Funktionen geschieht das durch Weglassen des async-Keywords, aber man wählt trotzdem eine von zwei Optionen
  • Es gibt keine Möglichkeit, Code zu schreiben, der in dieser Frage bewusst offen bleibt

• Speicherallokation und -freigabe

  • Die meisten Sprachen ohne Garbage Collection) zwingen dazu, über Speicherallokation und -freigabe zu sprechen
  • In Sprachen wie C geschieht das meist recht explizit oder implizit über Stack-Allokation, aber in jedem Fall muss eine Wahl getroffen werden
  • In anderen Sprachen kann dieses Problem stärker verborgen sein, verschwinden tut es aber nicht
  • In Rust verwandelt sich die Frage eher in eine über Lifetimes oder explizites Reference Counting
  • Die Option „Es ist mir egal, wann dieser Speicher allokiert und freigegeben wird; kümmere dich bitte darum“ wird faktisch nicht angeboten
  • Auch das Nicht-Aussprechen von Speicherallokation hat seinen Preis
  • Solche Sprachen legen dann fast sicher viele Werte auf den Heap und benötigen einen Garbage Collector zur Laufzeit
  • Dafür gewinnt die Sprache erheblich mehr Freiheit bei der Wahl, und Haskell trifft solche Entscheidungen zum Beispiel oft mithilfe von Striktheitsanalyse

• Scope

  • Alle bekannten modernen Sprachen zwingen einen dazu, über Scope nachzudenken
  • In vielen Fällen wird Scope über die physische Platzierung von Variablen ausgedrückt; wenn man anderes Verhalten möchte, braucht man zusätzliche Syntax wie global oder nonlocal in Python
  • Wenn man über Scope überhaupt nicht nachdenken will, bleibt womöglich nur der Weg hinunter zu Assembler mit einem einzigen globalen Adressraum

• Typen

  • Statisch typisierte Sprachen zwingen einen normalerweise dazu, über den Typ jeder Variablen nachzudenken und zu sprechen
  • Type Inference reduziert diese Last, ähnlich wie ein intelligenterer Zuhörer aus dem Kontext mehr erschließt, aber das „Gespräch“ selbst findet weiterhin statt
  • Rein dynamisch typisierte Sprachen erlauben es ebenfalls, über Typen zu sprechen, etwa mit isinstance-Prüfungen in Python, aber das ist weniger natürlich und technisch auch etwas anderes
  • Einer der Reize von schrittweise typisierten Sprachen liegt darin, dass sie das Inverse-Sapir-Whorf-Problem tatsächlich vermeiden und je nach Präferenz die Freiheit geben, über Typen zu sprechen oder eben nicht
  • Wie gut das in der Praxis funktioniert, ist unklar; Konventionen in bestehenden Codebasen und verwendete Linter üben fast immer Druck in die eine oder andere Richtung aus

Zugänglichere Sprachen und niedrigere Hürden

• Viele Eigenschaften „zugänglicherer“ oder „leichter lesbarer“ Programmiersprachen lassen sich aus einer Inverse-Sapir-Whorf-Perspektive analysieren
• Solche Sprachen könnten eine niedrigere Inverse-Sapir-Whorf-Barriere haben und dadurch weniger dazu zwingen, über Dinge zu sprechen, zu denen man noch keine Position hat oder die man noch nicht versteht
• Welche Themen eine Programmiersprache erzwingt, kann die Wahrnehmung dieser Sprache und die Entscheidung für oder gegen sie beeinflussen

[GN⁺]

Lobste.rs-Kommentare

• Sprachdesign – ob bei Programmiersprachen oder natürlichen Sprachen – kann man so verstehen, dass es durch die Elemente, die in eine Sprache aufgenommen werden, festlegt, worauf Nutzer ihre Aufmerksamkeit richten sollen
  C sagt implizit: „Achte auf Speicherverwaltung“, und Haskell sagt: „Achte auf die Typen, die Variablen und Ausdrücke annehmen können“
  Wenn eine Sprache mich in die Richtung lenkt, auf die ich meine Aufmerksamkeit tatsächlich richten will, fühlt sie sich wie ein gut passendes Werkzeug an; wenn nicht, ist es, als würde ich auf einer Cocktailparty versuchen, jemandem zuzuhören, der leise spricht, während quer durch den Raum jemand schreit
  Aufmerksamkeit ist die kostbarste Ressource, daher sollte man sich bewusst machen, wie Werkzeuge sie lenken und formen

  • Der Idee, dass „eine Sprache einschränkt, was nicht gesagt werden kann“, könnte man einen Namen wie Nichtneutralität des Ausdrucks geben
    Im Englischen sind Formulierungen mit oder ohne „the“ nicht neutral gegenüber der Bestimmtheit eines Gegenstands, und im Türkischen ist die Verwendung oder Nichtverwendung von miş nicht neutral gegenüber der Frage, ob eine Information direkt erlangt oder nur vom Hörensagen stammt
    Das kann man als Gegenstück zur klassischen Sapir-Whorf-Hypothese sehen, also dazu, dass „eine Sprache einschränkt, was gesagt werden kann“, nämlich als Neutralität des Ausdrucks
    So ließe sich erklären, ob eine Sprache bei bestimmten Themen neutral ist oder nicht, und als Sprachdesigner kann man steuern, ob die Aufmerksamkeit der Nutzer eher zerstreut oder gebündelt wird. Garbage Collection macht den Ausdruck in Bezug auf Heap-Allokation neutral, während Effect Tracking den Ausdruck in Bezug auf Nebenwirkungen und Ein-/Ausgabe nichtneutral macht

• Ich weiß nicht, ob ich den Kern des Artikels vollständig erfasst habe, aber er erinnert mich an einen Gedanken, den ich zu Rust schon lange immer wieder habe
  Rust nimmt eine merkwürdige Position ein: Es erlaubt den Umgang mit Referenzen, stellt aber strenge Regeln auf, um Speichersicherheit zu garantieren
  In C++ macht man etwas einfach zu einer Referenz, wenn man denkt, dass es eine sein sollte, und hofft, dass es gutgeht; in Python hat man diese Kontrolle nicht, also kopiert man Daten ohne große Hemmungen
  In Rust kann man jedoch in eine Optimierungsgrube geraten: „Kopieren ist ineffizient, also machen wir eine Referenz daraus“, und wenn dann der Borrow Checker schreit, refaktoriert man eine Stunde lang Code, obwohl man sicher ist, dass diese Referenz ungefährlich ist
  Gute Rust-Programmierer sagen dann: „Nimm einfach .clone, RC, Box usw.“, und ich stimme zu, aber die Tatsache bleibt, dass die Referenz vor einem liegt und sicher benutzbar zu sein scheint
  Daher bleibt dieses merkwürdige Gefühl zurück, den Code absichtlich verschlechtert zu haben, nur um den Borrow Checker zu besänftigen, und ich kann verstehen, warum manche irgendwann aufgeben und sagen: „Der Borrow Checker ist mir einfach zu viel“

  • Das berührt ziemlich genau das, worum es im Artikel geht. Rust zwingt einen dazu, Entscheidungen zu durchdenken und zu treffen, die andere Sprachen nicht verlangen, und dadurch wachsen sowohl die Last als auch die Stärke, die mit der Sprache einhergehen

• Interessantes Thema, und ich fand es auch schön, dass türkische Grammatik kurz vorkam
  Ein weiteres gängiges Beispiel ist, dass man in manchen Sprachen Details wie Pluralität weglassen kann; Vietnamesisch ist so ein Fall
  Als ich sah, dass das Wort „exaggerated“ verlinkt war, dachte ich: „Ist das vielleicht ein Artikel über Arrival?“, und genau das war es, was mich zusätzlich erfreut hat
  Viele mögen den Film sehr, aber ich persönlich konnte meine Skepsis nur schwer aussetzen. Es soll Science-Fiction sein, aber diese „Science“ wirkte auf mich eher wie eine Art magische Linguistik

  • Pluralität ist aus meiner Sicht genau der Punkt, den Dinge wie APL, Pandas und SQL zu überdecken versuchen
    Die meisten Programmiersprachen für Anwendungsentwicklung behandeln Einzelwerte als eine Art atomare Grundlage. Darauf kann man Listen oder Maps bauen, aber auch diese sind letztlich jeweils ein einzelnes Ding und oft auf subtile Weise nicht vollständig miteinander kompatibel
    In Rust kopiert man ständig zwischen solchen Strukturen hin und her; in SQL muss man sich darum weniger kümmern, dafür aber um Indizes und Query-Pläne – besonders wenn die Datenbank einen offensichtlich dummen Plan erstellt, der komplizierter macht, was ich eigentlich fragen will, und von SQL NULL wollen wir gar nicht erst anfangen
    Im Ergebnis ist der Großteil unserer Software bis hinunter auf die Ebene einzelner Werte unglaublich überbestimmt, und obwohl PCs 1000-mal leistungsfähiger geworden sind, ist die beste UI-Latenz heute zehnmal schlechter als früher
    Auch der Dogmatismus der objektorientierten Programmierung trägt teilweise Schuld. Mit Asynchronität haben wir es ebenfalls versucht, aber sie degeneriert viel zu leicht dazu, unabhängige Aufgaben einzeln zu awaiten und dabei vor lauter Bäumen den Wald nicht mehr zu sehen
    Man muss sich vorstellen, dass https://www.uiua.org/ glücklich ist

• Gute Punkte. Alle modernen Sprachen zwingen Programmierer dazu oder drängen sie sehr stark dazu, sich mit Details zu beschäftigen, als würden sie in ein Unkrautfeld hineingehen
  Skriptsprachen bieten Operationen auf etwas weniger detailreichen Objekten wie Programmen oder Webseiten, aber auch sie können die Details nicht verschwinden lassen
  Man muss sich immer noch mit sehr kleinen Einzelheiten wie Zahlen, Strings und Fehlercodes befassen und sie verwalten
  Durch jahrelanges Training und Berufspraxis sind wir so sehr an Detailverwaltung gewöhnt, dass es äußerst schwer geworden ist, nicht aus der Perspektive von Details zu denken

• Das Erste, woran ich denken musste, war die Schnittstelle von Objekten oder Modulen
  In Programmiersprachen ist das sehr konkret, in natürlicher Konversation viel verschwommener
  Ein weiteres Beispiel ist der Unterschied zwischen Generics in C++ und in Python. In C++ muss man sehr bewusst damit umgehen, während sie in Python recht implizit behandelt werden, wenn man Typ-Hinweise ignoriert

• Der Satz „Inverse Sapir-Whorf beschränkt, was eine Sprache nicht sagen kann, macht es schwierig, bestimmte Dinge nicht zu sagen, oder macht es sogar schwierig, bestimmte Dinge nicht zu denken“ wirkt auf mich wie eine Pyramide aus Syntax > Idiomen > Standardbibliothek > Drittanbieter-Bibliotheken > Ökosystem
  Der Teil mit „schwierig, nicht zu denken“ scheint den Fokus auf Probleme zu legen, die schwer auszudrücken sind oder wichtige Einschränkungen haben
  Vertrautheit wirkt von oben und unten nach innen, und Menschen verraten ihren Hintergrund dadurch, wie sie auf jeder dieser Ebenen Code schreiben

• Ich lese, schreibe und spreche seit über 15 Jahren Englisch und wusste trotzdem nicht, dass „I live in London“ und „I'm living in London“ unterschiedlich sind
  Ich weiß also nicht einmal, ob ich in London wohne oder gerade in London wohne 😅

  • Es hilft vielleicht ein wenig, wenn man „I'm living in London“ zu „I am living in London“ ausformuliert
    Wenn man das Gerundium hier durch ein gewöhnliches Adjektiv ersetzt und „I am cold“ sagt, versteht man das als „Mir ist jetzt kalt“ und nicht so, als wäre ich wie irgendein Superschurke dauerhaft kalt
    Genauso impliziert „I am living in London“, dass ich derzeit in London lebe, sich das in Zukunft aber ändern kann
    Außerdem schwingt mit, dass ich nicht schon immer in London gelebt habe. Das ist ein bisschen so, wie „I am cold“ mitschwingen lässt, dass ich zumindest einmal eine ausreichend warme Temperatur erlebt habe, um meinen jetzigen Zustand nicht als „normal“, sondern als „kalt“ wahrzunehmen