Programmers and software developers lost the plot on naming their tools

Embarrassing or opaque names

• Many comments share examples of tools or packages whose names lead to porn, fetishes, or childish humor when searched, or that are awkward to say in professional settings.
• This is used both to support the article’s claim (“this is embarrassing and off‑putting”) and to shrug it off as long-running hacker culture.

Descriptive vs whimsical naming

• Some strongly agree with the article: names should convey function or domain (“http-request-validator” beats “zephyr”), especially for infrastructure, libraries, and internal tools.
• Others argue descriptive names are overrated: you rarely infer true behavior from a name anyway; meaningful understanding always requires reading docs or code.
• Several point out that historically praised names (awk, sed, grep, BASIC, Postgres, etc.) are not obvious to newcomers either, and mainly feel “good” because people already know them.

Renaming, scope creep, and identifiers

• One camp: don’t use purpose‑agnostic names to pre‑optimize for scope creep; instead, name by function and accept the rare cost of a rename when direction changes.
• Opposing camp: renaming anything widely shipped is extremely painful (packages, configs, docs, scripts, mental models), so pick a stable “ID-like” name from the start and let functionality evolve.
• Popular compromise: internal code names (often whimsical) during development, then a more descriptive or marketable name once something is user-facing.

Comparisons to other fields

• Multiple commenters challenge the article’s claim that other technical disciplines are more disciplined: they list playful or opaque names in biology, chemistry, physics, astronomy, medicine, the military, and engineering.
• Others counter that those fields also have parallel systematic naming schemes (IUPAC, drug generics, engine model codes, astronomical catalog numbers) that software often lacks.

Searchability, acronyms, and collisions

• Whimsical, unique names can be excellent for search; generic names like “auth-service” or “http-client” are hard to Google and ambiguous in conversation.
• Conversely, overloaded common words (e.g., “combine”, “windows”, “nat”, “webhooks”) or generic library names can create confusion and name collisions across ecosystems.
• Heavy use of acronyms and initialisms in “serious” naming is cited as another source of cognitive load; people often end up memorizing arbitrary letter salads instead of clear concepts.

Culture, professionalism, and fun

• Some see silly names as unprofessional or as adding “cognitive tax”.
• Others defend whimsy as part of engineering culture, argue that many serious sciences do the same, and say that joy, memorability, and branding are legitimate goals alongside clarity.