14 puntos por GN⁺ 2025-12-12 | 7 comentarios | Compartir por WhatsApp
  • En la cultura moderna de desarrollo de software, los nombres de proyectos y bibliotecas se están llenando de palabras arbitrarias sin relación con su función
  • Antes, nombres como grep, awk, sed, FORTRAN, COBOL describían directamente la función o el propósito, pero hoy proliferan las denominaciones sin significado
  • Esta tendencia se aceleró con la expansión de GitHub y la cultura startup, hasta romper por completo el vínculo entre el nombre y la función
  • El costo de comprensión y la carga cognitiva aumentan, y los desarrolladores terminan repitiendo exploraciones innecesarias para entender el papel de cada herramienta
  • El texto pide restaurar reglas de nomenclatura claras y centradas en la función, y enfatiza que en las herramientas técnicas deben priorizarse la claridad y la profesionalidad por encima de la marca

El cambio en las prácticas de nomenclatura del software

  • Richard Stallman mencionó en una charla de EmacsConf de 2022 la importancia de los “nombres fáciles de recordar” y subrayó que el nombre de un paquete debería mostrar lo que hace
    • El ecosistema de Emacs ha mantenido tradicionalmente una convención de nombres basada en la función, como dired(editor de directorios) y eshell(shell de Emacs)
  • Sin embargo, los desarrolladores modernos tienden a poner a sus herramientas nombres como sustantivos aleatorios, seres mitológicos o personajes ficticios
    • Esto sería considerado en otros campos técnicos como una falta de profesionalismo

El problema de los nombres sin significado

  • Como ejemplo, nombres de herramientas como “Viper”, “Cobra”, “Melody”, “Casbin” o “Asynq” no permiten inferir en absoluto su función
    • El autor menciona que incluso tuvo que hacer búsquedas para entender la explicación de infraestructura de un amigo
  • En otros campos de la ingeniería, los nombres describen la estructura o la función
    • Ej.: Golden Gate Bridge, Hoover Dam, I-beam, butterfly valve dejan clara su forma o su papel
  • En química, sistemas como la nomenclatura IUPAC establecen que un nombre debe señalar con precisión un único objeto
    • Ej.: 2,2,4-trimethylpentane se refiere a una sola molécula, y no se le llama arbitrariamente “Steve”

Las reglas de nombres del pasado y la ruptura actual

  • En los años 80 predominaban abreviaturas basadas en la función, como grep, awk, sed, cat, diff
    • Los nombres de lenguajes de programación como FORTRAN, COBOL, BASIC, SQL, Lisp también reflejaban su propósito
  • A partir de la década de 2010 comenzó la expansión de los nombres sin significado
    • Algunos casos, como MongoDB, aún tenían cierta relación funcional o etimológica, pero después, con GitHub y la cultura startup, aumentaron de forma abrupta los nombres carentes de sentido
    • Se señala como causa la tendencia a imitar casos de éxito centrados en la marca, como Google

Costo cognitivo y menor eficiencia en el desarrollo

  • Nombres como libsodium dificultan inferir la función y obligan a los desarrolladores a cambiar de contexto una y otra vez
    • Se pierde tiempo innecesario tratando de interpretar “¿por qué sodium?”
  • Cuantas más dependencias tenga un proyecto, más se acumula este impuesto cognitivo (cognitive tax)
    • Eso termina reduciendo la productividad de los desarrolladores
  • El autor señala que, al procesar frases como “Viper, Cobra, Melody...”, se desperdician recursos mentales interpretando tokens sin significado

Objeciones comunes y sus refutaciones

  • “Los nombres fáciles de recordar ayudan al marketing” → las herramientas para desarrolladores no son productos de consumo, y la claridad funcional es más importante
  • “Los nombres descriptivos son aburridos” → ese aburrimiento es un costo aceptable a cambio de claridad; los instrumentos quirúrgicos también son aburridos, pero precisos
  • “Se hace por diversión” → todos los usuarios terminan pagando el precio de esa ‘diversión’, lo que deriva en una pérdida de tiempo para toda la industria
  • “Ya se usaron todos los buenos nombres” → puede resolverse con namespaces, prefijos y palabras compuestas, y al menos debería elegirse un nombre relacionado con la función

La dirección a seguir

  • El problema se explica menos por mala intención que por un cambio cultural
    • A medida que la programación pasó de estar centrada en empresas a estar centrada en comunidades, las normas sociales se debilitaron
  • La solución es una restauración cultural de las reglas de nomenclatura
    • Más que regulación, hace falta mejorar mediante recuperación del profesionalismo, educación y presión social
  • Los nombres de las bibliotecas deben reflejar su función, y si hace falta, también deberían aceptarse palabras compuestas y expresiones largas
    • Ej.: “http-request-validator” es mucho más claro que “zephyr”
  • Separar la mascota del nombre
    • Ej.: PostgreSQL usa la mascota elefante Slonik, pero el nombre en sí mantiene un significado funcional
  • Salvo que se trate de un producto de consumo donde la marca sea importante, debe priorizarse la claridad y la profesionalidad
    • Antes de ponerle “el nombre de tu personaje de anime favorito”, conviene preguntarse: “¿un ingeniero civil le pondría un nombre así a un sistema de puentes?”
  • En conclusión, hay que detener la proliferación de nombres sin sentido y volver a un lenguaje profesional claro
    • La claridad no es aburrimiento, sino respeto por el tiempo y los recursos cognitivos de los usuarios

7 comentarios

 
epdlemflaj 2025-12-13

Incluso awk difícilmente puede considerarse un nombre basado en su función....

 
roxie 2025-12-15

Si no hubieras puesto ejemplos, probablemente habría aumentado un 10% la capacidad de convencer.

 
kandk 2025-12-15

Estoy algo de acuerdo, pero parece que no quieren estresarse por tener que ponerles nombre.

 
qpolsa95 2025-12-13

Todos los nombres decentes ya los está usando alguien.

 
khris 2025-12-13

¿Alguien sabe qué significa emacs? Puede que tenga un significado, pero con esos nombres en acrónimo no se puede saber de un vistazo, y al final es un nombre… Además, a estas alturas ya hay demasiados proyectos como para ponerles nombre solo por su función.

 
cgl00 2025-12-13

Si le echa la culpa a GitHub, entonces es solo una crítica forzada al estilo de RMS, jaja

 
GN⁺ 2025-12-12
Comentarios de Hacker News
  • La versión GNU de Yacc se llama Bison. Pine era un acrónimo de “Pine Is Not Elm”, y UNIX surgió de UNICS como un juego de palabras con MULTICS. No sé qué significa dd, nano es un clon de pico, y Postfix combina ‘post’ y ‘bug fix’. C++ es una versión incremental de C; C vino después de B, y B después de BCPL. En realidad, los desarrolladores no perdieron la ‘filosofía de poner nombres’; simplemente nunca la tuvieron. En cambio, proyectos modernos como Clang, LLDB, jq, fzf y loc me parecen buenos ejemplos de nombres bien elegidos. mise-en-place describe perfectamente la función de mise

    • dd viene de la sentencia DD de JCL. Originalmente, tomó el nombre de la forma en que los mainframes de IBM describían archivos, y el comando dd de UNIX se creó para intercambiar archivos con mainframes. Por eso terminó con una sintaxis de tipo key=value, poco típica de UNIX
    • Tradicionalmente, dd se ha llamado en broma “delete disk” o “destroy data”, porque se usaba con frecuencia para sobrescribir bloques de disco
    • C++ se refiere al operador de incremento posfijo de C. Es decir, tiene el mismo valor que C, pero se incrementa después de leerse: una metáfora perfecta
    • GNU y Emacs también son acrónimos recursivos. Perl, Python, Java, Go, Pascal, Git, Mercurial y CVS, entre otros, también tienen orígenes de nombre muy distintos. Al final, el debate sobre los nombres me parece un alboroto sin mucha importancia
    • Back Orifice 2000 dejaba muy claro por el nombre lo que hacía, pero BitchX no
  • Los comandos de UNIX como grep, awk, sed, cat y diff tenían nombres funcionales o sistemáticos, pero en realidad solo diff se puede adivinar de forma intuitiva. Decir que awk es un buen nombre es exagerado

    • Que esos nombres se sientan naturales es solo una ilusión de familiaridad. Hoy existen muchísimas utilidades y bibliotecas, así que diferenciar los nombres es indispensable
    • Libiberty era uno de los nombres más graciosos. Se llamó así para que pudiera enlazarse con la opción -liberty
    • cat no viene de concatenate, sino de catenate. El prefijo ‘con’ se omitió por redundante. También es un ejemplo interesante desde el punto de vista lingüístico
    • awk, sed y cat no son buenos nombres; son simplemente nombres familiares. grep, en cambio, hasta suena como una onomatopeya que transmite la idea de ‘atrapar’ patrones
    • Estas siglas y abreviaturas funcionan como jerga especializada por industria: una vez que las aprendes, se vuelven naturales. Antes, la eficiencia al teclear importaba mucho, así que la diferencia entre cat y concat sí afectaba la productividad
  • Rechazo la idea de que “poner nombres así en tecnología es suicidio profesional”. Si ves la lista de nombres clave del Departamento de Defensa de EE. UU., abundan los nombres deliberadamente opacos. Hoover Dam al principio se llamó Boulder Canyon Project, y su nombre no describe su función. ¿Sería Reitzlib mejor nombre que Requests? Al final, depende del contexto

    • En química también hay nombres divertidos. Por ejemplo, algoritmos o paquetes como SHAKE, RATTLE, CHARMm y Amber. Los nombres adorables son aún más comunes en biología
    • En meteorología tampoco es una excepción. Un caso representativo es el fenómeno auroral llamado STEVE
    • Los nombres clave militares se eligen intencionalmente al azar para ocultar su significado. Los proyectos internos de empresas también usan a veces este enfoque
    • En biología pasa lo mismo: existe un nombre como Sonic hedgehog protein
    • La astronomía es especialmente famosa por sus peores nombres con siglas. Puedes ver ejemplos en este enlace
  • Nombres como awk en realidad no son buenos nombres. Son simplemente las iniciales del autor y no transmiten nada sobre su función. Hoy además existe el autocompletado con tab, así que ya no hace falta acortarlo tanto

  • Estoy de acuerdo con este texto de respuesta. Los identificadores externos cambian de significado con el tiempo, así que un nombre demasiado preciso desde el principio no envejece bien. Además, hay demasiados nombres como “X Manager” o “X Service”, lo que hace difícil distinguirlos

    • A mí me gustan los nombres ingeniosos. Si cuesta ponerle nombre, eso puede ser señal de que el concepto aún no está claro. El nombre ideal parece raro al principio, pero cuando luego entiendes el sentido, se queda en la memoria. Que el equipo de pruebas A/B de Spotify se llamara “ABBA” es el mejor ejemplo
    • Claro, depende del objetivo. Pero centrarse en una sola tarea y reflejarla en el nombre también es un buen principio
  • Trabajé como ingeniero de calibración de motores en un OEM automotriz, y todas las variables y funciones estaban escritas con abreviaturas. El primer mes fue agotador al punto de sentir que me explotaba la cabeza. Al final, un colega me dijo: “esto es como aprender un idioma nuevo”, y realmente lo era. Es decir, tener muchos nombres técnicos no reduce necesariamente la carga cognitiva

    • En comunicaciones móviles pasa lo mismo. Si intentas memorizar todas las siglas, no terminas nunca. Por ejemplo, AP puede significar Application Processor o Access Point, según el contexto. Aun así, no queda otra que usarlo porque sigue siendo más corto que MSISDN
    • Si ves este video sobre el examen de licencia de taxi en Londres, dicen que la fatiga de aprendizaje es tan grande que hasta cambia la estructura del cerebro. Los sistemas de nombres complejos generan, por naturaleza, una carga cognitiva
  • Me cuesta estar de acuerdo con la idea de que “los nombres funcionales son mejores que el marketing”. Los nombres basados en función terminan creando un mar interminable de siglas. Acabas confundiendo ABDC con ADBC

    • Yo también trabajé en una organización así, y al final aparecían nombres como CoreMainHttp y MainHttpCore, e incluso coexistían distintas API con el mismo nombre. También quedaban restos de nombres de organizaciones desaparecidas, como “DataOrgUtils”. Al final, hasta los nombres bonitos convergen por repetición. Se repiten memes culturales como Phoenix, Keymaster, Simpsons o Star Wars
    • El autor pasa por alto que las herramientas sobrevivieron tras competir entre sí. Los nombres memorables ayudaron a esa supervivencia
  • Me sorprende que haya aparecido un texto así en HN. Usar nombres como awk como ejemplo para decir que “se perdió la esencia de poner nombres” es contradictorio. Al final, parece más bien una aversión personal a los nombres lindos. Por cierto, este comentario fue escrito en Firefox, y por el nombre no se puede saber que es un navegador web

    • Incluso un nombre como awk tenía cierto sentido en su época. El software moderno piensa en una base de usuarios más amplia, así que hace falta un equilibrio entre especialización y diversión. No es que me molesten los nombres lindos, pero sí creo que en un contexto profesional hay que ser prudente. (Este comentario se envió con msmtp, un cliente SMTP cuyo nombre sí describe su función)
  • Frente a la idea de que “los nombres descriptivos son aburridos”, las herramientas del quirófano también suelen llevar nombres de personas. Adson, Allis, Babcock y Kocher no describen en absoluto su función. Al final, cuando te acostumbras, adquieren significado. awk no me convence, pero diff sí es un ejemplo razonable

    • Quien haya tenido un pin de Kirchner metido en el cuerpo va a entenderlo perfectamente
  • Ante la idea de que “nuestro campo parece un zoológico de sustantivos aleatorios”, a mí me gustan los nombres divertidos. Mi proyecto Wimsey es una biblioteca de pruebas de datos, pero eso no se adivina por el nombre. Aun así, me gustan nombres como Python, Cron y Zellij, porque transmiten cariño y humor. La tecnología al final la hacen personas, y debe haber espacio para el disfrute. “cookie” se siente más humano que “brown-dog-2”

    • Pero un nombre como “data-testing-library” pierde sentido en cuanto aparece una segunda versión
    • Un nombre estructurado como Project.Parser.Pcapng de .NET funciona bien dentro de un proyecto, pero en un contexto independiente no sirve mucho
    • En cambio, algunas personas encuentran disfrute en la propia profesionalidad y ven los nombres lindos como una distracción. También existe la idea de que el verdadero placer viene de la satisfacción del oficio artesanal