Earlier quoted context omitted.
Tabs require 2 set bits. Space requires only a single set bit. Spaces therefore requires less electricity.
Well, just a bit...
lol
PR that converts the TypeScript repo from namespaces to modules
131–140 of 204 posts
Re: PR that converts the TypeScript repo from namespaces to modules
#132Earlier quoted context omitted.
"Tabs vs spaces" is often misunderstood (and falsely reported) as a problem of preference. The real problem is that using spaces for indentation is an accessibility issue. The solution is to use tabs for indentation, and spaces for alignment.
Why would you ever mix them?! Even when I started programming 15 years ago it was already accepted wisdom that that was a terrible idea.
This is one of those things that started out as good advice, and then got turned in to an oversimplified parody of the original argument.
If you have something like:
var (
x = foo
other = bar
)
coolFun(arg1,
arg2)
->coolFun(arg1,
-> arg2)
--->coolFun(arg1,
---> arg2)
------->coolFun(arg1,
-------> arg2)
The problem is when you start doing stuff like:
if (one) {
------>if (two)
bar();
------>else
xxx();
}
That's what people mean with "don't mix tabs and spaces", not "if you use tabs then the space shall never appear in the file under any condition".
Re: PR that converts the TypeScript repo from namespaces to modules
#133Earlier quoted context omitted.
Why would you ever mix them?! Even when I started programming 15 years ago it was already accepted wisdom that that was a terrible idea.
This is one of those things that started out as good advice, and then got turned in to an oversimplified parody of the original argument. If you have something like: var ( x = foo other = bar ) Then clearly you should use spaces to align those "="s, no matter if you use spaces or tabs for indentation. Similarly, "hanging indents" like: coolFun(arg1, arg2) Can only be done correctly with spaces, and it doesn't really…
> If you had used tabs, changing the tab size would make it align all wrong.
This is clearly false. You said this after giving a perfect example of how it's done with tabs.
Re: PR that converts the TypeScript repo from namespaces to modules
#134500k lines changed, oof. Imagine the merge conflicts. Could this not have been done incrementally?
This is as incremental as it really could be; the entire build had to change, all of the code needed to be unindented one level, etc. I have tested the merge conflict problem, and thanks to the way the PR is constructed (in steps), git actually does a good job figuring things out.
I'm curious on how to make such a change in such a large and living code base.
Did you consider _not_ re-indenting the entire code base and rely on the auto formatters of contributing people? Did you consider re-formatting parts of the code step-by-step, beginning with code that's not frequently changed?
Didn't know about the feature that ignores commits in git-blame, thank you for that.
Re: PR that converts the TypeScript repo from namespaces to modules
#135Earlier quoted context omitted.
I rewrote a card game engine, openEtG, from JS to Rust. It was a pretty 1:1 rewrite. 2x improvement even when I was using HashMap everywhere. I've since entirely removed HashMap, which has only further improved perf As a bonus, the code is now statically typed
I suppose it depends on your use case, but I don't really consider 2x to be a significant difference. Between programming languages we often speak in orders of magnitude. If JS is only half the speed of a compiled language like Rust, that shows remarkably optimized performance.
Twice as fast is a big deal for damn near any program except like...unimportant, already slow background tasks or things that are already exceptionally fast. Cutting the frame render time in half could give you twice the framerate. Twice the performance on a server could let you handle twice as many concurrent sessions (and possible run half as many servers!). People regularly fight tooth and nail to squeeze 10% performance boosts on critical tasks, doubling it would be incredible
Re: PR that converts the TypeScript repo from namespaces to modules
#136Earlier quoted context omitted.
This is one of those things that started out as good advice, and then got turned in to an oversimplified parody of the original argument. If you have something like: var ( x = foo other = bar ) Then clearly you should use spaces to align those "="s, no matter if you use spaces or tabs for indentation. Similarly, "hanging indents" like: coolFun(arg1, arg2) Can only be done correctly with spaces, and it doesn't really…
> If you had used tabs, changing the tab size would make it align all wrong. This is clearly false. You said this after giving a perfect example of how it's done with tabs.
So you are saying that using a tabstop of eight to align this:
-------->coolFun(arg1,
-------->------->arg2)
Re: PR that converts the TypeScript repo from namespaces to modules
#137Earlier quoted context omitted.
"Tabs vs spaces" is often misunderstood (and falsely reported) as a problem of preference. The real problem is that using spaces for indentation is an accessibility issue. The solution is to use tabs for indentation, and spaces for alignment.
While that may be true, "spaces for alignment" is nigh unsupported by all editors I've seen. They insist on replacing 8 (or N) spaces with tab even if in an alignment region. int foobar(int a, ___________int b) // should only ever have spaces (using _ here because HTML) But good luck finding an editor that won't insert a tab when you use the tab key here (willing to be wrong). The other issue I have is that diffs bre…
With a .editorconfig[1] file with the correct configs you can get most code editors to insert spaces instead of tabs.
Re: PR that converts the TypeScript repo from namespaces to modules
#138Earlier quoted context omitted.
> The real problem is that using spaces for indentation is an accessibility issue. Not this again https://github.com/prettier/prettier/issues/7475#issuecommen... > Blind programmers have no problems with it.
Not everyone with vision or vision processing issues is blind. Being able to configure custom tab stops is an easy way to control what level of indentation is useful and clear.
The primary accessibility argument is that spaces waste precious space on braille displays.
Re: PR that converts the TypeScript repo from namespaces to modules
#139Earlier quoted context omitted.
> If you had used tabs, changing the tab size would make it align all wrong. This is clearly false. You said this after giving a perfect example of how it's done with tabs.
So you are saying that using a tabstop of eight to align this: -------->coolFun(arg1, -------->------->arg2) Would still look nicely aligned with a tabstop of 4? and 2? Clearly that will not look right.
You're misquoting yourself.
Re: PR that converts the TypeScript repo from namespaces to modules
#140Earlier quoted context omitted.
> Why not save even more bytes and re-format the output to single tab indentation? For your answer search "programmers who use spaces make more money"
Correlation != causation Spaces are simply inferior to tabs since the latter conveys the meaning of "one level of indentation" while the former does not. It's also better for accessibility and file size. There is not one single logical reason to ever use spaces for indentation, not one. For some very fucking stupid historical reason someone in the 80s made the idiotic decision of spaces being the default in editors a…
The decision to use a character that is 8 chars wide for indentation of a highly nested code was not a brightest idea either.
I’d love to set up terminal tabstop size, textview tabstop size, github tabstop size, IM tabstop size, HN tabstop size, git gui plugin tabstop size, issue tracker tabstop size, tsv file format tabstop size if I used tabs. It makes you so productive.