But no, 80-column terminals in 2020 isn't “reasonable” any more • Hacker News Board

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#231

Post by thawaway1837 » Sat, May 30, 2020, 11:36 AM UTC

shockinglytrue wrote: post #13

Typical ill-considered comment from Linus, and surprising for someone getting on his years. Column width is an accessibility issue . I'm barely in my mid 30s and the average font size has been steadily creeping, maybe 1.5 pts per 5 years. I could tolerate 132 column files today, but by the time I'm 50 there is no way this will work, regardless of screen size

Well, Linus has already said he doesn’t care about your (or anybody else’s) accessibility issues.

Is the kernel getting impossible to compile on anything less than a monster $2500 gaming rig? Too bad. Stop being poor or from a poor country.

Does the code require a $1000 monitor to be readable? Same.

Do you need a larger size font because of age? Well pop your Benjamin Button polls coz Linus Torvalds dont care.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#232

Post by LargoLasskhyfv » Sat, May 30, 2020, 11:49 AM UTC

I never understood this fetish. Using workstations with graphical framebuffers, which even had the system console in whatever was hires then, setting the system console to 132x60 in text mode on 21 inch for FreeBSD was one of the first things i did. That punchcard inspired technical limit was something to overcome, not to embrace.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#233

Post by wolrah » Sat, May 30, 2020, 12:22 PM UTC

enriquto wrote: post #207

fouric wrote: post #175

Earlier quoted context omitted.

This. The problem itself has nothing to do with the number of characters you have on a line - the problem is that the vast majority of programming tools today conflate content and presentation. The job of making sure the line length is reasonable is not up to the writer of the code - it is up to the tools that are used to read it. Lines should be as long as necessary, and then intelligently (i.e. syntactically-aware)…

> the problem is that the vast majority of programming tools today conflate content and presentation. This is not a problem, but a beautiful and crucial property of text files. I like the principle that "a program is a text file", that you can edit with tools orthogonal to the language in question

> I like the principle that "a program is a text file", that you can edit with tools orthogonal to the language in question

Adjustable tab display width and automatic line wrapping are features any good text editor offers that do not interfere with the use of any other text manipulation tools on that file.

Now, if you're forced to work in an environment where someone wrongheadedly decided to adapt to users who have bad or badly configured editors and standardized on space indentation that sucks, but that's the fault of whoever made that bad decision.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#234

Post by wolrah » Sat, May 30, 2020, 12:30 PM UTC

justaguy88 wrote: post #173

ssivark wrote: post #98

Earlier quoted context omitted.

It really doesn’t matter. We must strive to separate content and presentation, so people could choose whatever presentation they like (and have the editor do the wrapping as desired), for whatever whimsical reason that is nobody else’s business. It’s crazy to keep having this discussion and debating what the “research” indicates. C’mon, haven’t we made any progress in forty years!? Everybody can have their own damn b…

Ah so you're "tabs" haha

100% the reason I'm a tab guy.

If I'm glancing at some code on my phone, I can have it set to two space tabs to maximize the amount that fits on screen. If I'm on my desktop they're four spaces because my screen is huge and more visibly apparent indentation is valuable. Same editor, same data. If it's a shared codebase and someone else likes 8 space tabs, 6 space, or whatever they want (13 space? no kinkshaming here...).

To me that is a significant objective advantage of tabs, where the only advantage spaces seem to offer is that you can align text on multiple levels of indentation.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#235

Post by kakwa_ » Sat, May 30, 2020, 1:02 PM UTC

Fiahil wrote: post #39

I guess most of us, pragmatic people, agree that 80 columns is not a sane standard anymore. The more interesting question is "what would be a good default line length in 2020?" I vote for 120 columns.

I would vote for something around ~100 with a tolerance for ~130 (CI/linter warning if between 100 and 130, maybe with a threshold limiting the proportion of lines per file in warning so that the tolerance is not abused).

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#236

Post by taeric » Sat, May 30, 2020, 1:59 PM UTC

fauigerzigerk wrote: post #211

taeric wrote: post #162

Earlier quoted context omitted.

It is more than just natural language. You could look at math journals, for their jargon. Music notation. Recipes. Really, is there any writing that doesn't seem to apply?

It doesn't apply to code to the same extent, because reading code rarely means reading every single line left to right. Also, lines ending on column 100 are not necessarily 100 characters long. There could be indentation on that line and on the next. Vertical alignment has meaning in code whereas it ususally doesn't have meaning in natural language text. So if you insert line breaks into code purely to follow some ar…

Same is true for most all reading. Skim then read, is a predominant form is reading. Is why newspapers scatter their stories throughout. Indeed, they punish linear reading...

Recipes often do two columns of some things. Math jargon is all about repetition. Narrative, explanation, exposition.

Don't get me wrong, I am inclined to agree with you. But we don't have a ton of empirical evidence on our side.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#237

Post by Twixes » Sat, May 30, 2020, 2:10 PM UTC

zajio1am wrote: post #135

Fiahil wrote: post #39

I guess most of us, pragmatic people, agree that 80 columns is not a sane standard anymore. The more interesting question is "what would be a good default line length in 2020?" I vote for 120 columns.

I would say that 120 is too much - for 1920px (still widespread resolution) and split screen (2x120), one would need 8px-wide font to fit and no other borders. 8px-wide font is IMHO not enough for good readability, even VGA in 198x switched to 9px-wide fonts (from EGA 8px-wide fonts). Next natural values are 106 (for 9px fonts) and 95 (for 10px fonts).

Few use bitmap fonts today, especially with retina displays and whatnot

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#238

Post by bcrosby95 » Sat, May 30, 2020, 2:25 PM UTC

burntsushi wrote: post #146

bcrosby95 wrote: post #121

Earlier quoted context omitted.

> It's more of an anatomical restriction: the resolution of the human eye and the field of view. The restriction on code length to 80 has absolutely nothing to do with the resolution of the human eye or your field of view. > For example, if we had 10 meter-wide monitors we won't be able to see them entirely from a close distance. Increasing the distance will require to increase the font, so the number of characters p…

I have a certain monitor width, distance from that monitor and font size. Those constraints dictate how many open file columns I can fit across my screen. I'm happy if I can get two columns, so that I can edit files side-by-side. 80 columns is the approximate sweet spot. The suggestion that people should just get "better hardware" is so completely asinine, because it neglects to realize that the quality of hardware m…

He never said to buy better hardware. He said the code should no longer be formatted based upon what he believes to be a niche situation. People in this situation can, in fact, still edit code. You will get line wrapping. It's not optimal, but neither is editing 80 lines when you have 100 available.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#239

Post by ThrowawayR2 » Sat, May 30, 2020, 2:28 PM UTC

ogre_codes wrote: post #126

js2 wrote: post #49

The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. Take it from the world of books: This study may be helpful: > This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 c…

> The problem with overly wide lines is that it hurts readability because it's harder to find the next line when scanning your eyes from right back to left. There is some truth to this, but it's largely irrelevant. When text is laid out for books, it's based on a fixed width and each sentence follows the next. Code isn't laid out that way, with code, each statement starts on a new line which naturally limits line wid…

> "Good programmers gravitate towards shorter lines of code by nature. If your average line of code is wider than 80 characters, it's likely you have some other, bigger coding style problems which need to be addressed."

I can't agree with that. When you've got class names like AbstractSingletonProxyFactoryBean and similar naming conventions for variables, 80 characters just isn't adequate a lot of the time.

Re: But no, 80-column terminals in 2020 isn't “reasonable” any more

#240

Post by williamdclt » Sat, May 30, 2020, 2:53 PM UTC

bjoli wrote: post #212

voodootrucker wrote: post #139

Earlier quoted context omitted.

> patches in emails Cringe.

Give me a better non-locked-in experience than a mailing list, gnus/mu4e and magit and I am happy to try it out.

Your argument stands, but this non-locked-in experience is so bad it locks most people out. I've done it, I did contribute to Git, and the experience was horrible. The amount of time spent on the mailing part was far far greater and confusing than the amount of time writing code (one of the patch was just a wording change actually).

And I don't see how using github locks you in, switching to gitlab, bitbucket or whatever is dead simple.

Honestly, the only 2 arguments I see for this process are "that's what we always did and we don't want to make the effort to switch" and "having a high barrier keeps newbies out and we don't consider it a bad thing"