Hacker News Reader

Comment by tomcam | Hacker News Reader

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.

Any thoughts?

View on HN

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.

The point is if you use tabs, the different text-editora which you may need to use foe various specialised tasks can display it differently.

> Don't break my vertical allignment.

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".

I get the idea, but if I'm dealing with invisible whitespace characters next to each other it's already gone too far.

Tabs for indentation, spaces for alignment.

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!

Yeah. You know, I'm a tabs live well, but the amount of time fighting indentation/alignment with tabs/spaces is longer than just with spaces.

So, my suggestion is that we indent with dots '.' .

>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.

How this would pass code review before submit?

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.

Can always go the `gofmt` route and provide something in the language tooling and take this choice somewhat out of the developer's hands.

> gofmt's choices are no one's favorite, but gofmt is everyone's favorite.

I would go further than that and only allow single formatting style in the language at all. Make inconsistent/non-standard formatting a syntax error.

I love that concept, but it turns out to be kinda difficult in many languages that weren't designed around the concept.

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.

I love black. I hooked up blacken-mode for Emacs and never looked back. The best choice is not having to decide at all!

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.

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.

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.

> 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.

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.

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.

Golang is not better than every other language in every single detail, yet gofmt uses tabs...

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".

>Any thoughts?

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.

http://www.richardrodger.com/2012/11/03/why-i-have-given-up-...

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):

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

  //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. :)

One space indenting makes nested if statements and nested for loops a pain to read. Especially in long functions.

Have you tried it? For how long? (Or on how much code, if you just tried a small snippet.)

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.

What’s the non-sequitur? I was simply addressing your comment that you must “press the space bar 12 times when you want to indent to 3 levels“.

If you're hitting the spacebar more than once, you're using the wrong IDE.

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.

Tabs are better, yes, for the reasons you stated. But people have too much difficulty using them correctly so we have to make do with spaces.

Seriously?

> I’m developing yet another language

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.

Reply on news.ycombinator.com