Funny and enjoyable, but I have a serious question about tabs. I would actually like to provoke a religious war here because I’m developing yet another language and am trying to decide on spaces vs. tabs.
I don’t mind whitespace-significant languages like Python, but wouldn’t tabs be a better choice? Seems like you can easily get lost after a few levels of indentation, and much more to the point, it seems like tabs are superior because a) your IDE can display them with any width, making it easier to follow long passages with deep indentation, and b) they could free up the editor from requiring a mono space font.
>your IDE can display them with any width, making it easier to follow long passages with deep indentation
this to me is the crucial disadvantage because it baits people with low tab-width into writing deeply nested code, which is usually seen as a bad pattern, and also blows up on the screen on someone using a wider tab-width.
It wouldn't necessarily, but then again it's another thing that code reviewers have to look out for, which is time wasted on other things they could do.
I'm in favour of strong uniform rules. Make it 4 spaces, line width 80 and then everybody lives in the same formatting world.
Yes. Model your language on Python except each level of indent must be exactly one space.
Really?? Let's check...
if am == serious:
print "Really."
elif but == srs:
print "Haha. But really"
else:
print "This line actually a syntax error because wrong indent level."
Just my humble suggestion :)
EDIT: no fair downvoting, he said "any thoughts" and I gave some thoughts, with example.
I played around with various indentation styles and also eventually came to a preference of one space --- all the space savings(!) of tabs, with none of their odd behaviour. As an additional bonus, the column counter of the text editor doubles as a display of the indentation level.
That said, when working with shared code I believe what's more important is "micro-consistency" : the exact style doesn't really matter, as long as it's not so inconsistent that it confuses someone inspecting a function or file. One or ten spaces, or tabs, all applied consistently are far better than things like misleading indentation or mixed tabs and spaces in the same block of code.
Thanks for that feedback :) I suggested it because OP asked for suggestions and thoughts for their new language. I'm kind of peeved at the downvotes because at a minimum it's a reasonable idea to look into - as you've just confirmed, saying you've picked it as the best solution.
I thought it's worth considering as the syntax solution for a new language! It's fully orthogonal and removes all style decisions. The compiler never has to guess. That actually means the IDE could be fully sure of it in every case and could let you adjust the tabs, as in this example I put together (using excel and a C program):
I chose my suggestion based on orthogonality. Originally I started suggesting 2-space tabs for OP's new languages (as a syntax feature), since they're a pretty common style convention used by many in the C world, so not totally absurd.
But that is not fully orthogonal and hard to automate: if the compiler encounters 3 spaces, what is that supposed to be? Automatically a syntax error?
How many indents is 6 spaces again? -- when you use 2-space tabs the answer is 3
//Guess below line's indent level (2-space indents)
x
With two-space tabs, the answer is 3:
//This is indented how many?
x
a
b
c
x
but when you use 1-space tabs the same is:
//Guess below line's indent level? (1-space indents)
x
//Answer:
x
a
b
c
x
You can just count, and it is visually also very clear.
As mentioned your IDE can treat leading spaces as indents. (Visually indent them.) It's a 1:1 correspondence.
Anyway just my humble suggestion for tomcam's new language, who solicited ideas with "Any ideas?". I gave actual code snippets in my original comment. :)
The fact that the topic tends to "provoke a religious war" should be enough clue to know that you need to support both, not one or the other. There's also enough hate for Makefile's required use of tabs to now have yet another language with such a requirement.
If you want your language to have a wide range of users, let me tell that I wouldn't chose to use a language that required me to use tabs. I don't care what awesome features it has. It's a dealbreaker.
By the way, your reason "a" is the age-old argument in favour of tab indentation. You're not going to convince anyone that prefers spaces like that. We've all heard it.
However, your reason "b" is just horrid and invalid. I've never heard of a programmer that would prefer to code in variable width font. OMG.
I'm not going to reply further than this. You have to be trolling.
Spaces 100%. Especially in cases with significant whitspace like Python or heredocs etc.
Personally, I don't get nor like the "adjust to taste" tab argument. I routinely look at the same code in multiple editors. Intellij, vim, code reviews, code search tools, git diff output. In the browser and in a terminal.
Don't break my vertical allignment. I don't need it often but when I do I really need it. Functions with long params. Data points in opengl arrays.
One consistent cannonical form. That's where it's at. That's what I want.
How would using tabs break your vertical alignment? You'd still get the exact same alignment but instead of pressing space four times, you just press tab once. Most IDEs will either convert tabs to spaces or auto-indent based on the language-specific rules anyway, so I really don't understand this argument either way.
Why would you press space four times? I hit tab and my editor does the right thing. Is there a popular editor that lacks this sort of feature?
Edit: it's worth mentioning that this kind of tooling is extremely important, as reducing the issues that drive religious wars is a priceless sort of feature.
Using tabs for indentation doesn't do that. Using tabs for alignment does that, and virtually nobody wants that, including people who use tabs for indentation. Indentation and alignment are two separate issues. "Use tabs" is shorthand for "Use tabs for indentation", not "Use tabs for indentation and alignment".
Must you? Is there really no existing language sufficient for your needs?
Otherwise, you should be opinionated on this (and language design in general). Use tabs if you like them, nobody with a half decent editor will notice after two minutes of configuration anyway.
Two completely different rebuttal options to the “IDE can display them with any width” argument:
1) Your IDE can parse code and reformat it in literally any way you want. This includes indentation width (regardless of whether the code is actually stored using tabs or spaces), but also things like line width, semicolons, string quoting style, etc. (e.g. Prettier for JavaScript), or even using completely different language syntaxes that have the same semantics (e.g. Ocaml and ReasonML).
2) Stylistic code formatting choices, while completely ignored by the computer, are important for humans. Some style choices can have significant effects on engineering quality. The obvious example is variable names, but perhaps a subtler example is that a wide indentation width can discourage deep nesting.
> a) your IDE can display them with any width, making it easier to follow long passages with deep indentation, and b) they could free up the editor from requiring a mono space font.
Both points (and more!) can be resolved if the on-disk format is not considered directly the on-screen format. Instead if the on-disk format is considered a serialization of the AST and editors would display it with "just-in-time" formatting based on user-preferences, then that would resolve the tabs vs spaces discussion once and for all.
Incidentally I'm a fan of the concept of structured editing etc.
Making tabs compulsory would kill your language dead in the marketplace of ideas even if it was somehow miraculously better than every other language in every single detail.
Sorry missed this at the time. Sure, gofmt formats with tabs, perfectly understandable. But very different from Golang refusing to compile code that doesn't use tabs, i.e. "compulsory use of tabs".
The tabs advantages you mention are largely hypothetical / theoretical in nature, because there will inevitably be a mix of spaces AND tabs. So the choice is really: "spaces only" vs "tabs and spaces". Which is why spaces wins.
Tabs 100%. Especially in cases with significant whitespace like Python.
Personally, I don't get nor like the "just press the space bar 12 times when you want to indent to 3 levels“ argument. I routinely look at different code in the same editor. Someone’s Python code, another open source library’s Javascript code, some abandoned Wordpress theme.
Don't break my horizontal cadence. If I’m used to single-level indentations being 4 characters wide it really throws me off when I’m looking at indentations a single character wide. I have to refactor the entire code just for the step-indentations to be “normal” for me. A tab-indentation on my editor is as wide as I’m comfortable with.
I don’t care what form someone uses. I’m probably selecting all and converting spaces to tabs when I’m working with it. And maybe I’ll program my editor to automatically convert tabs to spaces when I’m uploading to GIT to make everyone happy. That's where it's at.
> Personally, I don't get nor like the "just press the space bar 12 times when you want to indent to 3 levels“ argument.
This sounds like a strawman. Most people who use spaces configure their editor so pressing tab inserts spaces. You don’t have to press space 12 times to indent to 3 levels.
this sounds like a non-sequitor. most people complaining about tabs can also configure their editor to make it work for them. Why must I have to?
I like my tab bar to actually create real tabs because I actually have my editor show space & tab characters and tabs tell me the intent of the programmer (to indent) better than spaces do.
We choose monospace fonts for programming for a reason. Tab shouldn't even exist is a monospace font. If tab hadn't existed out of the gate, no sane person would ask for it to be added.
I used tabs for a bit, then I saw my code looked awful on GitHub because they used a tabwidth of 8. At the time there was no way to change that. I was the only person working on the project, so I switched to spaces. You're still stuck with a tabwidth of 8 on GitLab. And everywhere else it seems to be based on the project's .editorconfig, so you're stuck with whatever the project authors decided anyways.
Tabs are configurable, but configuration is required. You must configure every project for every editor to get reasonable display, which is annoying when possible and even more annoying when impossible.
The whole point of using tabs is that the configuration can be per person instead of per project, and pretty much the whole point of EditorConfig is that spaces also require configuration.
Well, at least the article doesn't take itself too seriously.
Most bikeshed discussions, especially wrt code style, are excuses for guys to trot out some toxic masculinity in the workplace. They aren't telling you to alphabetise your imports to improve the codebase but to start an argument they think they can win. It leads to a hostile environment.
The reason spaces "are winning" is that tabs are the "live and let live" solution (read the code however you like) and spaces are the totalitarian solution -- "My code must look the same on your screen." Totalitarianism is naturally proselytising.
Thankfully the end is in sight. "Auto-formatters" are the "total control" endgame. They are probably a net drag on productivity, but they come with one incredible upside: nobody need ever talk about code style again, making the workplace safer for people who don't want to spend their time arguing about things that don't matter.
It isn't about saving space. When I ssh into a machine and need to edit a file I use tabs to indent. Those machines usually don't have a vim config deployed and for bash scripts - who cares.
It becomes messed up if you need to edit python files. First check which indendation is used (chances are, that the file was created there, not with an IDE), then use either the tab key (maybe some editor magic makes spaces if spaces are detected for indendation) or space, which makes it more annoying.
In my highly opinionated...opinion it's far easier to transform a tab into 1 space, 2 spaces, 3 spaces or n spaces than to attempt the reverse for coding while still preserving the underlying indentation.
It is maddening that there is even still a "discussion" happening. Tabs for indentation, spaces for alignment. Didn't even get mentioned in the article. All the pros, zero cons. Enough of this. Enough, enough.
"Use tabs for indentation, spaces for alignment: the superior approach. Code is indented and aligned properly, and indentation is flexible. Use spaces for both indentation and alignment: still fine, but not flexible enough. Use tabs for both indentation and alignment: completely unacceptable, leads to headaches."
Since this also happens every time, if you're currently writing a harebrained reply about "mixing tabs and spaces!!!!", you don't understand what's being discussed and should permanently recuse yourself from the conversation.
The problem is that most programmers do not bother to make whitespace visible, so tabs-for-indentation-spaces-for-alignment inevitably leads to a mess of mixed tabs and spaces.
I personally use tabs-for-indentation-spaces-for-alignment in my personal code, but I think I'd lose my mind if I tried to mandate it for a public or team project without a standard code formatter like gofmt.
Even though I'd push for tabs-for-indentation-spaces-for-alignment, I agree with your sentiment.
The "both"-camp is divided in two groups: the "don't care"-group and the "strict rules"-group (the former probably being much larger).
There was a Stack Overflow developer survey in 2017 which concluded that space users make more than tab/both users. Would be interesting to see the results when accounting for above difference in the both group.
That’s lowerCamelCase. CamelCase probably means UpperCamelCase to most people, because it’s what Microsoft standardized on long ago and that’s what so many people learned first.
> Emacs was initially released in 1976 and Vim came much later with its initial release in 1991.
Technically true, but so horribly misleading that I must assume it to be intentional.
You could just as well say that “VI was written in 1976 as a visual version of the older ‘ed’ and ‘ex’ editors, while GNU Emacs was first released in 1985.”
The truth is that both editors have their roots in 1976, got substantial re-writes in the ’80s and ’90s, respectively, and have been actively developed ever since.
The more important (to me) differing factors are things like:
1. Do they follow new developments in computer interfaces?
Emacs got its first graphical version in 1994 (1991 if you count XEmacs, 1985 if you count Zmacs), and keeps improving its graphical fidelity to this day by supporting multiple graphical environments on different platforms (Unix X11, Windows, macOS). While Vim technically has GTK support which adds a menu bar and tool bar, nobody uses it in this way since there is no point; in the main window, it is still is a terminal-style application, same as it was in 1976, with the only addition since then being colors. Compare that to what modern Emacs can look like: (https://www.gnu.org/software/emacs/tour/).
2. Do they get third-party support with packages, extensions, etc?
Emacs has always been very strong here, and modern Emacs has its own packaging system with an app store-style system built-in. From what little I hear about Vimscript, almost nobody uses it, it is not meant for serious programming, and the developers are unsure if it is worth bothering about.
64 comments
[ 4.3 ms ] story [ 142 ms ] threadI don’t mind whitespace-significant languages like Python, but wouldn’t tabs be a better choice? Seems like you can easily get lost after a few levels of indentation, and much more to the point, it seems like tabs are superior because a) your IDE can display them with any width, making it easier to follow long passages with deep indentation, and b) they could free up the editor from requiring a mono space font.
Any thoughts?
this to me is the crucial disadvantage because it baits people with low tab-width into writing deeply nested code, which is usually seen as a bad pattern, and also blows up on the screen on someone using a wider tab-width.
I'm in favour of strong uniform rules. Make it 4 spaces, line width 80 and then everybody lives in the same formatting world.
Yes. Model your language on Python except each level of indent must be exactly one space.
Really?? Let's check...
Just my humble suggestion :)EDIT: no fair downvoting, he said "any thoughts" and I gave some thoughts, with example.
That said, when working with shared code I believe what's more important is "micro-consistency" : the exact style doesn't really matter, as long as it's not so inconsistent that it confuses someone inspecting a function or file. One or ten spaces, or tabs, all applied consistently are far better than things like misleading indentation or mixed tabs and spaces in the same block of code.
http://www.richardrodger.com/2012/11/03/why-i-have-given-up-...
I thought it's worth considering as the syntax solution for a new language! It's fully orthogonal and removes all style decisions. The compiler never has to guess. That actually means the IDE could be fully sure of it in every case and could let you adjust the tabs, as in this example I put together (using excel and a C program):
https://imgur.com/a/s7zQMpw
----
I chose my suggestion based on orthogonality. Originally I started suggesting 2-space tabs for OP's new languages (as a syntax feature), since they're a pretty common style convention used by many in the C world, so not totally absurd.
But that is not fully orthogonal and hard to automate: if the compiler encounters 3 spaces, what is that supposed to be? Automatically a syntax error?
How many indents is 6 spaces again? -- when you use 2-space tabs the answer is 3
With two-space tabs, the answer is 3: but when you use 1-space tabs the same is: You can just count, and it is visually also very clear.As mentioned your IDE can treat leading spaces as indents. (Visually indent them.) It's a 1:1 correspondence.
Anyway just my humble suggestion for tomcam's new language, who solicited ideas with "Any ideas?". I gave actual code snippets in my original comment. :)
I honestly think people prefer spaces because it's hard to get the above right. With spaces, if it looks right, it is right.
(Wow, I can't believe I just argued in favor of spaces.)
I'm a tab person myself. With tabs, those 2-space-loving perverts have no power over me!
So, my suggestion is that we indent with dots '.' .
If you want your language to have a wide range of users, let me tell that I wouldn't chose to use a language that required me to use tabs. I don't care what awesome features it has. It's a dealbreaker.
By the way, your reason "a" is the age-old argument in favour of tab indentation. You're not going to convince anyone that prefers spaces like that. We've all heard it.
However, your reason "b" is just horrid and invalid. I've never heard of a programmer that would prefer to code in variable width font. OMG.
I'm not going to reply further than this. You have to be trolling.
Personally, I don't get nor like the "adjust to taste" tab argument. I routinely look at the same code in multiple editors. Intellij, vim, code reviews, code search tools, git diff output. In the browser and in a terminal.
Don't break my vertical allignment. I don't need it often but when I do I really need it. Functions with long params. Data points in opengl arrays.
One consistent cannonical form. That's where it's at. That's what I want.
Edit: it's worth mentioning that this kind of tooling is extremely important, as reducing the issues that drive religious wars is a priceless sort of feature.
Using tabs for indentation doesn't do that. Using tabs for alignment does that, and virtually nobody wants that, including people who use tabs for indentation. Indentation and alignment are two separate issues. "Use tabs" is shorthand for "Use tabs for indentation", not "Use tabs for indentation and alignment".
Must you? Is there really no existing language sufficient for your needs?
Otherwise, you should be opinionated on this (and language design in general). Use tabs if you like them, nobody with a half decent editor will notice after two minutes of configuration anyway.
1) Your IDE can parse code and reformat it in literally any way you want. This includes indentation width (regardless of whether the code is actually stored using tabs or spaces), but also things like line width, semicolons, string quoting style, etc. (e.g. Prettier for JavaScript), or even using completely different language syntaxes that have the same semantics (e.g. Ocaml and ReasonML).
2) Stylistic code formatting choices, while completely ignored by the computer, are important for humans. Some style choices can have significant effects on engineering quality. The obvious example is variable names, but perhaps a subtler example is that a wide indentation width can discourage deep nesting.
> gofmt's choices are no one's favorite, but gofmt is everyone's favorite.
Here's Black for python: https://github.com/ambv/black
I'm not sure if my future co-workers would kill me or not for using it on projects.
Both points (and more!) can be resolved if the on-disk format is not considered directly the on-screen format. Instead if the on-disk format is considered a serialization of the AST and editors would display it with "just-in-time" formatting based on user-preferences, then that would resolve the tabs vs spaces discussion once and for all.
Incidentally I'm a fan of the concept of structured editing etc.
Personally, I don't get nor like the "just press the space bar 12 times when you want to indent to 3 levels“ argument. I routinely look at different code in the same editor. Someone’s Python code, another open source library’s Javascript code, some abandoned Wordpress theme.
Don't break my horizontal cadence. If I’m used to single-level indentations being 4 characters wide it really throws me off when I’m looking at indentations a single character wide. I have to refactor the entire code just for the step-indentations to be “normal” for me. A tab-indentation on my editor is as wide as I’m comfortable with.
I don’t care what form someone uses. I’m probably selecting all and converting spaces to tabs when I’m working with it. And maybe I’ll program my editor to automatically convert tabs to spaces when I’m uploading to GIT to make everyone happy. That's where it's at.
This sounds like a strawman. Most people who use spaces configure their editor so pressing tab inserts spaces. You don’t have to press space 12 times to indent to 3 levels.
I like my tab bar to actually create real tabs because I actually have my editor show space & tab characters and tabs tell me the intent of the programmer (to indent) better than spaces do.
Tabs are configurable, but configuration is required. You must configure every project for every editor to get reasonable display, which is annoying when possible and even more annoying when impossible.
It's even a little less boring after seeing this. :)
The key thing for gofmt is that it's universal and community backed.
Most bikeshed discussions, especially wrt code style, are excuses for guys to trot out some toxic masculinity in the workplace. They aren't telling you to alphabetise your imports to improve the codebase but to start an argument they think they can win. It leads to a hostile environment.
The reason spaces "are winning" is that tabs are the "live and let live" solution (read the code however you like) and spaces are the totalitarian solution -- "My code must look the same on your screen." Totalitarianism is naturally proselytising.
Thankfully the end is in sight. "Auto-formatters" are the "total control" endgame. They are probably a net drag on productivity, but they come with one incredible upside: nobody need ever talk about code style again, making the workplace safer for people who don't want to spend their time arguing about things that don't matter.
It becomes messed up if you need to edit python files. First check which indendation is used (chances are, that the file was created there, not with an IDE), then use either the tab key (maybe some editor magic makes spaces if spaces are detected for indendation) or space, which makes it more annoying.
"Use tabs for indentation, spaces for alignment: the superior approach. Code is indented and aligned properly, and indentation is flexible. Use spaces for both indentation and alignment: still fine, but not flexible enough. Use tabs for both indentation and alignment: completely unacceptable, leads to headaches."
Since this also happens every time, if you're currently writing a harebrained reply about "mixing tabs and spaces!!!!", you don't understand what's being discussed and should permanently recuse yourself from the conversation.
I personally use tabs-for-indentation-spaces-for-alignment in my personal code, but I think I'd lose my mind if I tried to mandate it for a public or team project without a standard code formatter like gofmt.
The "both"-camp is divided in two groups: the "don't care"-group and the "strict rules"-group (the former probably being much larger).
There was a Stack Overflow developer survey in 2017 which concluded that space users make more than tab/both users. Would be interesting to see the results when accounting for above difference in the both group.
http://nickgravgaard.com/elastic-tabstops/
Technically true, but so horribly misleading that I must assume it to be intentional.
You could just as well say that “VI was written in 1976 as a visual version of the older ‘ed’ and ‘ex’ editors, while GNU Emacs was first released in 1985.”
The truth is that both editors have their roots in 1976, got substantial re-writes in the ’80s and ’90s, respectively, and have been actively developed ever since.
The more important (to me) differing factors are things like:
1. Do they follow new developments in computer interfaces?
Emacs got its first graphical version in 1994 (1991 if you count XEmacs, 1985 if you count Zmacs), and keeps improving its graphical fidelity to this day by supporting multiple graphical environments on different platforms (Unix X11, Windows, macOS). While Vim technically has GTK support which adds a menu bar and tool bar, nobody uses it in this way since there is no point; in the main window, it is still is a terminal-style application, same as it was in 1976, with the only addition since then being colors. Compare that to what modern Emacs can look like: (https://www.gnu.org/software/emacs/tour/).
2. Do they get third-party support with packages, extensions, etc?
Emacs has always been very strong here, and modern Emacs has its own packaging system with an app store-style system built-in. From what little I hear about Vimscript, almost nobody uses it, it is not meant for serious programming, and the developers are unsure if it is worth bothering about.