Live data from Hacker News

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

lkml.org

11–20 of 330 posts

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

#11
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.

Editors support it fine, but personally I find the result aesthetically unpleasant no matter the editor.

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

#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

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

#15

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

In APL, sure (at least for me). In most common languages today, using meaningful variable names, it's pretty easy to have wide but readable lines.

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

#16
I find as I get older that I need to use bigger fonts in order to easily read code. Based on my terminal font, I can fit two windows side by side with 90 character line lengths, but if I have 3 windows, it would go down to 60 characters (though that's not something I commonly do).

I also find diffs that involve changes to shorter lines easier to read compared to ones with longer lines.

I wonder what he now thinks about line length in email and git commit messages (excluding things like logs, error messages, etc)?

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

#17
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.

linewrap is aesthetically and logically jarring when you're debugging code 'by shape'.

peaks and valleys between functions and such are a huge aid visually -- line wrapping makes visualization of source code harder for myself, personally.

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

#18

I wonder how Linus feels about tabs vs. spaces (I didn't read the entire post, so maybe he addressed it?)

> And yes, we do use wide tabs, because that makes indentation something you can visually see in the structure at a glance and on a whole-function basis, rather than something you have to try to visually "line up" things for or count spaces.

That is what he says

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

#19

I remember bikeshedding with my coworkers about this topic a few years back while coming up with lint settings. We ended up analyzing all current line widths and realized that something like 98% of lines were under 110 characters, so that is what we ended up using.

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

Post reply on HN