Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PR that converts the TypeScript repo from namespaces to modules

github.com

Post reply on HN
Print view View original

171–180 of 204 posts

Re: PR that converts the TypeScript repo from namespaces to modules

#171

Post by dotancohen »

SuchAnonMuchWow wrote: post #168
dotancohen wrote: post #161

Earlier quoted context omitted.

Thats the point. I like four character width indentation. Linus prefers eight. With tabs VIM shows me what I like and shows Linus what he likes.

How do you work with max-char-per-line limits of coding conventions ? Does code you write with tabs as 4 spaces follow the convention but then break on Linus computer ?

I personally use a vertical monitor, in Jetbrains that gets me about 130 characters on a line before scrolling, and in VIM it get me about 125. I'll break a long line into shorter lines if they begin to approach the end, but I'm not strict about it. From what's open right now I do have a few lines that get close, and one that goes over. So what? All my coworkers use horizontal monitors and even with gutters and panels open they're not complaining about my line length - and I've not had a complaint about line length since I've started in this industry in 1999. Back then there were no vertical monitors, it was all 4:3 CRTs.

As an interesting note, I now work with the second hard-of-sight developer that I've worked with in my life. They both use normal Jetbrains IDEs, with font sizes and interfaces made huge. Neither of them has ever said a word about my line length. Nor my function length. Nor my long variable and method names. Nor my explicit comments, nor my detailed git commit messages, nor my frequent git commiting, nor my branching preferences, nor my README files, nor my obsessive security practices such as validating types and character length limits on input fields and sanitizing and filtering input and my rejecting of any PR with concatenated outside-data in SQL (even if that outside-data came from the DB itself, for a recent example), and all the other idiosyncrasies that one dev suffers from another.

Line length? Not a problem. Forcing the hard-of-sight dev to indent however _I_ see fit? I wouldn't dream of doing that.

Re: PR that converts the TypeScript repo from namespaces to modules

#172

Post by hennell »

SuchAnonMuchWow wrote: post #168
dotancohen wrote: post #161

Earlier quoted context omitted.

Thats the point. I like four character width indentation. Linus prefers eight. With tabs VIM shows me what I like and shows Linus what he likes.

How do you work with max-char-per-line limits of coding conventions ? Does code you write with tabs as 4 spaces follow the convention but then break on Linus computer ?

Is there really a value of a max-char rule these days? Editors can scroll, softwrap and usually do neither as screens are large anyway. A max-indent rule makes sense to highlight when you're nested too deep and should refactor, but a long line of code can either be done based on "this looks unusually long" or a formatter that has a set tabwidth.

Re: PR that converts the TypeScript repo from namespaces to modules

#173

Post by conaclos »

iainmerrick wrote: post #105
conaclos wrote: post #67

Earlier quoted context omitted.

This could change with an ongoing work to allow ts extension [1]. [1] https://github.com/microsoft/TypeScript/issues/37582

That doesn’t look like an issue that’s going to be resolved any time soon. Lots of comments which read like people digging in their heels to preserve the current behavior.

It was in the 4.9 iteration plan [1], and is now in the 5.0 iteration plan [2]. They also talk of this in a design meeting [3] and a member of TS team seems committed to it.

[1] https://github.com/microsoft/TypeScript/issues/50457

[2] https://github.com/microsoft/TypeScript/issues/51362

[3] https://github.com/microsoft/TypeScript/issues/51302

Re: PR that converts the TypeScript repo from namespaces to modules

#174

Post by brianzelip »

spartanatreyu wrote: post #107
robbick wrote: post #63

Earlier quoted context omitted.

I can see this is probably a calm point that will definitely not escalate, programmers don't really care about tabs and spaces that much, right???

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

> The solution is to use tabs for indentation, and spaces for alignment.

It's the second step that drives me nuts. Why can't/doesn't alignment happen at first step? The inconsistencies of alignment using true tabs, in a monospace plain text environment, grosses me out and decrements my faith in the underlying systems. I appreciate editors w/ settings like `insert spaces when pressing tab` and `the number of spaces a tab is equal to`.

Re: PR that converts the TypeScript repo from namespaces to modules

#175

Post by andy_ppp »

zebracanevra wrote: post #29

After this change, the TypeScript compiler will now be compiled with esbuild. I feel like thats probably the best endorsement esbuild could get, hah. Surprising they call out the 2 space indent level that esbuild is hardcoded[1] to use as a benefit. Why not save even more bytes and re-format the output to single tab indentation? I wrote a simple script to replace the indentation with tabs. 2 indent size: 29.2MB, tabb…

Why have and white space at all in that case?

Even on an absolutely gigantic codebase using tabs or spaces will make almost no difference to build or type-checking times. Building an AST is much more overhead than white space considerations and once it’s an AST tabs or spaces are not included in the running of the code.

Re: PR that converts the TypeScript repo from namespaces to modules

#176

Post by int_19h »

dotancohen wrote: post #160
shadowgovt wrote: post #126

Earlier quoted context omitted.

As with all other types of data: the right approach is for model and presentation to be separable concerns. We're struggling with the wrong problem if we aren't asking why the editor can't treat blocks as entities that are displayed however we want.

> why the editor can't treat blocks as entities That might with with C, but won't work with e.g. Python.

Python has syntactic blocks as well, and editors totally can (and do) muck around with their formatting. I don't see any reason why they couldn't handle customizable indentation.

Re: PR that converts the TypeScript repo from namespaces to modules

#177

Post by philliphaydon »

mathstuf wrote: post #122
spartanatreyu wrote: post #107

Earlier 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…

All JetBrains editors will put spaces.

Re: PR that converts the TypeScript repo from namespaces to modules

#178

Post by gchamonlive »

3836293648 wrote: post #170
ahungry wrote: post #130

Earlier quoted context omitted.

Well stated.

No, it's incredibly stupid and is missing the point. You use tabs to not be consistent. So that the crazy js person can have a 2-wide indent and the slightly visually impaired person can have an 8-wide indent without reformatting the entire codebase

Are you visually impaired of have you received or read criticisms of this nature from visually impaired persons? Genuine curiosity, because if this is a matter of accessibility I would vouch for tabs.

Thing is that with spaces you can also predict consistently the line length and not have code being clipped on someone's screen that set tabs for 8 spaces for some reason.

In any case, I like spaces but I am impartial to either one. You seem like you have very strong opinions about the matter so I won't push the subject further.

Re: PR that converts the TypeScript repo from namespaces to modules

#179

Post by Beltalowda »

adolph wrote: post #166
Beltalowda wrote: post #136

Earlier quoted context omitted.

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.

To understand tabstops properly, you need to throw away the "They always expand to N spaces." idea. If you have access to a mechanical typewriter with tabstops, then go and look at how it works (with tabs being set by protruding pins on the carriage). Tabstops in terminals in the Unix and Linux worlds work this way. https://superuser.com/questions/710019/why-there-are-11-tabs...

If you use it as indention then "tab expands to n spaces" is actually accurate though.

Re: PR that converts the TypeScript repo from namespaces to modules

#180

Post by IshKebab »

yrgulation wrote: post #112
IshKebab wrote: post #61

Earlier quoted context omitted.

Kind of funny because one of the benefits of tabs vs spaces that people laugh off is that it saves space. I think it's probably correct to laugh this off though. Why would you care about the non-minified/gzipped size this much?

TS devs still debating this in 2022? And i thought php devs are ridiculous for still debating setters and getters.

They aren't debating it. And I don't think why you'd think setters and getters are not worth debating. There are significant downsides to them (e.g. they make Dart's sound nullable support more annoying).
Post reply on HN