Durante décadas, podría decirse que las ingenierías han compartido un principio básico: los nombres importantes. Es decir, que un puente, una válvula, un compuesto químico o un instrumento quirúrgico reciben nombres que dicen algo sobre su función, su forma o su propósito. Nadie espera creatividad literaria en un manual técnico.: lo que se espera es claridad. Sin embargo, según el programador Salih Muhammeden el mundo del software algo se terminó torciendo en los últimos años.
Hoy convivimos con listados de aplicaciones, librerías de desarrollo y plataformas cloud poblados de serpientes, dioses nórdicos, animales y, en general, de palabras que no significan absolutamente nada relacionado con lo que en realidad hacen.
Esta tendencia, que a muchos puede parecerle simpática o inofensiva, según Muhammed tiene un coste muy real que pagamos con atención, memoria y esfuerzo mental. Él lo califica de ‘impuesto cognitivo’. Confucio ya hablaba de ello en sus ‘Analectas’:
«Zǐ lù dijo: Si el monarca de Wèi decidiera que el maestro se convirtiera en gobernante, ¿qué llevaría el maestro a cabo primero?»
«El maestro dijo: sería necesario rectificar los nombres«.
«Zǐ lù dijo: ¿esto harías? ¡el maestro es un pedante! ¿por qué rectificarlos?»
«El maestro dijo: Porque si los nombres no están rectificados, entonces las palabras no son eficaces; si las palabras no son eficaces, entonces los asuntos no se llevan a cabo (…)».
Cuando el nombre deja de ayudar
Richard Stallman, una de las figuras históricas del software libre, señalaba en una charla reciente algo que debería resultar obvio, pero que ya no lo es: las herramientas deben tener nombres que ayuden a recordar qué hacen.
El problema no es que exista algún nombre creativo aquí o allá. El problema es que la excepción se ha convertido en norma. Hoy es habitual escuchar descripciones técnicas que suenan más a un poema surrealista que a una arquitectura informática:
«Usamos Viper (‘víbora’) para la configuración, Cobra para la línea de comandos, Melody para los WebSockets, Casbin para permisos y Asynq para las colas de trabajo».
Desde el punto de vista del oyente, esa frase exige un esfuerzo inmediato adicional: detenerse, mapear cada nombre a su función real, consultar documentación o hacer búsquedas mentales forzadas. De todos los nombres, sólo el último tiene algo que ver con su función: asínq es una librería para procesamiento asíncrono de tareas y colas de trabajos en Go (cola de trabajo).
En otras ingenierías esto no pasaría
Imaginemos el mismo fenómeno trasladado a otros campos. Un ingeniero civil no hablaría de reforzar un edificio con el sistema «ThunderFalcon». Un cardiólogo no diría que va a implantar un ‘Butterfly X’ en lugar de un stent coronario. Y un químico no bautiza una molécula como «Steve» para que suene gracioso.
Cualquiera que haya estudiado algo de química sabe, de hecho, que la nomenclatura de los compuestos no es algo que se deja al azar: es preferible que algo tenga un nombre largo antes de que no quede claro a qué nos estamos refiriendo.
Durante los primeros años de la informática, este mismo principio era la norma. Herramientas como ‘grep’ (impresión de expresión regular global), ‘sed’ (editor de secuencias), ‘diferencia’ (diferencia) o ‘gato’ (concatenar) no resultaban muy líricas, pero funcionales. Los primeros lenguajes de programación también seguían esa lógica: FORTRAN, COBOL, BASIC, SQL. Incluso cuando había abreviaturas, el significado estaba ahí.
Muhammed no tiene claro cuando comenzó el problema, pero señala que la deriva se aceleró con dos fenómenos: el startup auge de la cultura y la multiplicación del software abierto en plataformas como GitHub.
Nombrar un producto de consumo con una palabra llamativa tiene sentido cuando se invierten millones en marketing y posicionamiento. ‘Google’ podía permitirse ser una palabra sin significado anterior porque se convirtió en verbo a base de omnipresencia. Pero una librería técnica con unas pocas decenas o cientos de usuarios. no tiene ese colchón cultural.
Aun así, muchos desarrolladores empezaron a imitar ese estilo: el resultado es un ecosistema saturado de nombres que no describen nada y que obligan a todos los demás a hacer trabajo extra: cuando alguien se encuentra con una dependencia llamada ‘libsodium’, debe detenerse y preguntarse «¿De qué va esto? ¿Criptografía? ¿Por qué ‘sodio’? ¿Es algún chiste químico?».
Ese pequeño esfuerzo mental exige sólo unos segundos, es cierto, pero en un proyecto moderno, con decenas o cientos de dependencias, esos segundos se multiplican. A lo largo de una carrera profesional, conlleva montañas de esfuerzo mental que no se dedica a resolver problemas reales, sino a descifrar etiquetas arbitrarias.
En los foros de HackerNewssin embargo, no todo el mundo acepta que haya habido una ‘edad dorada’ de buenos nombres que luego se perdió. De hecho, una de las respuestas más votadas lo resume con una frase demoledora:
«A los desarrolladores no ‘se nos fue de las manos’, nunca lo tuvimos entre manos y punto».
Una de las primeras reacciones del foro es desmontar la idealización de los nombres ‘clásicos’ de Unix y del software temprano. Se mencionan ejemplos como:
- ÑUun acrónimo recursivo (es decir, que se incluye a sí mismo:»GNU’s Not Unix»).
- awkiniciales de apellidos (por sus creadores Aho, Weinberger y Kernighan).
- ddquizás el caso más extremo: nadie parece ponerse de acuerdo sobre qué significa realmente.
Otros reconocen que no todos en nombres que cuidan del todo de sentido. pero que muchos solo funcionan dentro de un contexto histórico y cultural muy específico… y que si no lo conoces, el nombre deja de ser una pista y se convierte en un jeroglífico. El caso de la app ‘Bison’ (Bisonte) resulta paradigmático: es la versión GNU de Yacc (‘Yet Another Compiler-Compiler’), que suena igual que ‘yak’ (un animal emparentado con el bisonte).
9 PROGRAMAS tan BUENOS que es difícil creer que sean completamente GRATUITOS
Familiaridad y claridad no son lo mismo
Una idea que se repite en el debate es que la sensación de algo sea un ‘buen nombre’ suele ser retrospectiva: cuando una herramienta se usa durante años, su nombre se vuelve transparente por pura costumbre, no porque sea intrínsecamente bueno.
Muchos participantes sin permitir pudieron que usen aplicaciones de las antes mencionadas a diario sin recordar ya —o sin haber sabido nunca— qué significan esas siglas: así, el nombre deja de ser semántico y pasa a ser un simple identificador arbitrariocomo lo sería cualquier palabra inventada.
Desde esta perspectiva, el problema no es tanto el nombre como el volumen: hoy el número de herramientas, librerías y frameworks ha explotado; hay millas de proyectos nuevos cada año, y la carga cognitiva no proviene de que un nombre sea raro, sino de que hay demasiados nombres que aprender.
Antes, una persona podía conocer ‘todos’ los nombres relevantes del ecosistema Unix. Hoy eso es imposible (y también hay muchos más ecosistemas)
Marketing, buscabilidad y SEO
Otro argumento recurrente es práctico: el nombre tiene que ser único y fácil de encontrar. En un mundo dominado por buscadores (y ahora también por modelos de lenguaje), llama a tu proyecto ‘cliente http‘ puede que resulte descriptivo, pero es una opción pésima cuando pretende que el usuario busque documentación sobre el mismo.
Esto no justifica el uso de nombres completamente arbitrarios, claro… pero explica por qué muchos desarrolladores buscan palabras distintivas, incluso a costa de claridad inmediata.
¿Entonces no hay problema?
No exactamente. Aunque muchos participantes consideran exagerada la queja original, también hay un consenso implícito: nombrar cosas es dificily hacerlo bien es raro.
Algunos comentarios rescatan un punto intermedio muy interesante: los nombres funcionan mejor cuando hay una relación, aunque sea metafóricacon lo que hace la herramienta. Bison funciona porque es “GNU Yacc”; sodio porque viene de NaCl; grep porque remite a una acción concreta dentro de ed.
El problema surge cuando la relación desaparece por completo y el nombre se convierte en una ocurrencia privada sin anclaje compartido.
Imagen | Marcos Merino mediante IA
En Xataka | Los números de versiones son un dispares: por qué unas aplicaciones van por la 1.0 y otras por la 100.0
