And so on...
Well, you have to indent anyway, and if you don't it already, you will learn it quickly, because you want (and need) readable code. So, your argument:
It adds an unnecessary extra character to parse and store
doesn't pay off really , neither for you nor the compiler.
And then, you have to close every bracketed code. With a closing bracket. So, at the very end of your function, you are enforced to add (many) closing brackets. Every closing bracket adds a new line typically, blowing up your code. You need more lines and you have to scroll more. Doesn't pay off either.
I accidentally made a misleading title, sorry (can't edit it now). The title should have been "Why spaces instead of tabs?".
Getting rid of brackets is fine. Brackets are a cause of a lot of inconsistencies, especially when it comes to placing the bracket on the same line or the next line.
But so are spaces. Especially if it's true that any number of spaces are supported. Why support this instead of just forcing one tab per indent level? One can hope that people agree on some standard in space count, but without forcing anything, code from different sources become inconsistent.
"Why spaces instead of tabs?"
There are two valid reasons for spaces:
myproc(
a: int;
b: float
) =
This formating scheme would not work with tabs.
And github inserts 8 spaces for a tab, which looks bad.
For me both arguments are not really convincing, so I would prefer tabs for indenting (only tabs, mixing tabs and spaces for indenting must be forbidded of course.)
Tabs can become a nightmare if you happen to be forced to use a tool (e.g. a debugger) that uses a different tab width than you editor/IDE. For example, many tools use a tab width of 8 (which is the default tab width for HTML) which is far too wide for indentation.
This is not an issue as long as you stay within you IDE, but then you can configure you IDE to convert tabs into spaces automatically.
"Tabs are configurable for personal preference" - Some people seriously seem to suggest that within the same team different people use different identation widths by configuring different tab widths. To me this is just a crazy idea.
Yeah when I say tabs i mean tabs exclusively. My point is to completely forbid spaces for indentation in any case, and always use one tab for one indent level.
Github really needs a way to adjust tab size, or at least default it to something reasonable. As for now, you can add an .editorconfig in your project root with the following contents which will set the tab size straight:
root = true
[*.cs]
indent_style = tab
indent_size = 4Tabs can become a nightmare if you happen to be forced to use a tool (e.g. a debugger) that uses a different tab width than your editor/IDE. For example, many tools use a tab width of 8 (which is the default tab width for HTML) which is far too wide for indentation.
8 tab width is far too wide. I agree. This is why most tools allow for configuring the width. This is a fault of the tool, not the character.
This is not an issue as long as you stay within your IDE, but then you can configure you IDE to convert tabs into spaces automatically.
How many spaces though? 4 spaces? 2? I've even talked to a highly skilled programmer who use 3 spaces. You're going to have a git problem if people start converting your codebase to different space counts and don't convert back to tabs.
"Tabs are configurable for personal preference" - Some people seriously seem to suggest that within the same team different people use different indentation widths by configuring different tab widths. To me this is just a crazy idea.
As crazy as different people using different color themes for their IDE.
I think this summarizes my main beef with this issue. Basically Guido says he prefers tabs, and would use tabs, but the community got angry with him. I think this is what I am experiencing right now.
Congrats, you just managed to show the evidence of Wadler's Law (imposed in 1992)
https://wiki.haskell.org/Wadler%27s_Law
and the ongoing discussion is somewhat in between pt. 2: "Lexical syntax" and pt.3: "Lexical syntax of comments" ...
Well, an exclusive indent char might be nice, but TAB is very easy for almost everyone to enter by default already. Used the way @Tutbadut and @Araq were discussing only at the beginning of lines ('^TAB*[^TAB]' in Regex-ese) it could function that way. It's true that a brand new character might side-step the diverse ways to configure the amount of rendered blank space per tab, but at the non-zero cost of mandating unicode.
While source code "in the large" is not tabular data, in a leading-whitespace-for-block-structure language like Python or Nim, that part of the text has "regimented spacing concerns" much like a table. TAB characters of any fixed width are actually less useful for tables than the old early 20th century mechanical typewriter tab-stops that inspired the TAB character. Tab-stops were totally configurable - first at 4, next at 8, next at 10 or 20, etc. That flexibility was largely lost in the transition to ASCII-oriented software. { You think one conversion ratio is a pain in the ass...try dozens! ;-) }
Anyway, detecting the very first '^[some-kinda-white]' and mandating whole-file consistency afterward seems "not so hard", especially if you allow comment-only lines as candidate leading white-space determiners. In spite of not being so hard, most text editors punt on it, only doing line-global/file-global type transformations leading to Araq's observations. It would be a really easy CLI text filter to do leading-space only..probably less work than reading this whole thread and also of value to non-.nim files. Probably exists already, too. Using hard tab for leading indent only and letting divergent users adjust as they like seems philosophically much like Nim's style insensitivity, only with far more common environmental support for tunable rendering.
The only real problems are defaults of 8-spaces per TAB being 4x more than what Nim people are used to and diversity/unavailability of TAB size setting. Combined that creates trouble for the many to please the few. I'm pretty sure the diversity/unavailability of adjustment/having to tell Python TAB-size conversion complexity was what led to Guido's regret, mixed in with some Wadler's Law can't-believe-we're-arguing-about-it.
Anyway, just food for thought. I'm not really advocating anything.
I'm really tired of these tabs vs. spaces discussions.
There are good reasons for either approach, and I don't see why one approach would be objectively better than the other.
People who prefer the pro/con combination of tabs over the pro/con combination of spaces, prefer tabs.
People who prefer the pro/con combination of spaces over the pro/con combination of tabs, prefer spaces.
It's subjective.
My recommendation is to follow a project's existing approach or, if you start a new project, the "community standard" approach (two spaces per indent for Nim). I think there are really more important things to discuss than tabs vs. spaces. (Yes, it's ironic that I still took the time to write this reply. ;-) )
I dont like at all when I get this answer myself but ...
Nim is open source with MIT license. If you cant live without tabs, fork it.
From several decades of experience, tabs eventually always cause the (potential) problems, but only rarely deliver the (potential) benefits.
For the people who can't live without them, Nim provides https://nim-lang.org/docs/filters.html ; an #? expandTabs(tabwidth:int) filter can easily be written. Personally, I think it's a bad idea and would recommend against including such a filter in the standard library.