Inertia is not merely caused by a psychological block, overcoming it carries real tangible costs. There are countless examples where technically superior solutions exist, but the benefits they offer do not outweigh the cost of overcoming inertia.
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.
> Inertia is not merely caused by a psychological block, overcoming it carries real tangible costs. There are countless examples where technically superior solutions exist, but the benefits they offer do not outweigh the cost of overcoming inertia.
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.
The costs were moderate, not colossal. But they were still bigger than the benefits, which were tiny to non-existant. Because 99.99% of people do not actually see a "master branch" as a racially-charged or bigoted term.
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.
But I did provide some examples in my original comment: "fragmentation, outdated tutorials and scripts, and confusion for beginners".
> 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".
This is such a silly argument. Let’s call it “m” then - it’s even easier to type, so should be an even bigger win, right? Thousands of scripts and workflows be damned.
Less silly than you might think. An important part of life is letting people you don't like make the world better. The people behind this change are the up-in-others-business personalities. They're always going to be destructive, but we should appreciate when they do a little good nevertheless.
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.
Literally everyone who renamed their master branch to main thought it was good, that is why they did it. There isn't some international police force conspiring to strong-arm unwilling coders into renaming their default git branch.
Except its a very common adjective, so any time you refer to it you have to say 'main branch' otherwise you've introduced unnecessary ambiguity. Whereas 'master' refers to one thing and one thing only in most contexts (unless you're selling bedrooms).
> Replacing one well known default with another non-retroactively increases cognitive load.
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.
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.