Marcos Merino
EditorDurante décadas, podría decirse que las ingenierías ha compartido un principio básico: los nombres importan. 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 Muhammed, en 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 deberían 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 adicional inmediato: 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: Asynq es una librería para procesamiento asíncrono de tareas y colas de trabajos en Go (job queue).
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' (global regular expression print), 'sed' (stream editor), 'diff' (difference) o 'cat' (concatenate) 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 auge de la cultura startup 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 previo 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.
El otro punto de vista
En los foros de HackerNews, sin 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:
- GNU, un acrónimo recursivo (es decir, que se incluye a sí mismo:"GNU’s Not Unix").
- awk, iniciales de apellidos (por sus creadores Aho, Weinberger y Kernighan).
- dd, quizá el caso más extremo: nadie parece ponerse de acuerdo sobre qué significa realmente.
Otros reconocen que no todos on nombres que carezcan 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).
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 admiten sin pudor que usan 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 arbitrario, como 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 miles 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.
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), llamar a tu proyecto 'http-client' puede que resulte descriptivo, pero es una opción pésima cuando pretendes 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 difícil, y hacerlo bien es raro.
Algunos comentarios rescatan un punto intermedio muy interesante: los nombres funcionan mejor cuando hay una relación, aunque sea metafórica, con lo que hace la herramienta. Bison funciona porque es “GNU Yacc”; sodium 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 disparate: por qué unas aplicaciones van por la 1.0 y otras por la 100.0
