Sapir-Whorf inverso y lenguajes de programación

• Sapir-Whorf inverso se enfoca no en qué nos dificulta pensar un idioma, sino en qué nos dificulta no decir y qué información nos obliga a revelar
• En inglés, el presente, los pronombres de género, los sustantivos con género en francés y el pasado mış del turco empujan al hablante a expresar información como temporalidad, género, fuente de la información o nivel de confiabilidad
• En los lenguajes de programación, también es común que se obligue a los desarrolladores a incluir en el código temas que quizá no les interesen, como el orden de evaluación, si algo es async, la asignación y liberación de memoria, el alcance o scope, y los tipos
• async en Python o Javascript, la gestión de memoria en C, los lifetimes en Rust y las anotaciones de tipo en lenguajes estáticos obligan a hacer explícitas ciertas decisiones, mientras que Haskell puede delegar algunas de ellas al lenguaje gracias a su semántica no estricta y al análisis de strictness
• Un lenguaje de programación más accesible puede tener una barrera de Sapir-Whorf inverso más baja, es decir, forzar menos a hablar sobre temas que uno todavía no entiende o sobre los que aún no tiene una postura

---

Qué significa Sapir-Whorf inverso

• La hipótesis de Sapir-Whorf, simplificada, es la idea de que el idioma que usamos influye en nuestra forma de pensar
• La versión fuerte de Sapir-Whorf, especialmente el determinismo lingüístico, según el cual el lenguaje controla el pensamiento o se necesitaría un idioma específico para poder tener ciertas ideas, hoy en día no suele ser tomada muy en serio en lingüística
• Que una lengua no tenga tiempo gramatical no implica que sus hablantes piensen de forma más limitada sobre el tiempo; siempre hay otras maneras de expresarlo
• Sí hay bastante evidencia de que la lengua hablada puede influir en la percepción, la descripción o las actitudes en ciertos ámbitos, pero normalmente es difícil demostrar efectos grandes y directos
• Sapir-Whorf inverso no se enfoca en lo que el lenguaje vuelve difícil de decir o pensar, sino en lo que vuelve difícil no decir
• Desde esta perspectiva, lo importante es qué información el lenguaje nos empuja a expresar o qué ideas hace difícil evitar

La obligatoriedad que aparece en las lenguas naturales

• Temporalidad y permanencia en el presente del inglés

  • “I’m living in London” y “I live in London” significan ambas que la persona vive en Londres, pero la primera revela que esa situación es temporal
  • Quienes no son hablantes nativos quizá no noten esa diferencia, y los nativos también pueden internalizarla de forma inconsciente
  • El matiz de “temporal” puede estar más relacionado con cuánto le gusta Londres a la persona que con el tiempo real que lleva viviendo ahí
  • En inglés hay que elegir un tiempo verbal, y como esa elección suele hacerse inconscientemente, el idioma termina revelando información como la duración de la residencia o incluso cierta actitud emocional

• Pronombres y sustantivos con género en inglés, turco y francés

  • En el habla cotidiana del inglés, al referirse a una persona concreta normalmente hay que usar “he” o “she”
  • Existe el “singular they”, pero no suena del todo natural cuando se habla de una persona específica cuyo género se conoce o se supone
  • El turco usa una sola palabra, “o”, para he/she/it, y la ausencia de esos pronombres con género no impide pensar o hablar sobre el género de alguien
  • Esto no sirve mucho para defender el Sapir-Whorf tradicional, pero sí muestra claramente el Sapir-Whorf inverso: los pronombres del inglés empujan a decir el género se quiera o no
  • Incluso al intentar hablar de forma anónima sobre alguien conocido, usar sin pensar “him” o “her” puede revelar el género y volver más fácil identificar a la persona
  • En francés, los sustantivos tienen género, así que para traducir “my friend” hay que escoger entre “mon ami” y “mon amie”, o entre “mon copain” y “ma copine”, lo que obliga a revelar información
  • Los pronombres posesivos también están marcados por género tanto en inglés como en francés, pero his/her en inglés señala el género del poseedor, mientras que son/sa en francés indica el género de lo poseído, por lo que cada idioma fuerza a revelar información distinta

• El pasado “mış” en turco

  • En turco, simplificando, hay dos tiempos principales para hablar del pasado: uno general parecido al pasado simple del inglés y otra forma con “mış”
  • La forma “mış” tiene varias funciones y, al hablar de hechos pasados, se usa cuando la información es de oídas o menos confiable
  • Ante la pregunta “¿Fred fue a trabajar el lunes?”, si se vio directamente se usa el pasado común, “geldi”; si se sabe por referencia, se usa “gelmiş”
  • En inglés se puede hablar en pasado simple sin especificar la fuente o confiabilidad de la información, pero en turco en ciertos contextos se obliga a incluir el grado de certeza o si hubo testimonio directo
  • Como existe la forma “mış”, el pasado común deja de ser una opción neutral, y resulta poco natural cuando ninguna de las dos alternativas encaja del todo
  • Como el sufijo “mış” suele ir al final de la última palabra de la oración, una persona hablante de turco puede incluso terminar una frase en inglés y recién entonces notar que no indicó “esto es de oídas y no lo vi directamente”, desarrollando el hábito de querer añadir ese matiz al final
  • En inglés eso también puede expresarse fácilmente con palabras como “apparently”, pero el inglés no obliga a hacerlo, mientras que el turco sí lo hace en buena medida

• La obligatoriedad del lenguaje que los nativos casi no ven

  • Estas diferencias suelen ser difíciles de notar hasta que se aprende otro idioma o se intenta enseñar el propio a extranjeros
  • En la mayoría de los momentos en que uno elige entre presente simple y presente continuo, no piensa conscientemente qué está implicando esa elección
  • Cuando un idioma obliga a una expresión, eso no siempre aparece como la presencia de algo; también puede fijar significado por medio de la omisión
  • “I love cake” se refiere al pastel en general, mientras que “I love the cake” se refiere a un pastel específico
  • En la primera oración, la ausencia de “the” deja claro que se habla del pastel en general; si se tratara de uno específico, habría que marcarlo necesariamente con “the” o “this”
  • Puede haber otros idiomas donde no exista una expresión que corresponda directamente a esa distinción

Sapir-Whorf inverso en lenguajes de programación

• En los lenguajes de programación, incluso el Sapir-Whorf tradicional podría acercarse más a ser válido
• En lenguajes como Python o Haskell, hablar de asignación de memoria es difícil, pero no imposible
• Normalmente, las limitaciones de un lenguaje de programación se describen en términos de las cosas que cuesta expresar en él
• Sapir-Whorf does not apply to Programming Languages de Hillel Wayne profundiza más en este tema
• Desde la perspectiva del Sapir-Whorf inverso, la pregunta clave es si el lenguaje obliga a hablar incluso de cosas que en realidad no nos interesan
• Esa obligatoriedad suele hacerse visible cuando se aprenden varios lenguajes y se adquiere una mirada parecida a la de quien aprende un idioma extranjero

Ejemplos principales en lenguajes de programación

• Orden de evaluación

  • La mayoría de los lenguajes obliga a expresar el orden en que se realizan los cálculos
  • En Python, x = some_func(y + 1, z + 2) indica que primero se evalúa y + 1, luego z + 2, y después ambos valores se pasan como argumentos a some_func
  • Puede que no pensemos conscientemente en ese orden, pero en Python no hay forma de expresar ese cálculo sin especificarlo al mismo tiempo
  • La mayoría de los lenguajes son parecidos en esto, aunque en algunos el orden de evaluación se vuelve muy complejo
  • Una expresión equivalente en Haskell, como some_func (y + 1) (z + 2), no especifica en absoluto el orden de evaluación debido a su semántica no estricta
  • Esa característica permite técnicas como Tying the knot, donde se puede referenciar un valor que aún no está definido

• El color de las funciones async

  • El problema del color de las funciones async es un buen ejemplo
  • En lenguajes con una palabra clave async explícita, como Javascript o Python, hay que decir si el código es síncrono o asíncrono
  • En las funciones síncronas eso se expresa omitiendo la palabra clave async, pero igual sigue siendo una elección entre dos opciones
  • No hay forma de escribir código que sea ambiguo o neutral respecto de ese tema

• Asignación y liberación de memoria

  • La mayoría de los lenguajes sin recolección de basura) obligan a hablar de asignación y liberación de memoria
  • En lenguajes como C, normalmente eso se maneja de forma bastante explícita o se usa asignación en stack de manera implícita, pero en cualquier caso hay que elegir
  • En otros lenguajes este problema puede quedar más oculto, pero no desaparece
  • En Rust, el tema se transforma en hablar de lifetimes o de conteo de referencias explícito
  • En la práctica no existe la opción de decir “no me importa cuándo se asigna y libera esta memoria, resuélvelo tú”
  • También hay un costo en no hablar de asignación de memoria
  • Esos lenguajes casi con seguridad colocan muchos valores en el heap y requieren un recolector de basura en tiempo de ejecución
  • A cambio, el lenguaje gana mucha libertad para decidir, y Haskell por ejemplo suele hacerlo mediante análisis de strictness

• Scope

  • Todos los lenguajes modernos conocidos hacen pensar en el scope
  • En muchos casos, el scope se expresa mediante la ubicación física de las variables, y si se quiere otro comportamiento hay que usar sintaxis adicional como global o nonlocal en Python
  • Si uno no quiere pensar en absoluto en el scope, probablemente tendría que bajar a ensamblador y aceptar un único espacio global de direcciones

• Tipos

  • Los lenguajes con tipado estático suelen obligar a pensar y hablar sobre el tipo de cada variable
  • La inferencia de tipos reduce esa carga, como si un oyente más inteligente pudiera entender más por contexto, pero la conversación sigue existiendo
  • Incluso los lenguajes puramente dinámicos permiten hablar de tipos con cosas como isinstance en Python, aunque resulta más poco natural y técnicamente diferente
  • Uno de los atractivos del tipado gradual es precisamente que en la práctica evita el problema de Sapir-Whorf inverso y da libertad para hablar o no de tipos según la preferencia
  • No está claro qué tan bien funciona eso en la práctica, y las convenciones del código existente y los linters usados siempre ejercen presión en una u otra dirección

Lenguajes accesibles y barreras bajas

• Muchas características de los lenguajes de programación más “accesibles” o “fáciles de leer” pueden analizarse desde la perspectiva del Sapir-Whorf inverso
• Estos lenguajes pueden tener una barrera de Sapir-Whorf inverso más baja, es decir, no forzar a hablar sobre cosas sobre las que uno aún no tiene una postura o que todavía no entiende
• Los temas que un lenguaje de programación obliga a expresar pueden influir en cómo percibimos y elegimos los lenguajes que usamos

[GN⁺]

Opiniones en Lobste.rs

• El diseño de lenguajes, ya sean de programación o lenguas naturales, puede verse como la tarea de decidir a qué debe prestar atención la gente usuaria según qué elementos se incluyan en el lenguaje
  C implícitamente dice “presta atención a la gestión de memoria”, y Haskell dice “presta atención a los tipos que pueden contener las variables y expresiones”
  Cuando un lenguaje me lleva en la dirección a la que realmente quiero prestar atención, se siente como una herramienta adecuada para esa tarea; si no, se siente como intentar escuchar a alguien que habla en voz baja en un coctel mientras alguien grita al otro lado del salón
  La atención es el recurso más valioso, así que hace falta ser conscientes de cómo una herramienta la guía y la moldea

  • A la idea de que “el lenguaje limita lo que no se puede decir” quizá se le podría poner un nombre como no neutralidad de la expresión
    En inglés, expresar u omitir “the” no es neutral respecto a la especificidad del objeto, y en turco usar o no usar miş no es neutral respecto a si la información se obtuvo directamente o de oídas
    Esto también puede verse como el lado opuesto de la hipótesis estándar de Sapir-Whorf, o sea, que la neutralidad de la expresión limita lo que un lenguaje puede decir
    Entonces se puede explicar si un lenguaje es neutral o no sobre cierto tema, y como diseñador de lenguajes ajustar si se difumina o se concentra la atención del usuario. Por ejemplo, el garbage collection vuelve neutral la expresión respecto a la asignación en el heap, y el seguimiento de efectos vuelve no neutral la expresión respecto a los efectos secundarios y la entrada/salida

• No sé si capté por completo el punto central del texto, pero me recordó una idea que he repetido por mucho tiempo sobre Rust
  Rust está en una posición curiosa: te deja manejar referencias, pero impone reglas estrictas para garantizar la seguridad de memoria
  En C++, si piensas que algo debería ser una referencia, simplemente lo haces referencia y esperas que no haya problemas; en Python, como no tienes ese nivel de control, copias datos sin demasiada duda
  Pero en Rust puedes caer en el pozo de optimización de pensar “copiar es ineficiente, así que hagámoslo referencia”, y cuando el borrow checker te grita, te pasas una hora refactorizando código aunque estés convencido de que esa referencia es segura
  Los buenos programadores de Rust dicen “solo usa .clone, RC, Box, etc.”, y estoy de acuerdo, pero sigue ahí el hecho de que la referencia está frente a ti y parece que podría usarse de forma segura
  Entonces queda esa sensación extraña de que decidiste empeorarlo para apaciguar al borrow checker, y entiendo por qué hay gente que termina rindiéndose con un “el borrow checker es demasiado para mí”

  • Esto conecta bastante con lo que el texto quería tratar. Rust te obliga a pensar y decidir cosas que otros lenguajes no exigen, y con eso crecen tanto la carga como el poder de usar el lenguaje

• El tema está bueno, y también da gusto que aparezca un poco de gramática turca
  Otro ejemplo común es que en algunos idiomas se pueden omitir detalles como la pluralidad, y el vietnamita es un caso así
  Cuando vi que la palabra “exaggerated” tenía un enlace pensé “¿será un texto relacionado con Arrival?”, y sí resultó serlo, lo cual también estuvo divertido
  A mucha gente le encanta esa película, pero personalmente me costó suspender la incredulidad. Se presentaba como ciencia ficción, pero esa “ciencia” me parecía una especie de lingüística mágica

  • Creo que la pluralidad es justo el punto que cosas como APL, Pandas y SQL intentan cubrir
    La mayoría de los lenguajes de programación para aplicaciones toman el valor individual como una especie de base atómica. Encima de eso puedes construir listas o mapas, pero al final también son una sola cosa unitaria y muchas veces no son sutilmente compatibles entre sí
    En Rust uno termina copiando mucho entre estas estructuras, y en SQL te preocupas menos por ese problema, pero a cambio tienes que preocuparte por los índices y el plan de consulta. Sobre todo cuando la base de datos arma un plan claramente tonto que complica lo que quiero preguntar, y mejor ni hablemos de SQL NULL
    Al final, gran parte de nuestro software está especificado en exceso hasta un nivel de valores individuales que cuesta creer, y aunque las PC son 1000 veces más potentes, la mejor latencia de UI es diez veces peor que antes
    El dogmatismo de la programación orientada a objetos también tiene parte de culpa. La asincronía también se intentó una vez, pero se degrada con demasiada facilidad a un estado de ver solo los árboles y no el bosque, esperando una por una tareas que son independientes
    Hay que imaginar que https://www.uiua.org/ es feliz

• Buenos puntos. Todos los lenguajes modernos obligan o empujan con mucha fuerza a que el programador trate detalles como si se metiera a un matorral
  Los lenguajes de scripting ofrecen operaciones sobre objetivos un poco menos detallados, como programas o páginas web, pero aun así no logran eliminar los detalles
  Igual te hacen pensar y gestionar detalles minúsculos, como números, cadenas o códigos de error
  Llevamos tantos años de entrenamiento y trabajo real acostumbrándonos a gestionar detalles, que se vuelve muy difícil no pensar desde esa perspectiva

• Lo primero que me vino a la mente fue la interfaz de objetos o módulos
  En lenguajes de programación eso es muy concreto, mientras que en una conversación en lenguaje natural es mucho más difuso
  Otro ejemplo es la diferencia entre los genéricos de C++ y los de Python. En C++ hay que tratarlos de forma muy intencional, mientras que en Python se manejan bastante implícitamente si ignoras las type hints

• Esa parte de “el Sapir-Whorf inverso limita lo que un lenguaje no puede decir, o hace difícil no decir ciertas cosas, o incluso hace difícil no pensar ciertas cosas” se ve como una pirámide de gramática > modismos > biblioteca estándar > bibliotecas de terceros > ecosistema
  La parte de “difícil no pensar” parece enfocarse en problemas que son difíciles de expresar o que tienen restricciones importantes
  La familiaridad opera desde arriba y desde abajo hacia adentro, y la gente revela su trasfondo por la forma en que escribe código en cada capa

• Llevo más de 15 años leyendo, escribiendo y hablando inglés, y aun así no sabía que “I live in London” y “I'm living in London” fueran diferentes
  Ya ni sé si vivo en London o si estoy viviendo en London 😅

  • “I'm living in London” ayuda un poco si lo expandes a “I am living in London”
    Si aquí cambias la forma de gerundio por un adjetivo común y dices “I am cold”, lo entenderías como que ahora tienes frío, no como que eres fría para siempre como una supervillana
    Del mismo modo, “I am living in London” implica que ahora vives en London, pero que eso podría cambiar en el futuro
    También tiene el matiz de que no siempre has vivido en London. Es parecido a cómo “I am cold” contiene en cierta medida la idea de que al menos alguna vez has experimentado una temperatura suficientemente cálida como para notar que tu estado actual no es “normal”, sino “frío”