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.
Software component names should be whimsical and cryptic
271–280 of 339 posts
Re: Software component names should be whimsical and cryptic
#272Re: Software component names should be whimsical and cryptic
#273Aesthetically, 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…
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
#274Earlier 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…
Re: Software component names should be whimsical and cryptic
#275> 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…
Re: Software component names should be whimsical and cryptic
#276If 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)
Re: Software component names should be whimsical and cryptic
#277Naming 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…
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
#278If i see the words "whimsical", "delightful" or {insert emoji} on a project readme, I will instantly dismiss that project. I've learnt not to trust such projects.
Re: Software component names should be whimsical and cryptic
#279Earlier 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.
And yeah, all of them start at zero lines of code and zero users. Naming things sucks, but renaming things sucks worse.