Tabs slower than spaces in Firefox • Hacker News Board

Re: Tabs slower than spaces in Firefox

#71

Post by js2 » Tue, Jul 19, 2016, 12:35 PM UTC

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…

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 which point the tabs buy you nothing.

So just use spaces and be done with it. Or go fmt. :-)

Re: Tabs slower than spaces in Firefox

#72

Post by __s » Tue, Jul 19, 2016, 12:42 PM UTC

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…

As a tab person, I don't line up code. Each line may decide to unindent, indent, or maintain indentation

Here's some Befunge interpreters in a few different languages: https://github.com/serprex/Befunge

Re: Tabs slower than spaces in Firefox

#73

Post by kazinator » Tue, Jul 19, 2016, 12:45 PM UTC

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 their second year of school. A function isn't larger if we give it wider indentation with more spaces, or replace its local variables with ones having longer names.

Re: Tabs slower than spaces in Firefox

#74

Post by mikegerwitz » Tue, Jul 19, 2016, 12:47 PM UTC

minitech wrote: post #58

andrewfong wrote: post #38

Earlier quoted context omitted.

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.

I think that depends partially on the verbosity of the programming language (e.g. type declarations, casting, templating) which eat up a lot of columns, and verbosity of coding style. In the latter case, if your variable names are `name_of_person' rather than simply `name' (which should be obvious by context), you're also going to have problems.

The first one might be a legitimate issue. The second issue, I've noticed, I've never had a problem with, even in heavily indented lisp:

- If your variable names are too long, they must not be obvious from context, and your function/method/block is doing too much. Refactor.

- Consequently, if the line is too long, perhaps it's doing a little too much; short lines with limited logic help with code comprehension the same way short methods do. Splitting code into multiple lines generously allows you to clearly indicate how parts relate to one-another.

My line width is 76 characters max to allow for 3 columns for line numbering + one space after it---if line numbering requires more columns that that, maybe your file's too big as well. Some will disagree on that last point, but I consider that in the same light as I do line length and function size. For OOP especially where there's one class per file, it's certainly a code smell if you have a long file.

Re: Tabs slower than spaces in Firefox

#75

Post by Klathmon » Tue, Jul 19, 2016, 12:59 PM UTC

mhomde wrote: post #59

onion2k wrote: post #23

Earlier quoted context omitted.

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

While I agree in some senses, i'm terrified of this idea in others.

A business-basic style language i work with (second time i've talked about it in a few days... it's weird) saves it's files in a strange not-compiled-but-not-plaintext format that only it can read. That means you can't use your VCS of choice, you can't use your favorite editor, you can't even grep through the codebase to find where a variable name is used.

Technically you could write something to get it working in a more "normal" editor, but that is a path I don't want to run down.

Ignoring encoding, text is about as accessible as it gets. You can always layer more tooling on top of it, but you can't take it away from a non-text representation easily.

Personally I like the way that the go team handles it. Source files are "plaintext" (again, ignoring encodings for the sake of discussion), but there is one (and only one) canonical format for the layout of the code, and a tool which will apply it.

Then like you said, you can have IDEs which can layer more visual representations on top of that if needed, and there is a chance that some people could program without actually seeing the "plaintext" source code.

Re: Tabs slower than spaces in Firefox

#76

Post by sethish » Tue, Jul 19, 2016, 1:00 PM UTC

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…

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

Re: Tabs slower than spaces in Firefox

#77

Post by Klathmon » Tue, Jul 19, 2016, 1:07 PM UTC

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 things like strip comments, whitespace, and other "simple" things, but is it really worth the extra cycles?

With minifiers and compilers in such large usage, a check like that would most likely just waste CPU time in the vast majority of cases, not to mention the extra developer time spent in the engine.

That being said, i'm pretty sure this exact instance is a bug.

Re: Tabs slower than spaces in Firefox

#78

Post by yAnonymous » Tue, Jul 19, 2016, 1:10 PM UTC

scrollaway wrote: post #51

yAnonymous wrote: post #47

Earlier quoted context omitted.

"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 qu…

It's more like new editors ship with spaces as default, because most style guides recommend it.

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

It seems you're the vocal minority: https://ukupat.github.io/tabs-or-spaces/

Re: Tabs slower than spaces in Firefox

#79

Post by slavik81 » Tue, Jul 19, 2016, 1:12 PM UTC

yoavm wrote: post #22

th0br0 wrote: post #16

Earlier quoted context omitted.

Tab width can vary between editors, i.e. do a "set shiftwidth=8" in vim, and it'll be 8 spaces. Spaces are more constant.r

I have to admit I always thought of that as an advantage of tabs, since they allow the viewer to set how much to indent the code, and doesn't force anyone to adapt to someone else's preferred style. I like it when a tab = 4 spaces, but you like it when a tab = 2 spaces. Cool, just set your editor accordingly.

Unfortunately, it also means that if the viewer hasn't or can't set the tab width, it may look awful. GitHub was using 8 spaces per tab by default, and my code looked ridiculous. Now GitHub checks .editorconfig for a default tab width, but it didn't used to.

Re: Tabs slower than spaces in Firefox

#80

Post by yAnonymous » Tue, Jul 19, 2016, 1:19 PM UTC

Stratoscope wrote: post #48

yAnonymous wrote: post #47

Earlier quoted context omitted.

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

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

That doesn't make them right, but I'd like to know how you came up with the "many of us" in the first place, because there are far more developers who use spaces (https://ukupat.github.io/tabs-or-spaces/), and it's not even close.