Programmers and software developers lost the plot on naming their tools

Posted by todsacerdoti 12/11/2025

Programmers and software developers lost the plot on naming their tools(larr.net)

422 points | 534 commentspage 8

perrygeo 12/12/2025|

The cognitive tax is a real problem. Using random cutesy names, there is no obvious behavior boundary. Does authentication go in the SnufBux module? Or the Farfrumstable service? Who knows? Without obvious language clues to handle a new concept, any new functionality will get strewn across these internal boundaries. And why not - they have zero semantic meaning anyway! Sloppy names encourage sloppy programming.

hansvm 12/12/2025|

And you've spotted why normal, regular, simple, natural, real mathematics is so hard for people to grok at first glance.

longemen3000 12/12/2025||

That is one thing i like about the Julia package ecosystem. The general Registry (where package metadata is stored and where you go to register a new package), recommends using explicit names over short acronyms. For example, DifferentialEquations.jl is a package that does differential equations in julia (recognizable via the .jl suffix). What does Garlic.jl do? Exactly, garlic (the vegetable) modelling.

PhilipRoman 12/12/2025|

Does Julia registry have active moderation? Otherwise I'd expect to see 99 different variations of DifferentialEquations.jl

eigenspace 12/12/2025||

Yes, but it's fairly light-touch moderation. Newly registered first packages go through some automatic checks, and if they pass all those checks they are put on a 3-day waiting period for community to give feedback or raise objections to the package, and then at the end of the 3-day period, if nobody blocks it, the package is registered.

One of the automatic checks is a name similarity check, and if the name is too similar to an existing name, then the package is blocked from being auto-merged. At that point, someone will look at it, and there'll be a discussion on whether or not the name is okay. A lot of the time, the response is just "this is a false positive" and the package is greenlit. Other times, there's a discussion on whether or not the name is acceptable, and some alternative suggestions are given.

_______________

There was a little episode recently where someone tried to register a package with the same name as an existing package, but with two letters tacked onto the end of the name. Their package was just a fork of an existing package, but with a minor patch applied becuase they were frustrated that maintainers of the existing package weren't responding to pull requests.

The system automatically flagged the name, and the person was initially upset that they couldn't just register their fork, but within a couple hours we tracked down a maintainer to fix the existing package, and then we added this person as a maintainer to the original package so that they could review and accept pull requests to the package themselves. I think this ended up being a better solution for everyone involved.

dannyfreeman 12/11/2025||

I believe one of the things that prompted stallman to give that talk was the inclusion of the lsp client "eglot" in emacs. Eglot i think is short for emacs polyglot.

The most idiomatic name, lsp-mode, was taken by another package. Stallman wanted to find another name but no one seemed to care as much as he did. I think one name he suggested in its place at one point was "code-parse" or something like that.

MisterTea 12/11/2025||

I agree, some names that come to mind are Celery and Windows. But there are always silly names. I like Plan 9, an OS named after an Ed Wood B movie. Its sibling, Inferno is full of puns and references to Dante Alighieri's Divine Comedy. Its corporate dullards who insist that neutral boring is appealing to most and I again agree but its not a hard rule for me.

liampulles 12/12/2025||

I read an article linked on HN once (can't remember what it was) that recommended giving totally meaningless names to monoliths. The point being that one should not use the name as a crutch to decide what should or should not go in the service.

So at my last job, we called our monolith anubis. It always brought joy when someone asked for an explanation.

djmips 12/12/2025||

This essay is not consistent. They ramble between company names Google ( which is a great name ) and tools like AWK which is not descriptive at all but a good name.

But I do share his pain with onboarding when I joined Humungous Entertainment the tools or systems were called Sputm, Phlegm, Mucus, SPIT. There might have been a Bile. :-)

joleyj 12/12/2025|

Have a Stoolap https://github.com/stoolap/stoolap

djmips 12/12/2025||

It's good to see it's written in Rust with full Acid compliance...

assimpleaspossi 12/12/2025||

A lot of the issue has to do with marketing. Some people name their tool for the pizazz it might generate and gain them fame or it's an actual company motivation. Instead of a hammer is a hammer and a heavy hammer should be named "heavy_hammer".

EDIT: I just noticed that the marketing angle is mentioned in the article.

zcw100 12/11/2025||

Why does it have to be all or nothing? How about a clever name or two for marketing that stands out and doesn't get lost in a sentence "I'm not asking you to search, I'm asking you to use the search command" but not obnoxiously over done where everything is named after some Norse god or some other silliness.

teleforce 12/12/2025||

Forget about tools, in most part of the world, the name programmer and software developers like to call themselves namely software engineer is not even considered part of engineering professions.

That's why you find most of software engineering department in Computer Science Faculty or School, not in the Faculty of Engineering.

necovek 12/12/2025|

Why does nobody in SF say "I am going via the San Francisco-Oakland Bay Bridge", but shortens it to just the "Bay Bridge"? This is the reason some bridges get a nice name (like Golden Gate), and some are strictly utilitarian (like SF-Oakland Bay).

And I am sure there are other "Bay Bridges" in the world too.

More comments...