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

51–60 of 129 posts

Re: Tabs slower than spaces in Firefox

#51

Post by scrollaway »

yAnonymous wrote: post #47
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…

"Many of us" - you are using that way too often in your posts and it's a pseudo argument. Fact is, you're giving up the choice of different coding styles to make something broken work. "Many of us" prefer spaces for that reason and that's why it has become the de facto standard.

> "Many of us" prefer spaces for that reason and that's why it has become the de facto standard

Has it? I wasn't informed. I know it has in the Python community, because of pep8 mainly, but a lot of communities have settled on tabs (Lua for example, and for a long time PHP until recently).

I'll paste here what I replied to someone off-thread, regarding "why" anything ever becomes a de facto standard.

> I would bet quite a bit that personal indent preferences are driven by whatever the default is on the editor of choice of the person in question. I would equally bet that you can correlate the tab defaults on editors/IDEs widely used in specific communities (Visual Studio for Windows C-family stacks, PyCharm for python, Eclipse and its little family for java, etc) and the general preference of that community.

Chicken and egg problem. Spaces aren't standard because they're preferred; they're preferred because they're standardized by editor defaults. Developers that don't have a particular preference grow into those defaults.

Re: Tabs slower than spaces in Firefox

#52

Post by Stratoscope »

piaste wrote: post #46
scrollaway wrote: post #19

Earlier quoted context omitted.

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…

for example, it creates git blame/git diff noise when reformatting due to having to update alignment on a bunch of other lines just because you introduced a variable one character longer than the others. If you're working with git on a non-whitespace-sensitive language, and this annoys you, you can use the --ignore-space-change option to avoid this.

That is certainly true! But the problem is I don't want to ignore whitespace changes when I review my diffs. If I do that, I'm very likely to introduce inadvertent whitespace changes that will annoy everyone I work with. :-)

Re: Tabs slower than spaces in Firefox

#53

Post by Stratoscope »

andrewfong wrote: post #38
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)

How do tab advocates deal with max column widths? Many projects require that lines not exceed 80 chars, but I'm not sure how'd you establish that kind of limit with variable length tabs.

That's a very reasonable question to ask.

I suspect that it isn't much of an issue in practice for a few reasons:

1) I'd wager that most projects that have a hard 80-column limit also forbid tabs.

2) If a project does use tabs and has a hard line length limit, it can simply say that that limit is interpreted using a certain tab size (e.g. the most common tab size is probably 4 spaces).

3) In my own code, as I've mentioned probably too many times in this thread :-) I don't use column alignment, which is one of the main causes of excessive line length. Because I use indentation for multiline expressions, my lines of code tend to be a lot shorter than they would be with column-aligned expressions.

Re: Tabs slower than spaces in Firefox

#54

Post by scrollaway »

saucetenuto wrote: post #50
girvo wrote: post #41

Earlier quoted context omitted.

EditorConfig or various other configuration setups allow your editor/git/whatever to read a tab as if it is "n" spaces, where that is somewhat configurable. Using EditorConfig, this allows consistency across tooling, and solves this problem neatly (at least in this particular use-case, YMMV in other places where this isn't possible or desirable).

Suppose I have a configured tab width of 2 and I write a line with three tabs that's 78 characters wide. When my friend with tab-width 8 views it, he'll see a line that's 90 characters wide. What do projects with 80 character limits do in situations like that? In either case the line contains only 75 characters, of course, but that's a pretty pedantic non-answer: we care about horizontal screen space, not the number…

EditorConfig tells you the canonical tab size for the project, in other words "a tab counts as 4 characters to the soft wrap". If you choose to increase the tab size beyond 4 characters, you have to accept you'll get longer lines.

(It's also high time we stop pretending wrap limits matter to the exact character. In most cases, they are and should be guidelines - we have evolved beyond 640x480 CRTs and 80 character terminals)

Re: Tabs slower than spaces in Firefox

#55

Post by Stratoscope »

efaref wrote: post #44
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)

Tabs make no sense to me as they're clearly control codes. I maintain that if tabs are permitted, so are other ASCII control codes, like vertical tab, form feed (which is actually used in GNU code), and bell. int foo(void) { /* This bit is really important. */ ... } int blah(void) { ... } :-)

Careful, my friend. Strawmen are highly flammable. ;-)

But I like your sense of humor, so you definitely earned an upvote from me - a flaming tab advocate!

(And I learned to program on a ASR33 Teletype - so I do miss those old control codes...)

Re: Tabs slower than spaces in Firefox

#56

Post by akerro »

yoavm wrote: post #15
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…

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)

This is interesting. Why do we use spaces anyway? I mean, really - what are the advantages spaces have over tabs?

Apparently nested JS runs faster with spaces.

Re: Tabs slower than spaces in Firefox

#57

Post by Asooka »

efaref wrote: post #44
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)

Tabs make no sense to me as they're clearly control codes. I maintain that if tabs are permitted, so are other ASCII control codes, like vertical tab, form feed (which is actually used in GNU code), and bell. int foo(void) { /* This bit is really important. */ ... } int blah(void) { ... } :-)

Why not go all the way? Use Start of Header before your require/#include/import/etc. then Start of Text when your code proper starts. Replace ifs with ENQ, thens with ACK and elses with NAK. You can build an entire language where all the keywords are just ASCII control codes. That will free up all the punctuation for other purposes, and you could name your variables if, for, while, etc.

Re: Tabs slower than spaces in Firefox

#58

Post by minitech »

andrewfong wrote: post #38
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)

How do tab advocates deal with max column widths? Many projects require that lines not exceed 80 chars, but I'm not sure how'd you establish that kind of limit with variable length tabs.

Personally: by not enforcing maximum widths. Having a fixed limit makes for ugly workarounds and looks horrid if you happen to be viewing at a narrower width. Just wrap code where it makes sense to do so.

Re: Tabs slower than spaces in Firefox

#59

Post by mhomde »

onion2k wrote: post #23
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…

I've never quite understood why lots of IDEs don't convert a file to your preferred variation of tabs or spaces when you open a file, and then convert it back again when you save it. On disk the indentation could be one thing while in the editor it's something else. That way everyone's happy.

I think the whole notion of programming language as pure text and even using "files" as a unit is veering towards obsoletion. We do it that way because that's the way it's always been done, but I can see plenty of cases where an IDE that uses a more hybrid graphical approach would be beneficial, and we wouldn't have arguments like this :)
Post reply on HN