But it is also a technical improvement. main is easier to type.
It takes a lot of effort to overcome the inertia of a default, so even if the reasoning is a bit suspect the outcome is going to be a win eventually.
It takes a lot of effort to overcome the inertia of a default, so even if the reasoning is a bit suspect the outcome is going to be a win eventually.
Consider the QWERTY keyboard, which is far from the most efficient design. JavaScript is notorious for its quirks. Unix commands often lack intuitiveness, suffering from poor naming conventions. Linux is coded in a language that has memory safety issues. Even the English language itself, is riddled with inconsistencies and arbitrary exceptions. The list goes on.
To surmount the inertia for any of the mentioned examples, the replacement solution has better be significantly superior. A marginal improvement simply won't suffice, given the large costs of change.
To many people, the switch from "master" to "main" had benefits that were, at best, debatable, while introducing substantial costs such as fragmentation, outdated tutorials and scripts, and confusion for beginners, among others. That's what got people worked up.
What colossal cost do you see in granting users the choice of, say, picking their default branch name instead of being forced to use "master"?
What cost do you see in referring to "blacklists" as "allowlist" instead?
Have you ever noticed that critical projects like Kubernetes managed to adopt clear and unambiguous concepts such as "control plane node" and "worker node" without making dubious remarks regarding "inertia"?
Any argument regarding "inertia" frankly sounds like a lame excuse to stick with bigoted and racially-charged terms without any valid reason other than a refusal to extend the most basic of common courtesies.
In the case of Kubernetes, I suppose those terms were chosen from the beginning so there was no cost of switching. And hence why no one complained about it.
Which incidentally supports my claim: that people were upset about the cost of changing rather than because of their secret admiration for slavery.
Care to point out any concrete example? Just pick the absolute best example you can imagine. So far none was provided. There's all this talk about "cost" but apparently it's so costly that even providing a concrete example is prohibitively expensive.
> In the case of Kubernetes, I suppose those terms were chosen from the beginning so there was no cost of switching. And hence why no one complained about it.
What's there to complain? Absolutely nothing at all.
> What's there to complain? Absolutely nothing at all.
Well yes, that's my point. We agree on that. In the case of git, I am sure if "main" had always been the convention there would have been nothing to complain about as well. In fact, I am sure the same people who complained about the change from "master" to "main" would have complained about a change from "main" to "master".
I really try hard not to mock people on HN, but you need to take a look in the mirror. Your sheltered world view of what "makes the world better" isn't reflective of everyone elses, nor objectively true. I'm glad you think it's good, but you must understand that those who don't agree aren't generally 'bigoted racists' or even people who "don't like" those making the changes.
What contexts? Should we also ban "master" key because it implies it enslaves the other keys?
It's quite clear that managing cognitive loads is the least of all concerns considered by proponents of sticking with non-inclusive terms.
For example, the terms "blacklist"/"whitelist" do not impose a lower cognitive load than "denylist"/"allowlist", but somehow this argument is used in favour of sticking with the legacy/non-descriptive terms.
Also, there is no objective meaning to "slave". In the times of old, people talked about "slave drives" and I bet that most of the proponents of sticking with racist/bigoted language cannot even describe what it's supposed to be.