Sapir-Whorf inverso e linguagens de programação

• Sapir-Whorf inverso foca não no que a linguagem torna difícil de pensar, mas no que ela torna difícil de deixar de dizer e em quais informações ela força a revelar
• O presente do inglês, pronomes de gênero, substantivos com gênero no francês e o passado mış do turco pressionam o falante a expressar informações como temporariedade, gênero, origem da informação ou grau de confiabilidade
• Em linguagens de programação, também é comum que se force o desenvolvedor a incluir no código temas pelos quais talvez ele nem se interesse, como ordem de cálculo, se algo é async, alocação e liberação de memória, escopo e tipos
• async em Python ou Javascript, gerenciamento de memória em C, lifetimes em Rust e anotações de tipo em linguagens estaticamente tipadas obrigam a explicitar escolhas, enquanto Haskell pode deixar parte delas para a linguagem com semântica não estrita e análise de estrita
• Linguagens de programação mais acessíveis podem ter uma barreira de Sapir-Whorf inverso mais baixa, com a característica de forçar menos o programador a falar sobre temas que ele ainda não entende ou sobre os quais ainda não tem opinião

---

O que significa Sapir-Whorf inverso

• A hipótese de Sapir-Whorf, simplificando, é a ideia de que a língua que usamos influencia o pensamento
• A forma forte de Sapir-Whorf, especialmente o determinismo linguístico, segundo o qual a língua controlaria o pensamento ou seria necessária uma língua específica para se ter certos pensamentos, hoje não é amplamente levada a sério na linguística
• O fato de uma língua não ter tempo gramatical não leva à conclusão de que seus falantes pensam de forma mais limitada sobre o tempo, pois sempre existem outras formas de expressá-lo
• Há bastante evidência de que a língua falada pode influenciar percepção, descrição e atitude em certas áreas, mas normalmente é difícil demonstrar um efeito direto grande
• Sapir-Whorf inverso foca não no que a linguagem torna difícil de dizer ou pensar, mas no que ela torna difícil de deixar de dizer
• Nessa perspectiva, o ponto central é como a linguagem empurra a pessoa a dizer certas informações ou torna difícil evitar certos pensamentos

A obrigatoriedade que aparece nas línguas naturais

• Temporariedade e permanência no presente do inglês

  • “I’m living in London” e “I live in London” significam que a pessoa mora em Londres, mas a primeira forma revela a informação de que esse estado é temporário
  • Quem não é nativo pode não perceber essa diferença, e até nativos podem assimilá-la apenas de forma inconsciente
  • O sentido de “temporário” pode ter mais relação com o quanto a pessoa gosta de Londres do que com o tempo real de moradia
  • Em inglês, é preciso escolher o tempo verbal e, como essa escolha costuma ser inconsciente, a língua acaba fazendo a pessoa revelar informações como duração da estadia ou sentimentos

• Pronomes e substantivos com gênero em inglês, turco e francês

  • Na fala cotidiana em inglês, ao se referir a uma pessoa específica, normalmente é preciso usar “he” ou “she”
  • “singular they” existe, mas ao falar de uma pessoa específica cujo gênero se conhece ou se supõe, isso não soa muito natural
  • O turco usa um único “o” para he/she/it, e a ausência desses pronomes de gênero não impede pensar ou falar sobre o gênero das pessoas
  • Nesse ponto, é difícil sustentar o Sapir-Whorf tradicional, mas fica claro o Sapir-Whorf inverso no fato de que os pronomes do inglês empurram a pessoa a declarar o gênero, queira ou não
  • Mesmo ao tentar falar anonimamente sobre alguém conhecido, usar sem querer “him” ou “her” pode revelar o gênero e facilitar a identificação
  • Em francês, substantivos têm gênero, e ao traduzir “my friend” é preciso escolher entre “mon ami” e “mon amie”, ou entre “mon copain” e “ma copine”, revelando assim informação extra
  • Os pronomes possessivos também são marcados por gênero em inglês e francês, mas his/her em inglês indica o gênero de quem possui, enquanto son/sa em francês indica o gênero do objeto possuído, revelando informações diferentes

• O passado “mış” do turco

  • Em turco, simplificando, há dois tempos principais para o passado: um passado geral parecido com o simple past do inglês e a forma “mış”
  • A forma “mış” tem várias funções e, ao falar de eventos passados, é usada quando a informação é ouvida de terceiros ou tem menor confiabilidade
  • À pergunta “Fred foi trabalhar na segunda-feira?”, se a pessoa viu diretamente, usa o passado comum “geldi”; se soube por outra fonte, usa “gelmiş”
  • Em inglês, dá para usar o passado simples sem especificar a origem da informação ou seu grau de confiabilidade, mas em turco, em certas situações, a língua força a incluir o nível de certeza ou se houve testemunho direto
  • Como a forma “mış” existe, o passado comum deixa de ser uma escolha neutra e pode soar artificial quando nenhuma das duas opções parece adequada
  • Como o sufixo “mış” muitas vezes aparece no fim da última palavra da frase em turco, pode surgir o hábito de terminar uma frase em inglês, perceber que não marcou “isso foi informação ouvida e não algo que vi diretamente” e então sentir vontade de acrescentar “mış” no final
  • Em inglês também é fácil expressar isso com palavras como “apparently”, mas o inglês não obriga a explicitar isso, enquanto o turco obriga bastante

• A obrigatoriedade da língua que nativos quase não percebem

  • Diferenças assim costumam ser difíceis de notar até que se aprenda outra língua ou se tente ensinar a própria a estrangeiros
  • Na maioria dos momentos em que se escolhe entre simple present e present continuous, a pessoa não pensa conscientemente no que essa escolha implica
  • Quando a língua força uma certa expressão, isso nem sempre aparece apenas como inclusão de algo; o significado também pode se fixar pela omissão
  • “I love cake” fala de bolo de forma geral, e “I love the cake” fala de um bolo específico
  • No primeiro caso, a ausência de “the” deixa claro que se trata de bolo em geral; se fosse um bolo específico, seria necessário usar uma marca como “the” ou “this”
  • Outras línguas podem não ter uma forma que corresponda diretamente a essa distinção

Sapir-Whorf inverso em linguagens de programação

• Em linguagens de programação, o Sapir-Whorf tradicional talvez se aplique um pouco mais
• Em linguagens como Python ou Haskell, é difícil falar sobre alocação de memória, embora não seja impossível
• As limitações de linguagens de programação costumam ser discutidas em termos daquilo que é difícil expressar nelas
• Sapir-Whorf does not apply to Programming Languages, de Hillel Wayne, trata desse tema com mais detalhes
• Pela perspectiva do Sapir-Whorf inverso, o ponto central é se a linguagem de programação força a falar até sobre temas pelos quais você realmente não se importa
• Essa obrigatoriedade fica mais visível quando se aprende várias linguagens e se ganha uma perspectiva de aprendiz de língua estrangeira

Principais exemplos em linguagens de programação

• Ordem de cálculo

  • A maioria das linguagens força a expressar a ordem em que os cálculos serão executados
  • x = some_func(y + 1, z + 2) em Python diz a ordem em que y + 1 é calculado primeiro, depois z + 2, e então os dois valores são passados como argumentos para some_func
  • Você pode não pensar conscientemente nessa ordem, mas em Python não há como expressar esse cálculo sem ao mesmo tempo especificá-la
  • A maioria das linguagens é parecida nesse aspecto, embora em algumas a ordem de avaliação fique bem complexa
  • Uma expressão equivalente em Haskell, como some_func (y + 1) (z + 2), não especifica ordem de avaliação alguma por causa da semântica não estrita
  • Essa característica permite técnicas como Tying the knot, que referenciam valores ainda não definidos

• A cor das funções async

  • A cor das funções async é um bom exemplo
  • Em linguagens com palavra-chave async explícita, como Javascript ou Python, é preciso dizer se o código é síncrono ou assíncrono
  • Em funções síncronas, isso aparece pela omissão da palavra-chave async, mas ainda assim é uma escolha entre duas opções
  • Não há como escrever código que permaneça ambivalente em relação a esse tema

• Alocação e liberação de memória

  • A maioria das linguagens sem garbage collection) força você a falar sobre alocação e liberação de memória
  • Em linguagens como C, isso normalmente é tratado de forma bastante explícita, ou então com alocação em stack implícita, mas de qualquer forma é preciso escolher
  • Em outras linguagens, esse problema pode ficar mais escondido, mas não desaparece
  • Em Rust, isso vira uma questão de lifetimes ou de contagem explícita de referências
  • A opção “não me importo com quando essa memória é alocada ou liberada, resolva isso para mim” simplesmente não é oferecida
  • Também existe custo em não falar sobre alocação de memória
  • Linguagens desse tipo quase certamente colocam muitos valores no heap e precisam de um coletor de lixo em tempo de execução
  • Em compensação, a linguagem ganha muita liberdade para escolher, e Haskell, por exemplo, muitas vezes faz essas escolhas com análise de estrita

• Escopo

  • Todas as linguagens modernas conhecidas fazem você pensar em escopo
  • Em muitos casos, o escopo é expresso pela posição física em que a variável é colocada, e, se quiser um comportamento diferente, é preciso usar sintaxe adicional, como global ou nonlocal em Python
  • Se você realmente não quiser pensar em escopo, talvez tenha de descer para assembly e aceitar um único espaço global de endereços

• Tipos

  • Linguagens estaticamente tipadas normalmente obrigam a pensar e falar sobre o tipo de todas as variáveis
  • Inferência de tipos reduz essa carga, como um ouvinte mais inteligente que entende mais coisas pelo contexto, mas a conversa continua existindo
  • Mesmo linguagens puramente dinâmicas permitem falar de tipos, como com verificações isinstance em Python, mas isso é mais artificial e tecnicamente diferente
  • Um dos atrativos das linguagens com tipagem gradual é justamente evitar, na prática, o problema do Sapir-Whorf inverso, dando liberdade para falar ou não sobre tipos conforme a preferência
  • Não está claro o quanto isso funciona bem na prática, e as convenções de codebases existentes e os linters usados sempre exercem pressão em alguma direção

Linguagens acessíveis e barreiras mais baixas

• Muitas características de linguagens de programação mais “acessíveis” ou “legíveis” podem ser analisadas pela lente do Sapir-Whorf inverso
• Essas linguagens podem ter uma barreira de Sapir-Whorf inverso mais baixa, com a característica de não forçar a falar sobre coisas sobre as quais você ainda não tem opinião ou que ainda não entende
• Os temas que uma linguagem de programação obriga a explicitar podem influenciar a percepção e a escolha da linguagem usada

[GN⁺]

Comentários do Lobste.rs

• O design de linguagem, seja de linguagem de programação ou natural, pode ser visto como decidir a que o usuário deve prestar atenção com base no que é colocado na linguagem
  C implicitamente diz “preste atenção no gerenciamento de memória”, e Haskell diz “preste atenção nos tipos que variáveis e expressões podem conter”
  Quando a linguagem me conduz na direção em que eu realmente quero focar, ela parece a ferramenta certa para aquele trabalho; quando não, é como tentar ouvir alguém falando baixo numa festa enquanto alguém grita do outro lado da sala
  Atenção é o recurso mais precioso, então precisamos estar conscientes de como as ferramentas a orientam e moldam

  • A ideia de que “a linguagem restringe aquilo que não se pode deixar de dizer” talvez pudesse receber um nome como não neutralidade da expressão
    Em inglês, explicitar ou omitir “the” não é neutro em relação à especificidade do objeto, e em turco usar ou não usar miş não é neutro quanto a saber se a informação foi obtida diretamente ou ouvida de outra pessoa
    Isso também pode ser visto como o oposto da hipótese Sapir-Whorf padrão, isto é, a neutralidade da expressão, que trata de “a linguagem restringe aquilo que se pode dizer”
    Assim, dá para explicar se uma linguagem é neutra ou não em relação a certos temas e, como designer de linguagem, ajustar isso para difundir ou concentrar a atenção do usuário. Por exemplo, coleta de lixo torna a expressão neutra em relação à alocação no heap, e rastreamento de efeitos torna a expressão não neutra em relação a efeitos colaterais e entrada/saída

• Não sei se entendi completamente o ponto central do texto, mas ele me lembrou de algo que penso há muito tempo sobre Rust
  Rust ocupa uma posição curiosa: permite lidar com referências, mas impõe regras rígidas para garantir segurança de memória
  Em C++, se você acha que algo deveria ser uma referência, simplesmente faz disso uma referência e torce para não dar problema; em Python, como você não tem esse nível de controle, copia os dados sem muita cerimônia
  Já em Rust, dá para cair no poço da otimização de pensar “copiar é ineficiente, então vamos usar referência”, e quando o borrow checker começa a gritar você passa uma hora refatorando o código mesmo tendo certeza de que aquela referência é segura
  Bons programadores Rust dizem “só usa .clone, RC, Box etc.”, e eu concordo, mas o fato de a referência estar bem na sua frente e parecer que daria para usá-la com segurança continua ali
  Então fica uma sensação estranha de que você decidiu piorar o código só para agradar o borrow checker, e dá para entender por que algumas pessoas acabam desistindo com a sensação de que “o borrow checker é demais para mim”

  • Isso toca bastante no que o texto queria abordar. Rust faz você pensar e decidir coisas que outras linguagens não exigem, e com isso tanto o peso quanto o poder de usar a linguagem aumentam

• O tema é bom, e foi legal ver um pouco de conversa sobre gramática turca
  Outro exemplo comum é que, em algumas línguas, certos detalhes como pluralidade podem ser omitidos, e o vietnamita é um desses casos
  Quando vi a palavra “exaggerated” com link, pensei “será que é um texto sobre Arrival?”, e realmente era, o que também foi divertido
  É um filme de que muita gente gosta, mas pessoalmente achei difícil suspender a descrença, porque apesar de se apresentar como ficção científica, essa “ciência” me pareceu uma espécie de linguística mágica

  • Acho que pluralidade é exatamente o ponto que coisas como APL, Pandas e SQL tentam cobrir
    A maioria das linguagens de programação para aplicações toma um único valor como uma espécie de base atômica. Dá para construir listas ou mapas em cima disso, mas eles também acabam sendo uma única coisa isolada e muitas vezes não são sutilmente compatíveis entre si
    Em Rust, copiar entre essas estruturas é frequente; em SQL, você se preocupa menos com isso, mas em troca precisa se preocupar com índices e planos de consulta, especialmente quando o banco de dados monta um plano obviamente idiota que torna complicado perguntar o que você quer saber, e nem vamos tocar em SQL NULL
    No fim, a maior parte do nosso software é exageradamente especificada até o nível dos valores individuais a ponto de ser difícil acreditar, e mesmo com PCs 1000 vezes mais rápidos, a melhor latência de UI ficou 10 vezes pior do que antes
    O dogmatismo da programação orientada a objetos também tem parte da culpa. Assíncrono também foi uma tentativa, mas degrada com facilidade para um estado em que se perde a visão do todo ao fazer await de tarefas independentes uma por uma
    https://www.uiua.org/ deve ser imaginado como algo feliz

• Bons pontos. Todas as linguagens modernas forçam ou induzem muito fortemente o programador a lidar com detalhes como se estivesse entrando num matagal
  Linguagens de script oferecem operações sobre alvos um pouco menos detalhados, como programas ou páginas web, mas ainda assim não conseguem eliminar os detalhes
  Você continua tendo de pensar e gerenciar minúcias como números, strings e códigos de erro
  Ficamos tão acostumados a gerenciar detalhes por anos de treino e trabalho prático que se tornou muito difícil pensar sem a perspectiva do detalhe

• A primeira coisa que me veio à cabeça foram as interfaces de objetos ou módulos
  Em linguagens de programação isso é muito concreto, mas em conversas em linguagem natural é bem mais nebuloso
  Outro exemplo é a diferença entre genéricos em C++ e em Python. Em C++, isso precisa ser tratado de forma muito intencional; em Python, se você ignorar as type hints, a coisa é tratada de maneira bem implícita

• A parte de “Sapir-Whorf inverso restringe aquilo que a linguagem não consegue deixar de dizer, ou torna difícil não dizer certas coisas, ou até torna difícil não pensar em certas coisas” parece uma pirâmide de gramática > idiomatismo > biblioteca padrão > bibliotecas de terceiros > ecossistema
  A parte de “difícil não pensar” parece focar em problemas difíceis de expressar ou com restrições importantes
  Familiaridade atua de cima e de baixo para dentro, e as pessoas revelam seu histórico pela forma como escrevem código em cada camada

• Leio, escrevo e falo inglês há mais de 15 anos e mesmo assim não sabia que “I live in London” e “I'm living in London” são diferentes
  Não sei se eu moro em London ou se estou morando em London 😅

  • “I'm living in London” ajuda um pouco se você expandir para “I am living in London”
    Se aqui você trocar a forma em gerúndio por um adjetivo comum e disser “I am cold”, entenderíamos que significa que você está com frio agora, não que seja permanentemente frio como algum supervilão
    Do mesmo modo, “I am living in London” sugere que você mora em London no momento, mas isso pode mudar no futuro
    Também carrega a nuance de que você nem sempre morou em London. É parecido com “I am cold”, que em certo grau implica que você ao menos já experimentou uma temperatura suficientemente quente para perceber que seu estado atual não é o “normal”, mas sim “frio”