The task is to invent names for things

[Eli the Bearded]

In comp.lang.python, Peter J. Holzer <hjp-python at hjp.at> wrote:
             ^^^^^^

> On 2021-10-27 12:41:56 +0200, Karsten Hilbert wrote:
>> In that situation, is it preferable to choose a nonsensical
>> name over a mediocre one ?
> I don't know. A mediocre name conveys at least some information, and
> that seems to be better than none. On the other hand it might be just
> enough to lead the reader astray which wouldn't happen with a
> non-sensical name.

C is named as a pun on the earlier B, which was derived from BCPL, the
Barely Complete Programming Language. Unix is a pun on Multix, Linux
a personalization of Unix. sed is a portmanteaux of "stream editor".
AWK is named for the authors' initials. Perl started out as an
initialism (Practical Extraction and Report Language, I think), which
the manpage used to lead with. Ruby is named as a play on Perl, it's a
different four letter gem, and Ruby has obvious Perl influence.

But "Python"? What's Python named for? Hint, it's a pretty "non-sensical
name" for a computer language.

> But since perfect names are hard to find, using nonsensical instead of
> mediocre names would mean choosing nonsensical names most of the time.
> So I'll stick with mediocre names if in doubt.

The choice of a non-sensical is perfectly fine _when_ it's a major
component. Kafka, Python, Java, Rust. Those are all non-sensically named,
in that the name doesn't fit what it is, by pun, initials, or reference.
Someone just liked the name and applied it to thing being build. The
designer of Kafka liked the author. Guido liked Monty Python. Java is
named for coffee. Rust is named for a fungus. 

Those all work. But if you are writing a new web framework and you name
your method to log stuff to a remote server "Britney" because you were
listening the singer, that's not perfectly fine, even you want to make
"Oops, I did it again" jokes about your logged errors.

Where naming has a great importance to understanding, it needs to be
done carefully. Mediocre names work, but can be confusing. For the
remote logging example, there's probably not a lot of difficulty with
mediocre. If you're doing something with a multiple of things, do you
call it a "pod", "cluster", "group", "set", etc? You can pick one but
then when you have multiples of multiples, you'll want to pick another
and if you do it wrong it will confuse people. A Kubernetes "cluster"
will run replica "sets" of "pods" (each of which have one or more
"containers", but "containers" is a word that predates Kubernetes).

If your framework runs "sets" of "clusters" that reversal of heirarchy
ends up being more likely to confuse. Or look at the mess that AWS has
for Elasticache Redis: you can have a "cluster" that provides redundancy
in case something fails. Or you can run in "cluster mode" which shards
the data across multiple independent nodes. If you want redundancy
in "cluster mode" you can can have groups of replicas.

Redis no replication or sharding:	Node

Redis non-cluster mode cluster:		Node Replica-Node1 ...

Redis cluster mode cluster no replicaion:
	Shard-1-Primary-Node
	Shard-2-Primary-Node
	...

Redis cluster mode cluster with replicas:
	Shard-1-Primary-Node Shard-1-Replica-Node-1 ...
	Shard-2-Primary-Node Shard-2-Replica-Node-1 ...
	...

Maybe this is Redis's fault or maybe it's AWS's, I don't know the
history of these names, I've only used it on AWS. But whoever did the
naming did a "mediocre" job to come up with something that's called a
"Redis cluster-mode enabled cluster".

https://aws.amazon.com/blogs/database/work-with-cluster-mode-on-amazon-elasticache-for-redis/

Elijah
------
naming is hard, unless it's easy