His reply included a dig against gnu make for making tabs mandatory, so I don’t think this was a “stance” as in taking a pro-tabs position. He simply, reasonably, thinks parsers should be able to deal with all types of whitespace.
Tabs suck, because you can’t rely on them for consistent spacing and formatting. Spaces always win out.
Classic “you’re using it wrong”.
The tab people still use spaces for formatting if they want to format something. Tabs are only used for indentation.
Now I’m imagining how code where someone only uses tabs for everything would look.
I don’t think you know what a tab means.
How can you not rely on them for consistent spacing? It’s a tab.
But 2 or 4 spaces?
Maybe we can compromise with 3?
Heretic!
Well since we ditched the old 80 column terminals I’ve always thought a laid back 7 spacer tab would be sublime. Chilled indentation and a big prime number of spaces. Very profound, what’s not to like?
Man I could not for the life of me figure out what was wrong with my
docker-compose.ymlfile one time a while back. The issue was that I somehow managed to indent using spaces in some lines and tabs on another. I was using vim at the time and it took me a while but eventually I figured it out.Hey, im not a coder, can someone ELI5 the 2 camps on this one for me and other lurkers?
Edit: Thank you kindly, much appreciated! Now i have a better understanding of something I’ve come across in discussion ice witnessed but not been a part of.
And thanks Lemmy, for the opportunity to have come across this in the first place so that i was able to learn, or at least gain a wee bit of insight into this
Programmers use a margin on the beginning of a code line to easily identify that that line is related to a previous line (for example, one line may establish a condition and the next line an action to be executed on that condition, the line with the action will have this margin in this case).
There are basically two ways to create this margin: by adding a tab character or by adding spaces. The tab character is a special character that exists specifically for things like this and most tools allow you to configure the size of the margin it adds. Spaces on the other hand have a fixed size so if you add two spaces the margin will always be of two spaces.
Programmers have forever argued about their preferences on this and it often results in very heated arguments.
Tabs are generally considered the best choice but many people disagree, usually because of one of those three things:
-
they think that people who use tabs want to replace all usages of spaces with tabs and not just this specific use case. Then demonstrate how tabs can be unpractical on other situations (that don’t really have anything to do with the original argument).
-
they use (or need to use) some shitty tool that do not recognize tabs properly, or that force an unpractical tab size on them (not as common these days as it used to be, but still happens).
-
they actually want everyone to always display those margins with the same size regardless of each individual’s personal preferences.
-
It’s, as Linus mentions, all about bad tooling.
I don’t think that anyone disagrees that tabs are “technically” the better choice, as they are a representation of indentation rather than a visual absolute. They aren’t visible and your UI should render them as one, two, four spaces or however you would prefer it to appear.
However there were a lot of editors that were shit. They displayed them as four spaces, which IMHO is quite frankly awful to read, and they provide no way to customise it.
As such the world split into two. Those who valued being able to set their indentation to what they preferred, and those that didn’t have a tool that displayed the text in a pleasant way.
So we end up with edicts from Python that say “Thou shalt not use tabs”, and ones from Linus saying “Thou shalt not not shitty tooling”.
Tab masterrace.
Blech, tabs
This is the best summary I could come up with:
You can see glimpses of this newer, less curse-laden approach in how Torvalds recently addressed a commit with which he vehemently disagreed.
The commit last week changed exactly one thing on one line, replacing a tab character with a space: “It helps Kconfig parsers to read file without error.”
If you’ve read this far and don’t understand what’s happening, please allow me, a failed CS minor, to offer a quick explanation: Tabs Versus Spaces will never be truly resolved, codified, or set right by standards, and the energy spent on the issue over time could, if harnessed, likely power one or more small nations.
By attempting to smooth over one tiny part of the kernel so that a parsing tool could see a space character as a delineating whitespace, Prasad Pandit inadvertently spurred a robust rebuttal:
In fact, let’s make such breakage more obvious than some esoteric ftrace record size option.
Yes, tab-vs-space confusion is sadly a traditional Unix thing, and ‘make’ is famous for being broken in this regard.
The original article contains 476 words, the summary contains 170 words. Saved 64%. I’m a bot and I’m open source!
Tabs converted to spaces. Because I like tabs but I also want consistency.
Tabs are consistent?
What if when aligning details inside a line you replaced the spaces with tabs because you’re an idiot or a osychop? what then huh? how do tabs solve that?
Therefore I’ll reinvent a bad version of tabs with macros that repeat an integer number of spaces and you’ll write a script for emacs that visually replaces that with a different integer number of spaces so things render how you like.
Are you okay? None of that makes any sense.
Folks advocating for tabs use them for indentation, not alignment. What has that got to do with Emacs?
My comment is a joke at people who think tab users want to use tabs for more than indentation
