Live data from Hacker News

Software component names should be whimsical and cryptic

medium.com

261–270 of 339 posts

Re: Software component names should be whimsical and cryptic

#261
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…

Well, Shelob has no meaning to me. And yes, I know now where it comes from, but I haven't read the books.

The article says "names should make you smile." And really, does anything make a person smile more than Chumbawumba? They get knocked down, and they get up again!

Re: Software component names should be whimsical and cryptic

#263

> 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…

"I've lost the bleeps, I've lost the sweeps, and I've lost the creeps.

The what?

The what?

And the what?"

Re: Software component names should be whimsical and cryptic

#264

Think of the new people you hire! It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement. What is easier to und…

Except as the article says, names tend to stick, scopes don't.

This PaymentService grew into fraud detection. So the new hire will be even more confused. Asking "What does Picard do?" is natural, where a new hire might have trouble asking "What does the PaymentService do?"

Re: Software component names should be whimsical and cryptic

#265
post #127

I'd be curious to hear thoughts from anyone with practical experience of urbit, considering their intentionally nonsensical naming choices.

The choice of using totally novel and cryptic names for everything was intentional. The project is ambitious, and aims to do a completely fresh stack, (OS, drivers, network stack, identity, filesystem, etc.). Given that level of ambition, the choice of names was done remind the user that this is not just Unix and TCP/IP re-written, this is a whole new alien OS, based on distinct ideas.

The fact that Arvo (the kernel) doesn't even have a distinction between RAM and disk, or between PCI input and network input, is a much bigger deal than remembering that "Arvo is the kernel".

OP is right that naming can give a false sense of familiarity, so inverting that for things like this makes sense. Create a false sense of un-familiarity, to keep the users paying attention while they learn what they are using. That's been my experience so far, a heightened sense of awareness while reading through the cryptic documentation.

Re: Software component names should be whimsical and cryptic

#266

Think of the new people you hire! It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement. What is easier to und…

Except as the article says, names tend to stick, scopes don't. This PaymentService grew into fraud detection. So the new hire will be even more confused. Asking "What does Picard do?" is natural, where a new hire might have trouble asking "What does the PaymentService do?"

As someone else mentioned in the replies, this sounds more of a problem of not having a top level design than a naming problem.

You have bigger problems if your `PaymentService` morphs into the functionality of being a storage or user service.

Re: Software component names should be whimsical and cryptic

#267

Earlier quoted context omitted.

> Whimsical project names fall within a well-understood and used convention. Boy, I wish! I 100% second TFA when I tell you: There are a lot of really really boring people out there that just don't get it. They think "Product Data Exporter" is the perfect project name.

I remember how confused I was when I found out a program exists called "FileMaker". Curious how that name was chosen.

I'm still split on which category Adobe (Macromedia) Dreamweaver falls into.

Re: Software component names should be whimsical and cryptic

#268
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 "weird" for other named things to be dependent on or be required by the named thing -- that's often a hint about a context issue.

Re: Software component names should be whimsical and cryptic

#269
post #93

Earlier quoted context omitted.

> Create libraries that aim to do one thing and do it well. That's nice and all, but once you combine that with giving them descriptive names, you're going to have a list of hard-to-distinguish projects like: - css-min - css-polyfill - css-inline-min - css-inline-polyfill - css-script-min - css-script-polyfill - etc. Good luck clarifying what you're talking about. And of course, people will start using acronyms for a…

> 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.

Re: Software component names should be whimsical and cryptic

#270

Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…

Please don't cross into personal attack.

Also, please don't fulminate in HN comments.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN