Live data from Hacker News

Software component names should be whimsical and cryptic

medium.com

271–280 of 339 posts

Re: Software component names should be whimsical and cryptic

#271
post #269

Earlier quoted context omitted.

> you're going to have a list of hard-to-distinguish projects like: What's hard to distinguish? These are projects that do something with CSS. If you don't need css, you skip them. If you need a polyfill, you only look at polyfill ones to see what you need. Now, let's imagine your list is "creatively" named like - shelob - arcana - custard - escalope - virtuocsso - jester-css - etc. Ah yes, this is so much easier to…

They're hard to distinguish in the sense that a colleague might ask something like "hey can you publish a new version of css-script-min" and you accidentally publish a new version of "css-min" or "css-inline-min" or whatever instead.

That's such a minuscule problem compared to trying to figure out which of the insane names is the one you need.

Re: Software component names should be whimsical and cryptic

#272
I called my startup https://text-generator.io despite the name ... it uses image recognition to help generate text and offers an embeddings API, trying to extend it now to generate other forms of content (images, audio etc) depending on the input which is unfortunate

Re: Software component names should be whimsical and cryptic

#273

Aesthetically, at this point descriptive names almost look unprofessional, or at least quickly made. If you call your thing "ui-state-syncer" I'm going to suspect it's not really a big budget mainstream thing. If it's called Vue, I'm going to think it's big enough that someone thought it was worth it to spend an hour thinking of names. It was intended to get big. This isn't some minimal internal thing for one specifi…

> Aesthetically, at this point descriptive names almost look unprofessional, or at least quickly made.

I think part of this is that in software ecosystems that have been around a long time, the most obvious descriptive name for a package tends to have been chosen by the package that got there first but is now has an API riddled with outdated anti-patterns and whose code hasn't been touched in a decade because eventually everything becomes a breaking change.

The newer package has to pick a weird-but-available name, but has the luxury of rebooting with a cleaner, simpler API and an implementation free of "bugs" that must be kept around in the name of backwards compatibility.

Once you experience enough of those, you subconsciously develop an association that "boring obvious name" equals "crappy API and weird behavior" while "weird random name" signals "nice modern API and coherent semantics". Of course, it's not always true, but humans are voracious pattern matchers and will create an association at the slightest hint of correlation.

Re: Software component names should be whimsical and cryptic

#274

Earlier quoted context omitted.

It's _A_ truth, but it's a truth that is inextricably intertwined with a certain context. If your software components are services running in the backend of a large web service company, then their purpose is likely to mutate as time goes on. In that paradigm, I totally believe it tends to be true that you're better off giving up from the beginning and just choosing unique names from the get-go. Your system is more li…

I'm saying it's not just webservice monoculture. It predates the web . Which is a better name, MS-DOS or Linux? BCPL or Perl? Source Code Control System (SCCS) or Git? If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothi…

Big projects, fine. "Software components"? Most of those aren't big projects.

Re: Software component names should be whimsical and cryptic

#275
post #253

> Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is. I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will…

Klomgan? This argument is a straw man because those names are all ridiculous and defeat the purpose of the naming strategy. If a real organization adopted the naming strategy described by this article, reason would quickly become a part of it, and all those names would therefore be disqualified. Nobody knows what a Klomgan is and it's a made-up word that's difficult to pronounce. Why would anyone suggest it? How abou…

The article specifically uses "Shelob" as an example of a desirable name. The comment you are replying to is not a straw man.

Re: Software component names should be whimsical and cryptic

#276

If you want to see this line of thinking taken a bit too far, check out the list of Trilinos packages on github: https://github.com/trilinos/Trilinos/tree/master/packages There's ~50, and nearly all of them are incomprehensible. It definitely makes things much less accessible to a newcomer / outsider. (Trilinos is a set of scientific / engineering libraries for HPC)

If you want to see this line of thinking taken to TempleOS levels, https://media.urbit.org/docs/hooncard-2022-04-03.pdf [PDF]

Re: Software component names should be whimsical and cryptic

#277

Naming is hard. It requires an understanding of what a thing does (or more accurately, at the time of coming up with the name: what the thing WILL do). One useful practice I've acquired over the years is to make the names unique. It makes it easier to search for them later. Generally, I would lean towards descriptive names. If the name no longer fits the thing, that's a great warning about scope issues. If it sounds…

Naming is hard.

I mean, there's a reason the old joke goes:

"There are only two hard problems in computer science; naming things, cache invalidation, and off-by-one errors."

Re: Software component names should be whimsical and cryptic

#279

Earlier quoted context omitted.

I'm saying it's not just webservice monoculture. It predates the web . Which is a better name, MS-DOS or Linux? BCPL or Perl? Source Code Control System (SCCS) or Git? If a name is going to last a long time, and face a lot of different people, and have lots of relationships and sub-names of its own (e.g. "github"), then it's far better that it be short, unique, and memorable than that it be descriptive. There's nothi…

Big projects, fine. "Software components"? Most of those aren't big projects.

The start of the post clarifies: "services/repos/libraries".

And yeah, all of them start at zero lines of code and zero users. Naming things sucks, but renaming things sucks worse.

Post reply on HN