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

121–129 of 129 posts

Re: Tabs slower than spaces in Firefox

#121

Post by minitech »

sethish wrote: post #76
js2 wrote: post #71

Earlier quoted context omitted.

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…

In an argument of tabs vs spaces. Someone always says both. You are that person.

But the argument really is both vs. spaces. Anyone using tabs for alignment is doing it wrong.

Re: Tabs slower than spaces in Firefox

#122

Post by 6t6t6t6 »

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.

A supposed genius programmer who can have an argument for such a silly question.

Besides, why people don't use linters?

Re: Tabs slower than spaces in Firefox

#123

Post by exadeci »

donny2015 wrote: post #104
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.

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

You just don't get it, it's not supposed to depict programmers in the Silicon Valley.

It's a comedy, that makes fun of the stuff happening in the Silicon Valley by strongly exaggerating it.

On a side note, geniuses are know to have unusual quirks.

Re: Tabs slower than spaces in Firefox

#124

Post by marssaxman »

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 use tabs for indentation. I don't desire or care about column alignment. Code that has carefully-laid-out column alignment feels bizarrely fiddly to me - it's like the fad for absurd giant ASCII boxology comment headers back in the late '80s. Why bother? What's it adding?

Re: Tabs slower than spaces in Firefox

#125

Post by [deleted] »

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…

[deleted]

Re: Tabs slower than spaces in Firefox

#126

Post by yoklov »

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…

Lets say you've thrown away the ast, don't have a token stream, etc, but do still have access to the source of the function. Getting the function length is O(1). At worst, its a subtraction. Lexing it is considerably more expensive, and doing so just to improve the heuristic may not be worth the time.

Re: Tabs slower than spaces in Firefox

#127

Post by chriswarbo »

Stratoscope wrote: post #113
chriswarbo wrote: post #70

Earlier quoted context omitted.

> 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; } }

Now that is an interesting approach! So you're lining up the dots? I like the creative thinking, even if I don't like the end result. A couple of problems I see here: What happens if you have more than one dot, like foo.bar.method()? Which dots do you line up? And note that the else isn't aligned with its matching if. I suppose another alternative would be to line things up like this: if( foo == bar ) { if( baz == mo…

> To me, this is one of the fundamental problems with column alignment: once you start doing it, it's too easy to start fiddling with all of the possible things you might align. And it really doesn't help the reader visualize the code structure except in the simplest cases.

I certainly agree that it can cause problems, e.g. with diffs, extraneous decisions, etc.

I only tend to do it when there's commonality between the lines (more than trivial ones, like "there's a dot"); e.g. aligning the "=" in a bunch of assignments, aligning the arguments in calls to the same function, etc.

> Also, you're in for a maintenance headache when someone changes foo to moreMeaningfulName. Now what? Move everything farther to the right?

I tend to follow the following process:

- Preserve the existing alignment (e.g. "move everything over")

- If any lines grow longer than 80 characters, split them

- If any already-split lines shrink to less than 80 characters, remove the split

- If you spot a nicer pattern, try it

- If there's no pattern anymore, "fall back" to not doing any alignment; consider inserting blank lines if the statements are very different or the lines are very dense

I've thought a few times about making an auto-layout script, which would run files through a language-agnostic "nicely aligned" fitness function, and make a bunch of language-specific semantics-preserving edits to try and maximise this score. It's quite low on my TODO list though ;)

Re: Tabs slower than spaces in Firefox

#129

Post by Klathmon »

skykooler wrote: post #128
Klathmon wrote: post #90

Earlier quoted context omitted.

well a newline is the same amount of bytes!

Newlines and semicolons aren't always interchangeable in Javascript.

the only situation they aren't is when a line starts with a [ or a (

In every other scenario, a newline and a semicolon are interchangeable.

Post reply on HN