I think the famous rule for short memory capacity (we can on average keep 7 words/numbers/objects in out short memory) should also apply here. Up to 7 words/operators per line, up to 7 lines for a function etc. are optimal.
But no, 80-column terminals in 2020 isn't “reasonable” any more
141–150 of 330 posts
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#142Typical 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
> "the average font size has been steadily creeping, maybe 1.5 pts per 5 years."
To be fair, so has the monitor resolution and its density. I'm looking at HN, and imagine, ten years ago, I was using 1280x1024 then, this very font would've physically been a much bigger picture. So in effect, the font-size increase may only counter-measuring the resolution increase...
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#143Optimal code line width has very little to do with monitor or window width. It's more of an anatomical restriction: the resolution of the human eye and the 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 per line we can use doesn't change much. Not so long ag…
I would be more sympathetic to 80 column limits if Linux didn't have indent set to 8 columns.
This was a solved problem with tab indenting. It's a bit unfortunate that space indenting won, but I understand why.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#144"Does Column Width of 80 Make Sense in 2018?":
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#145Earlier quoted context omitted.
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
It’s _literally_ the first app that gets installed on a fresh machine for me.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#146Optimal code line width has very little to do with monitor or window width. It's more of an anatomical restriction: the resolution of the human eye and the 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 per line we can use doesn't change much. Not so long ag…
> 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 might not be the problem. For example, instead of having a single very large monitor, I use three somewhat smaller monitors because that enables other productive workflows.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#147Earlier quoted context omitted.
You can customize your text editor to show them as any number of spaces. Mostly people prefer tab-stops at each forth or eighth column.
In practice you get problems, because of the line length rule. I.e. if your editor is configured with four-space tabs and a line with one leading tab shows up in your editor having 79 characters, it will show up as 83 characters for others assuming the normal 8-space tabs thus breaking the line length rule. Not to mention that coding style may require that function calls broken to 2 lines must have the arguments alig…
>Not to mention that coding style may require that function calls broken to 2 lines must have the arguments aligned at the opening parenthesis.
That doesn't result in any problems with using s, unless the coding style also requires you to replace all (leading) sequences of N spaces with with a , which is, IMO, quite brain-dead. For example,
if (cond) {
foo(1,
2);
}
Admittedly, your first problem remains; a problem with dumb editors. In truth, your editor could well signal if your lines exceed the limit (indent-width*indent + rest) you have set for your project, just as easily as it can draw a line at a column.
The harder problem is that you need a context-aware editor for it to help you with indenting. Most editors are incapable of that by default.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#148I think this is a subject most editors fail to address. A single line of code should be written to file as a single line - no matter how long. However, the editor you are using should be able to gracefully word wrap it depending on your settings. Most editors word wrap based on window size or some other hard setting. They should be able to wrap gracefully at a logical point in the code e.g. at a comparison operator o…
Even vim handles word wrapping well. A text editor which can't... well, it's a pretty poor text editor then, isn't it?
That said, I don't know of many text editors (outside of notepad, and even that's gotten better lately) which don't offer options about how to (or not to) wrap text.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#149Typical 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.
As "nerdy" as they look, the CliC brand readers (that separate magnetically at the nose, and that wrap around the back of your head with a solid band) are remarkably good at sticking with you as you move around in the day. 1.0's at the computer, 1.x around your neck.
Sadly, they don't make them with anything under 1.25.
Re: But no, 80-column terminals in 2020 isn't “reasonable” any more
#150Earlier quoted context omitted.
Can't you enable line wrapping in your editor?
Line wrapping is an abomination.
Visual line wrapping (that doesn't modify the code) is just fine. Works a treat for prose and notes, and if you combine it with a toggle to switch to horizontally scrolling lines, it works remarkably well.