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

81–90 of 129 posts

Re: Tabs slower than spaces in Firefox

#81

Post by Confiks »

scrollaway wrote: post #14
drewrv wrote: post #10

Earlier quoted context omitted.

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

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…

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

I remember when I got into coding Runescape autoclick bots when I was 14, in an arcane Delphi editor / standard library called SCAR, it was the insane convention to not use any indenting at all. Indeed you had to manually hit the spacebar again and again to get some proper indenting.

Also, the spacebar key on my keyboard was noisy.

Re: Tabs slower than spaces in Firefox

#82

Post by mrcsparker »

Freak_NL wrote: post #25
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)

The common argument is that with spaces the indent is the same in not only every editor, but also every tool used, such as cvs, diff, patch, build tools, web viewers (e.g., for your cvs tool, issue tracker, and/or code review), shell tools (e.g., less and cat), et etcetera. With tabs you need to configure each and every tool you use to use the right indent (2? 4? 8?), with spaces, every tool just works, and copy/past…

With tabs, everyone gets to use their own indent. It is a lot more portable from programmer to programmer.

Re: Tabs slower than spaces in Firefox

#83

Post by scrollaway »

chriswarbo wrote: post #69
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…

> Take a look at the following code and tell me which method looks better: That seems like a strawman to me. I would go with something like: function() { nested_code() { some_very_long_function_call( long_argument_one, long_argument_two, long_argument_three, long_argument_four, ); } }

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.

Re: Tabs slower than spaces in Firefox

#84

Post by dzhiurgis »

Confiks wrote: post #81
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…

> 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? I remember when I got into coding Runescape autoclick bots when I was 14, in an arcane Delphi editor / standard library called SCAR, it was the insane convention to not use any indenting at all. Indeed you had to manually hit the spacebar again and again to get some proper indent…

Autorune was better though :)

Attack(0) would attack yourself in wilderness, leaving bystanders confused.

Re: Tabs slower than spaces in Firefox

#85

Post by scrollaway »

yAnonymous wrote: post #80
Stratoscope wrote: post #48

Earlier quoted context omitted.

Your point about my overuse of "many of us" is a good one, so I changed it to "I" in the comment you just replied to. Fair enough? But look, my real point here is that column alignment is detrimental in several ways, and indentation is a better way to illustrate your code structure - both for statements and expressions. Using indentation instead of column alignment isn't a workaround for anything - it's just a more p…

I see the points for VCS and non-monospace fonts, minor as they may be, but readability is absolutely a matter of choice. While we're on the matter of user prefereces and numbers: Most style guides recommend spaces as lined out in my other post. >Google, Microsoft, Apache and NASA for C-family languages, Crockford and almost every other web-related style guide I've ever seen recommend the use of spaces. Apple is a no…

"Many of us" doesn't imply "a majority of us". This statement isn't contradictory and is backed up by the data you linked: "Many of us use tabs. Many of us use spaces. Some of us use form-feed.. bloody nutters!"

Re: Tabs slower than spaces in Firefox

#87

Post by kazinator »

Klathmon wrote: post #77
kazinator wrote: post #73

Anyone who makes a language in which the performance of a call to previously processed code depends on its original whitespace should immediately be stripped of their CS degree, if they even have one. If some decision depends on the size of a function, that size should be measured over the parsed code: number of nodes in the abstract syntax tree or whatever. This should be obvious to everyone by around the end of the…

Now it's been a bit since I last read about this a bit so forgive me if i'm off by a lot, but i'm pretty sure most javascript engines do this. The reasoning is that they will parse the text slightly differently depending on if it is being inlined or not (potentially skipping steps if possible to speed the process up), so the heuristic needs to happen before the parsing step. Yeah, you could add in some checking to do…

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

Re: Tabs slower than spaces in Firefox

#89

Post by Klathmon »

kazinator wrote: post #87
Klathmon wrote: post #77

Earlier quoted context omitted.

Now it's been a bit since I last read about this a bit so forgive me if i'm off by a lot, but i'm pretty sure most javascript engines do this. The reasoning is that they will parse the text slightly differently depending on if it is being inlined or not (potentially skipping steps if possible to speed the process up), so the heuristic needs to happen before the parsing step. Yeah, you could add in some checking to do…

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

You can say how it's design smell all you want, but do you have any reasons why?

This is a JIT, optimizations like this can (and do) have some pretty big impacts on the speed of the execution without needing a long warmup which is extremely important for a language like javsacript. And in doing so it needs to balance battery usage, startup performance, "hot" performance, and a ton of other things. Its easy for you to stand back and say "that's dumb", but optimizations are often messy, and without them the language would run much slower.

> That somehow falls short of being convincing that it's right.

That's why I tried to provide other reasons why I think it's right...

Post reply on HN