Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tabs slower than spaces in Firefox

bugzilla.mozilla.org

Post reply on HN
Print view View original

101–110 of 129 posts

Re: Tabs slower than spaces in Firefox

#101

Post by betenoire »

scrollaway wrote: post #19
yoavm wrote: post #15

Earlier quoted context omitted.

This is interesting. Why do we use spaces anyway? I mean, really - what are the advantages spaces have over tabs? (I use spaces only because I try to follow common coding styles, like PEP 8, but I never gave it enough thought)

One of the main drivers for spaces is alignment, which you should never attempt to do with tabs (except in contexts which normalize tabstops, which generally excludes programming). Aligning within a line can and should be done with spaces. There's good reasons against alignment in such cases -- for example, it creates git blame/git diff noise when reformatting due to having to update alignment on a bunch of other lin…

my opinion:

The second is better looking. I'd rather maintain the second.

But...

The first is easier to read. The shape of the code is enough for me to parse without effort. In the second, I have to "walk myself" through the code, even for this little example. I feel the effort required as soon as I have to start looking for the embedded commas.

So I usually choose something like the first, since time spent typing matters less than time spent thinking.

Re: Tabs slower than spaces in Firefox

#102

Post by scrollaway »

chriswarbo wrote: post #96
scrollaway wrote: post #83

Earlier quoted context omitted.

That is no semantically no different to #2 so I'm not sure why you think it's a strawman seeing as you just agreed with me. While, like I said, there's reasons against alignment within lines, using tabs doesn't prevent you from doing it.

I meant that aligning columns is orthogonal to breaking up long lines; you can do either, both, or neither, so your example comes across as a strawman.

This isn't about breaking up long lines. The second indent style results in shorter lines, that is one of the various side effects which makes it superior. My example was meant to display that start-of-line alignment is generally a poor idea and there are better alternatives... which you seem to understand just fine.

Re: Tabs slower than spaces in Firefox

#103

Post by mixedCase »

js2 wrote: post #71
scrollaway wrote: post #14

Earlier quoted context omitted.

Poe's law and all, I hope your comment isn't serious. The whole point was to highlight Richard's "neurotic" side. (It failed to convey it for me when his girlfriend started audibly indenting by hitting the spacebar 8 times... I'd go nuts, who wouldn't?) Also, plenty of geniuses use tabs :) the Linux kernel included. It obviously has no relation. (Seriously though, tabs are a matter of accessibility. https://leclan.ch…

If the tab people would reliably use tab for leading indent and space for further alignment, I'd be 100% on board. But what happens in practice is that the file ends up with a mish-mash of tabs and spaces throughout and the file is only legible if you set your tab stop to a specific setting, and sometimes not even then because different authors have used different tab stops for both indentation and alignment. At whic…

>If the tab people would reliably use tab for leading indent and space for further alignment, I'd be 100% on board.

There is no other way to do tabs. Anything else is simply wrong and grounds for execu... a stern talking-to.

Re: Tabs slower than spaces in Firefox

#104

Post by donny2015 »

drewrv wrote: post #10
peterkelly wrote: post #3

I'm going to use this as fodder next time I get into an argument with someone about why spaces are better than tabs when writing code. Or maybe I've just been watching too much silicon valley...

I thought that was the most unrealistic thing this season: a supposedly genius programmer who loves tabs and hates spaces.

Just because of this I knew the whole show was BS.

Re: Tabs slower than spaces in Firefox

#105

Post by donny2015 »

js2 wrote: post #71
scrollaway wrote: post #14

Earlier quoted context omitted.

Poe's law and all, I hope your comment isn't serious. The whole point was to highlight Richard's "neurotic" side. (It failed to convey it for me when his girlfriend started audibly indenting by hitting the spacebar 8 times... I'd go nuts, who wouldn't?) Also, plenty of geniuses use tabs :) the Linux kernel included. It obviously has no relation. (Seriously though, tabs are a matter of accessibility. https://leclan.ch…

If the tab people would reliably use tab for leading indent and space for further alignment, I'd be 100% on board. But what happens in practice is that the file ends up with a mish-mash of tabs and spaces throughout and the file is only legible if you set your tab stop to a specific setting, and sometimes not even then because different authors have used different tab stops for both indentation and alignment. At whic…

I wonder what's wrong with people today. Just use spaces, any descent text editor inserts 4 or 2 spaces on pressing tab, and nobody has any problem.

Re: Tabs slower than spaces in Firefox

#106

Post by kazinator »

astrodust wrote: post #100
kazinator wrote: post #87

Earlier quoted context omitted.

> parse the text slightly differently depending on if it is being inlined or not Any frosh should recognize that as a language design/implementation smell by their third year. > most javascript engines do this That somehow falls short of being convincing that it's right.

The reason most JavaScript engines do it is because they have three or four ways of executing code that are all intended to offer maximal performance under different circumstances. If it takes longer to compile a function than to simply interpret it, don't bother compiling. If it's called frequently, compile it. Your academic view of compilers work has no bearing on how ugly and complicated reality is.

> Your academic view of compilers work ...

I didn't write anything about compilers. Scanning tokens isn't compiling. Even old line number BASIC in 1981 running on 1Mhz computers with 32Kb RAM at tokenized code as it was entered into memory.

Re: Tabs slower than spaces in Firefox

#107

Post by scrollaway »

chriswarbo wrote: post #70
Stratoscope wrote: post #43

Earlier quoted context omitted.

> So you're trying to dictate a coding style to make up for tabs' weaknesses? Not in the slightest. The disadvantages of column alignment have nothing to do with whether you use tabs or spaces. I don't recall for sure, but I think I was using spaces for indentation at the time that I stopped using column alignment. Column alignment has the same problems if you indent with spaces: it leads to excessive line length, it…

> If the column-aligned way of writing a multiline function call or expression is such a good thing, why don't we also format blocks of statements this way: I don't see any reason not to. Your example is pretty ugly though, as it's not particularly aligned. What about: if( foo == bar ) { if( baz == moo ) { console.log( "yes" ); this.that = true ; } else { console.log( "no" ); this.that = false; } }

Why are you doing character-based right-alignment in a LTR script?

It breaks with proportional fonts, and... well, if we wanted to right-align things in code, our non-document editor would probably support it by now, don't you think?

Re: Tabs slower than spaces in Firefox

#108

Post by astrodust »

kazinator wrote: post #106
astrodust wrote: post #100

Earlier quoted context omitted.

The reason most JavaScript engines do it is because they have three or four ways of executing code that are all intended to offer maximal performance under different circumstances. If it takes longer to compile a function than to simply interpret it, don't bother compiling. If it's called frequently, compile it. Your academic view of compilers work has no bearing on how ugly and complicated reality is.

> Your academic view of compilers work ... I didn't write anything about compilers. Scanning tokens isn't compiling. Even old line number BASIC in 1981 running on 1Mhz computers with 32Kb RAM at tokenized code as it was entered into memory.

The JavaScript VM is a lot more complicated than a compiler, it's a compiler, an interpreter, and a whole heap of hacks to squeeze maximal performance out of it.

That there's a problem processing whitespace isn't a reflection on the team not knowing their stuff, it's a problem that will be corrected. It's likely something that was never benchmarked and proven to be an issue before, or if it was an issue it was a low-priority one.

Re: Tabs slower than spaces in Firefox

#109

Post by Stratoscope »

chriswarbo wrote: post #96
scrollaway wrote: post #83

Earlier quoted context omitted.

That is no semantically no different to #2 so I'm not sure why you think it's a strawman seeing as you just agreed with me. While, like I said, there's reasons against alignment within lines, using tabs doesn't prevent you from doing it.

I meant that aligning columns is orthogonal to breaking up long lines; you can do either, both, or neither, so your example comes across as a strawman.

By definition, scrollaway's example is not a strawman, because the first version matches the way I've seen code formatted very many times.

(I wonder if this why your comment got downvoted? FWIW, I upvoted you for engaging in the discussion.)

Personally, I would do his second example like this:

  function() {
      nested_code() {
          some_very_long_function_call(
              long_argument_one,
              long_argument_two,
              long_argument_three,
              long_argument_four,
          );
      }
  }
In other words, once I get to the point of splitting up the call into multiple lines, I generally split all the arguments onto their own lines.

Now all the arguments are lined up with each other, as they are in your example. This matches how I format multiline statement blocks: if I'm splitting the code to multiple lines, then I split it consistently on each argument. This way I don't have to worry about how many arguments fit on a single line.

Of course I'm not entirely consistent about this. :-) Take a function like CreateFile() in the Windows API. It has so many parameters, and you're likely to pass in NULL or 0 for so many of them, that it makes sense to bunch them up a bit to not use so many lines.

But even then I wouldn't start adding extra spaces within a line to make vertical columns out of it.

Re: Tabs slower than spaces in Firefox

#110

Post by asQuirreL »

nerdponx wrote: post #49
asQuirreL wrote: post #32

Earlier quoted context omitted.

In vim, adding the following to your .vimrc should do it: inoremap

Or just `set expandtab`...

That would be more like

  inoremap
The request was: when I press two spaces, I want a tab character to be inputted. I agree that if you want `n` spaces when the tab key is pressed, you should use `expandtab` and `shiftwidth`.
Post reply on HN