Live data from Hacker News

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

lkml.org

21–30 of 330 posts

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

#21
The problem here is that our editors aren't smart enough to wrap code appropriately. Word processors know to wrap lines on word boundaries; a smart code editor should be able to wrap lines and indent parameters in a human-pleasing way as you drag a window wide or narrow.

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

#22

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

I'm 62 and don't normally wear glasses, but reading glasses have become a big part of my life. I use 1.0 to look at my big screen, 1.75 to look at my phone and always misplace them somewhere.

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

#23

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

Can't you enable line wrapping in your editor?

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

#24

Isn’t there some merit to the notion that long lines are typically either overly verbose or mentally challenging to understand?

Splitting one line into many because of character limits can also make an action overly verbose or mentally challenging.

In some cases, unreasonable gymnastics needs to be done to get 80 character lines, turning good variable and function names into shorter worse ones or adding functions just to hide characters.

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

#25
Optimal reading width is like 40-90 characters, and if I end up with an excessively long line, often times, I’ll try to rewrite a bit, not just line-break my first thought, but use it as a creative spur to write better.

Personally, I like 80 character lines. If I need more than 80 characters in a line, I treat it as a code smell.

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

#26

I spend a lot of time writing code on my laptop, and while that could display two 100-column terminals side-by-side, I prefer to also be able to see other windows on my screen while having text at a size that doesn't strain my eyes.

Even on very large high resolution screens, it's nice being able to tile that many more files on the screen. I think 'narrow' source code is advantageous no matter your display.

Yes, and human eyes are bad at tracking lines beyond a certain length.

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

#27
I'm a big fan of softwrapping. Not because it's inherently prettier or something, but because the results are consistently better on more platforms because they can softwrap at what you've set the column width to be and not some arbitrary number someone thought was a good idea. (I have a similar argument for using tabs, but I digress.)

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

#28
post #6

Many programmers are averse to line wrapping plain text files (especially source code), which has never made much sense to me. There's great support for it in like every editor.

In my experience, line wrapping makes line numbering uglier and less intuitively useful. This impacts line operations.

I agree with Linus in some ways, but I think he's also repping a broad-front executive-style decision rather than a really nuanced one. And the details can really impact the preference in a case like this.

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

#29
post #19

Earlier quoted context omitted.

I think a lot of terminals just set that as the default window width. No real reason for it, I usually snap to half the screen width immediately anyways. That turns out to about 105-120 characters width. Some people might just not resize it most of the time. Especially on Mac where efficient window management just isn't a thing.

A note on your last sentence. Once I used my Win10 laptop at an interview at Apple. The interviewer saw me drag one window the the side, snap it, and then select another window to fill in the space. He said, wow, Windows is really nice! :)

I use keyboard shortcuts for that: Win+left and Win+right will maximize a window on that half of the screen. That makes it easy to quickly have a terminal or editor on one half and something else (like a browser or PDF) on the other half, using only the keyboard.

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

#30
post #19

Earlier quoted context omitted.

I think a lot of terminals just set that as the default window width. No real reason for it, I usually snap to half the screen width immediately anyways. That turns out to about 105-120 characters width. Some people might just not resize it most of the time. Especially on Mac where efficient window management just isn't a thing.

A note on your last sentence. Once I used my Win10 laptop at an interview at Apple. The interviewer saw me drag one window the the side, snap it, and then select another window to fill in the space. He said, wow, Windows is really nice! :)

The #3 productivity app on the Mac App Store is a $2 app that enables this on Apples: https://apps.apple.com/us/app/magnet/id441258766?mt=12
Post reply on HN