Le Sapir-Whorf inversé et les langages de programmation

• Le Sapir-Whorf inversé ne s’intéresse pas à ce qu’une langue rend difficile à penser, mais à ce qu’elle rend difficile à ne pas dire et aux informations qu’elle oblige à révéler
• Le présent en anglais, les pronoms genrés, les noms genrés en français et le passé turc en mış poussent les locuteurs à exprimer des informations comme le caractère temporaire, le genre, ou encore la source et la fiabilité de l’information
• Dans les langages de programmation aussi, il faut souvent inclure dans le code des sujets qui peuvent ne pas intéresser le développeur, comme l’ordre de calcul, le caractère async ou non, l’allocation et la libération mémoire, la portée ou les types
• Le async de Python ou Javascript, la gestion mémoire en C, les durées de vie (lifetimes) en Rust et les annotations de type dans les langages à typage statique obligent à expliciter certains choix, tandis que Haskell peut laisser certains choix au langage grâce à sa sémantique non stricte et à l’analyse de strictness
• Un langage de programmation plus accessible peut avoir une barrière de Sapir-Whorf inversé plus basse, en forçant moins à parler de sujets que l’on ne comprend pas encore ou sur lesquels on n’a pas d’avis

---

Ce que signifie le Sapir-Whorf inversé

• L’hypothèse de Sapir-Whorf, en simplifiant, est l’idée que la langue que l’on utilise influence la pensée
• La forme forte de Sapir-Whorf, en particulier le déterminisme linguistique selon lequel la langue contrôlerait la pensée ou qu’il faudrait une langue donnée pour avoir certaines pensées, n’est aujourd’hui pas largement prise au sérieux en linguistique
• Le fait qu’une langue n’ait pas de temps grammaticaux n’implique pas que ses locuteurs pensent le temps de manière plus limitée, car il existe toujours d’autres façons de l’exprimer
• Il existe pas mal d’éléments montrant que la langue parlée peut influencer la perception, les compétences et les attitudes dans certains domaines, mais démontrer de grands effets directs reste généralement difficile
• Le Sapir-Whorf inversé ne s’intéresse pas à ce qu’une langue rend difficile à dire ou à penser, mais à ce qu’elle rend difficile à ne pas dire
• Dans cette perspective, l’essentiel est de savoir quelles informations une langue pousse à exprimer et quelles pensées elle rend difficiles à éviter

Les contraintes visibles dans les langues naturelles

• Le caractère temporaire et durable du présent en anglais

  • “I’m living in London” et “I live in London” veulent tous deux dire qu’on habite à Londres, mais la première formulation révèle que cette situation est temporaire
  • Un non-natif peut ne pas remarquer cette différence, et même un natif peut ne l’intégrer que de façon inconsciente
  • Le sens de « temporaire » peut en réalité être davantage lié au fait d’aimer ou non Londres qu’à la durée réelle du séjour
  • En anglais, il faut choisir un temps, et comme ce choix se fait souvent inconsciemment, la langue amène à révéler des informations comme la durée du séjour ou le ressenti

• Les pronoms et noms genrés en anglais, en turc et en français

  • Dans l’usage courant de l’anglais, lorsqu’on désigne une personne précise, il faut généralement utiliser “he” ou “she”
  • Le “singular they” existe, mais il reste peu naturel lorsqu’on parle d’une personne précise dont on connaît ou suppose le genre
  • Le turc utilise un seul terme, “o”, pour he/she/it, et cette absence de pronom genré n’empêche pas de penser ou de parler du genre des personnes
  • Il est donc difficile d’y voir un argument fort pour le Sapir-Whorf classique, mais les pronoms anglais illustrent clairement le Sapir-Whorf inversé en ce qu’ils poussent à exprimer le genre, qu’on le veuille ou non
  • Même lorsqu’on essaie de parler anonymement de quelqu’un que l’on connaît, employer machinalement “him” ou “her” peut révéler son genre et faciliter son identification
  • En français, les noms ont un genre, et pour traduire “my friend”, il faut choisir entre “mon ami” et “mon amie”, ou entre “mon copain” et “ma copine”, ce qui oblige à révéler une information
  • Les adjectifs possessifs sont genrés en anglais comme en français, mais le his/her anglais renseigne sur le genre du possesseur, tandis que le son/sa français renseigne sur le genre de l’objet possédé, ce qui fait apparaître des informations différentes

• Le passé turc en “mış”

  • En simplifiant, le turc possède deux grands temps du passé : un passé général proche du prétérit anglais, et la forme en “mış”
  • La forme en “mış” a plusieurs fonctions et, lorsqu’on parle d’un événement passé, elle s’emploie quand l’information est rapportée ou jugée moins fiable
  • À la question « Fred est-il allé travailler lundi ? », on utilisera le passé ordinaire “geldi” si on l’a vu directement, et “gelmiş” s’il s’agit d’une information entendue
  • En anglais, on peut raconter un fait au passé simple sans préciser la source ni le degré de fiabilité de l’information, alors qu’en turc certaines situations obligent à inclure ce niveau de certitude ou l’absence d’observation directe
  • Puisque la forme en “mış” existe, le passé ordinaire n’est pas un choix neutre, et il devient peu naturel quand aucune des deux formes n’est vraiment adaptée
  • Comme le suffixe “mış” arrive souvent à la fin du dernier mot de la phrase en turc, on peut prendre l’habitude de finir une phrase en anglais puis de réaliser qu’on n’a pas indiqué « ceci est rapporté et je ne l’ai pas vu moi-même », avant d’ajouter mentalement un “mış” à la fin
  • L’anglais peut facilement exprimer la même chose avec un mot comme “apparently”, mais il ne force pas à le faire, alors que le turc le fait assez fortement

• Les contraintes linguistiques que les natifs perçoivent mal

  • Ces différences sont souvent difficiles à remarquer tant qu’on n’apprend pas une autre langue ou qu’on n’essaie pas d’enseigner sa propre langue à des étrangers
  • La plupart du temps, lorsqu’on choisit entre le présent simple et le présent continu, on ne réfléchit pas consciemment à ce que ce choix implique
  • Quand une langue impose une forme d’expression, cela ne se manifeste pas toujours uniquement par l’ajout d’un élément ; le sens peut aussi être fixé par omission
  • “I love cake” parle du gâteau en général, tandis que “I love the cake” parle d’un gâteau en particulier
  • Dans la première phrase, l’absence de “the” indique clairement qu’il s’agit des gâteaux en général ; pour parler d’un gâteau spécifique, il faut obligatoirement employer un marqueur comme “the” ou “this”
  • D’autres langues peuvent ne pas avoir d’expression correspondant directement à cette distinction

Le Sapir-Whorf inversé dans les langages de programmation

• Dans les langages de programmation, le Sapir-Whorf classique peut aussi être plus pertinent
• Dans des langages comme Python ou Haskell, il est difficile de parler d’allocation mémoire, mais ce n’est pas impossible
• On parle généralement des limites d’un langage de programmation en termes de ce qu’il permet ou non d’exprimer facilement
• Sapir-Whorf does not apply to Programming Languages de Hillel Wayne traite plus en détail de ce sujet
• Du point de vue du Sapir-Whorf inversé, la vraie question est de savoir si le langage oblige à parler de sujets qui n’intéressent pas réellement le développeur
• Ce type de contrainte est plus facile à voir lorsqu’on apprend plusieurs langages et que l’on adopte une perspective d’apprenant en langue étrangère

Principaux exemples dans les langages de programmation

• Ordre de calcul

  • La plupart des langages obligent à exprimer l’ordre dans lequel les calculs sont effectués
  • En Python, x = some_func(y + 1, z + 2) exprime l’ordre suivant : calculer d’abord y + 1, puis z + 2, puis passer les deux valeurs comme arguments à some_func
  • On peut ne pas y penser consciemment, mais en Python il n’existe pas de manière d’exprimer ce calcul sans spécifier en même temps cet ordre
  • C’est similaire dans la plupart des langages, mais dans certains l’ordre d’évaluation devient très complexe
  • Une expression équivalente en Haskell, comme some_func (y + 1) (z + 2), ne précise aucun ordre d’évaluation grâce à la sémantique non stricte
  • Cette propriété permet des techniques comme Tying the knot, où l’on référence des valeurs qui ne sont pas encore définies

• La couleur async des fonctions

  • La couleur async des fonctions en est un bon exemple
  • Dans des langages comme Javascript ou Python, qui ont un mot-clé async explicite, il faut dire si le code est synchrone ou asynchrone
  • Dans une fonction synchrone, on l’exprime en omettant le mot-clé async, mais cela reste malgré tout un choix entre deux possibilités
  • Il n’existe pas de façon d’écrire un code neutre ou ambivalent sur ce point

• Allocation et libération mémoire

  • La plupart des langages sans ramasse-miettes) obligent à parler de l’allocation et de la libération mémoire
  • Dans un langage comme C, on le gère en général de manière assez explicite, ou bien on utilise implicitement l’allocation sur la pile ; dans les deux cas, il faut choisir
  • Dans d’autres langages, le problème peut être davantage masqué, mais il ne disparaît pas
  • En Rust, le sujet se transforme en discussion sur les durées de vie (lifetimes) ou sur le comptage de références explicite
  • L’option consistant à dire « je ne me soucie pas du moment où cette mémoire est allouée et libérée, gérez cela pour moi » n’est en pratique pas disponible
  • Ne pas parler de l’allocation mémoire a aussi un coût
  • De tels langages placent presque certainement beaucoup de valeurs sur le tas et nécessitent un ramasse-miettes à l’exécution
  • En contrepartie, le langage dispose d’une grande liberté de choix, et Haskell prend souvent ce type de décision, par exemple via l’analyse de strictness

• Portée

  • Tous les langages modernes connus obligent à réfléchir à la portée
  • Souvent, la portée est exprimée par l’emplacement physique des variables, et si l’on veut un autre comportement, il faut utiliser une syntaxe supplémentaire comme global ou nonlocal en Python
  • Si l’on ne veut vraiment pas penser à la portée, il faut probablement descendre jusqu’à l’assembleur et accepter un espace d’adressage global unique

• Types

  • Les langages à typage statique obligent généralement à penser et à parler du type de chaque variable
  • L’inférence de types allège cette contrainte, un peu comme un interlocuteur plus intelligent qui comprend davantage de choses à partir du contexte, mais la conversation existe toujours
  • Les langages purement dynamiques permettent aussi de parler des types, par exemple avec des vérifications isinstance en Python, mais cela reste plus artificiel et techniquement différent
  • L’un des attraits du typage progressif est précisément d’éviter en pratique ce problème de Sapir-Whorf inversé, en laissant la liberté de parler ou non des types selon les préférences
  • On ne sait pas clairement à quel point cela fonctionne bien dans la réalité, car les conventions du code existant et les linters exercent presque toujours une pression dans un sens ou dans l’autre

Langages accessibles et barrière basse

• Beaucoup des caractéristiques des langages de programmation jugés plus « accessibles » ou « faciles à lire » peuvent être analysées sous l’angle du Sapir-Whorf inversé
• Ces langages peuvent avoir une barrière de Sapir-Whorf inversé plus basse, en n’obligeant pas à parler de choses sur lesquelles on n’a pas encore d’avis ou que l’on ne comprend pas encore
• Les sujets qu’un langage de programmation impose influencent la manière dont on perçoit ce langage et le choix que l’on en fait

[GN⁺]

Avis sur Lobste.rs

• On peut voir la conception d’un langage, qu’il s’agisse d’un langage de programmation ou d’une langue naturelle, comme le fait de décider à quoi l’utilisateur doit prêter attention selon les éléments que l’on y met
  Le C dit implicitement « fais attention à la gestion mémoire », et Haskell dit « fais attention aux types que peuvent contenir les variables et les expressions »
  Quand un langage m’oriente vers ce à quoi je veux réellement faire attention, il ressemble à un outil bien adapté à la tâche ; sinon, c’est comme essayer d’entendre quelqu’un qui parle doucement dans une soirée cocktail pendant que quelqu’un hurle de l’autre côté de la pièce
  L’attention est la ressource la plus précieuse ; il faut donc être conscient de la manière dont les outils la guident et la façonnent

  • On pourrait donner à l’idée selon laquelle « un langage contraint ce qu’il est difficile de ne pas dire » un nom comme la non-neutralité de l’expression
    En anglais, le fait d’expliciter ou d’omettre « the » n’est pas neutre quant au caractère spécifique de l’objet, et en turc, utiliser ou non miş n’est pas neutre quant au fait que l’information provienne d’une expérience directe ou d’un ouï-dire
    On peut y voir l’opposé de l’hypothèse de Sapir-Whorf standard, selon laquelle « un langage contraint ce qu’il est possible de dire », c’est-à-dire la neutralité de l’expression
    On peut alors expliquer si un langage est neutre ou non sur un sujet donné, et, en tant que concepteur de langage, ajuster cela pour diffuser ou concentrer l’attention de l’utilisateur. Par exemple, le garbage collection rend l’expression neutre vis-à-vis de l’allocation sur le tas, tandis que le suivi des effets rend l’expression non neutre vis-à-vis des effets de bord et des entrées/sorties

• Je ne suis pas sûr d’avoir complètement saisi le cœur du texte, mais cela m’a rappelé une réflexion que je me fais depuis longtemps à propos de Rust
  Rust se trouve dans une position étrange : il permet de manipuler des références tout en imposant des règles strictes pour garantir la sécurité mémoire
  En C++, si l’on pense que quelque chose devrait être une référence, on en fait simplement une référence en espérant que tout ira bien ; en Python, on n’a pas ce niveau de contrôle, donc on copie volontiers les données
  Mais en Rust, on peut tomber dans un piège d’optimisation du type « copier est inefficace, donc faisons-en une référence », puis, quand le borrow checker se met à hurler, on passe une heure à refactorer le code tout en restant convaincu que cette référence est sûre
  Les bons programmeurs Rust disent « utilise simplement .clone, RC, Box, etc. », et je suis d’accord, mais le fait demeure que la référence est juste là devant soi et semble pouvoir être utilisée sans danger
  Il reste donc cette étrange impression d’avoir empiré les choses uniquement pour apaiser le borrow checker, et je comprends pourquoi certaines personnes finissent par abandonner en se disant « le borrow checker, c’est trop pour moi »

  • Cela rejoint assez bien ce que le texte voulait dire. Rust oblige à réfléchir et à décider de choses que d’autres langages n’exigent pas, ce qui augmente à la fois la charge et la puissance du langage

• Le sujet est bon, et j’étais aussi content de voir un peu de grammaire turque apparaître
  Un autre exemple courant est que, dans certaines langues, on peut omettre des détails comme la pluralité, et c’est le cas du vietnamien
  En voyant le mot « exaggerated » lié, je me suis dit « tiens, est-ce que c’est un article sur Arrival ? », et c’était effectivement le cas, ce qui m’a amusé
  C’est un film que beaucoup aiment, mais personnellement j’ai eu du mal à suspendre mon incrédulité : on nous le présente comme de la science-fiction, mais la « science » m’y a semblé relever d’une sorte de linguistique magique

  • La pluralité est, à mon avis, précisément le point que des choses comme APL, Pandas ou SQL essaient de recouvrir
    La plupart des langages de programmation applicative prennent une valeur unique comme base atomique. On peut construire par-dessus des listes ou des maps, mais celles-ci restent au fond des objets unitaires et sont souvent subtilement incompatibles entre elles
    En Rust, on passe souvent son temps à copier entre ces structures ; en SQL, on se soucie moins de ce problème, mais il faut alors se préoccuper des index et des plans de requête, surtout quand la base de données élabore un plan manifestement idiot qui complique ce que l’on voulait demander, et ne parlons même pas de SQL NULL
    Au final, la majeure partie de notre logiciel est spécifiée de façon incroyablement excessive jusqu’au niveau de la valeur individuelle, et alors que la puissance des PC a été multipliée par 1000, la meilleure latence d’interface est devenue 10 fois pire qu’avant
    Le dogmatisme de la programmation orientée objet porte aussi une part de responsabilité. On a aussi essayé l’asynchrone, mais cela dégénère trop facilement en une vision qui ne voit plus que l’arbre en awaitant les tâches indépendantes une par une
    Il faut imaginer que https://www.uiua.org/ est heureux

• Ce sont de bons points. Tous les langages modernes forcent le programmeur, ou l’y incitent très fortement, à traiter les détails comme s’il entrait dans un champ de mauvaises herbes
  Les langages de script fournissent des opérations sur des objets un peu moins détaillés, comme des programmes ou des pages web, mais ils ne parviennent toujours pas à faire disparaître les détails
  Ils nous obligent encore à penser et à gérer de tout petits détails comme les nombres, les chaînes de caractères ou les codes d’erreur
  Après des années de formation et de pratique, nous sommes devenus si habitués à gérer les détails qu’il devient très difficile de ne pas penser en termes de détails

• La première chose qui m’est venue à l’esprit, c’était l’interface des objets ou des modules
  En programmation, c’est quelque chose de très concret, alors que dans une conversation en langue naturelle c’est beaucoup plus flou
  Un autre exemple est la différence entre les génériques en C++ et les génériques en Python. En C++, il faut les traiter de manière très intentionnelle, alors qu’en Python, si l’on ignore les indications de type, cela reste assez implicite

• L’idée que « l’inverse de Sapir-Whorf limite ce qu’un langage ne peut pas ne pas dire, ou rend certaines choses difficiles à ne pas dire, voire difficiles à ne pas penser » ressemble à une pyramide syntaxe > idiomes > bibliothèque standard > bibliothèques tierces > écosystème
  La partie « difficile à ne pas penser » semble mettre l’accent sur les problèmes difficiles à exprimer ou soumis à des contraintes importantes
  La familiarité agit d’en haut et d’en bas vers l’intérieur, et les gens révèlent leur parcours par leur manière d’écrire du code à chaque couche

• Cela fait plus de 15 ans que je lis, écris et parle anglais, et pourtant je ne savais pas qu’il y avait une différence entre « I live in London » et « I'm living in London »
  Je ne sais même pas si j’habite à London, ou si je suis en train d’y vivre en ce moment 😅

  • Reformuler « I'm living in London » en « I am living in London » aide un peu
    Si l’on remplace ici la forme en gérondif par un adjectif ordinaire, comme dans « I am cold », on comprendrait que cela signifie que j’ai froid maintenant, pas que je suis froid de manière permanente comme un super-vilain
    De la même manière, « I am living in London » implique que je vis actuellement à London, mais que cela peut changer à l’avenir
    Cela suggère aussi qu’on n’a pas toujours vécu à London. C’est un peu comme si « I am cold » contenait l’idée qu’on a au moins une fois connu une température suffisamment chaude pour percevoir l’état actuel non comme « normal », mais comme « froid »