I was once told that the tab key can be represented in different ways on different systems, and that's why spaces are safer because they're always represented the same.
Is that what Brendan was trying to say?
It's literally difficult to enter a "tab" character into many text entry fields and dialogs and applications, because it's used so often as a navigation key.
I only found this because I am an Emacs user and I instinctively tried Control-Q first (because many other key bindings like C-f or C-b work). The Control-I bit is a guess that worked. I cannot imagine a non-technical user knowing how to insert a tab character in Safari.
The main counter argument is that users have different preferences for the amount of indentation, so giving them control over that, just as they (nowadays) have control over the font used and window width, is a good idea.
The tongue-in-cheek counter argument is that fixed-width spaces are preferable over ‘normal’ spaces. They also give you more control over indentation, allowing, for example, mixing usage of THREE-PER-EM SPACE (https://unicode-explorer.com/c/2004) for indentation with FIGURE SPACE (https://unicode-explorer.com/c/2007) for right-aligning numbers.
Now that im thinking about it I’m convinced capslock would have been superior next field key and alt+capslock to be used for toggling capslock. But it’s not obvious to me capslock [e: must be] seen by the OS. It could be changed on the keyboards themselves.
You can configure your editor so that pressing the tab key inserts a tab character. Good luck with a web browser, or a UI where tab moves focus to the next control. The space bar basically always inserts a space character.
Except when it does page forward.
Bullshit reasoning though, because even people who use spaces for indentation don't do it by hammering the space bar - they also press the tab key. And of course in modern browsers we can give tab the expected behaviour.
The only logic I've ever heard for using spaces for indentation that actually makes sense and I vaguely agree with, is that lots of programmers do not give a shit about formatting code and even using spaces properly is often a bit too much for them.
That doesn't matter so much if you have an autoformatter though, so with the exception of Go I don't know why modern languages with widely used autoformatters don't use tabs.
About your point of tab being represented different on different systems: It will always be ascii 9, how it's draw does differ between text editors but I consider that one of it's strengths for programming. Everyone can configure what an indent looks like for them, it makes reading code easier.
But yeah I guess, that's another argument against getting accustomed to tabs for indentation.
The typewriter history was irrelevant.
He said people argued how wide should a tab be. And this caused misery. But almost all tabs advocates said tabs should be any width you want in my experience. And spaces advocates argued how many spaces should indentation be.
He said there was no value in the conflict. There is value in accessibility.[1][2]
He said tabs could be eliminated and spaces could not. Spaces could be eliminated for indentation. And indentation could replace alignment with initial spaces.[3]
[1] https://news.ycombinator.com/item?id=20341354
That tabs can be eliminated but spaces not. The rest is incidental to this idea.