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

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

lkml.org

Post reply on HN
Print view View original

161–170 of 330 posts

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

#161

Post by Terretta »

DoubleGlazing wrote: post #124

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

> wrap gracefully at logical point in the code

This is so clearly right, how can it not yet exist?

‘Just’ dynamic virtual pretty print per personal lang style prefs.

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

#162

Post by taeric »

l0b0 wrote: post #134
ogre_codes wrote: post #126

Earlier quoted context omitted.

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

Another reason the assumption that style rules for natural language is transferrable to code is kinda baffling. I wonder if there's ever been much research in this space which doesn't make that assumption.

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?

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

#163

Post by em-bee »

williamdclt wrote: post #133
wallacoloo wrote: post #101

Earlier quoted context omitted.

More generally though, there's an argument to be made that line-wrapping should be a thing your editor does as part of the rendering process -- not a thing it encodes into the actual source file. Modern languages come with excellent auto-formatters which can make the code look nice at just about any line length. What we need to do is integrate the auto-formatting into the editor (likely via a language-server) so that…

We could stop storing code as text, just store an AST and let the editor parse it and render it respecting the preference of the user (I think this is a terrible idea, but also got me thinking if there's something interesting there)

didn't some variants of BASIC do this?

smalltalk is storing the code together with the compiled result in an image, so it could do the same, but i am not aware of any implementation that does that.

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

#164

Post by shockinglytrue »

gnarbarian wrote: post #37
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

Buy a bigger monitor. Or get glasses. I'm 38, rocking a 43" 4k monitor. There's so much room. Scale things up or down to your comfort level. It's a pleasure if you use an editor like atom.

What kind of laptop bag do you use for the monitor?

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

#165

Post by JMTQp8lwXL »

Arathorn wrote: post #48

Fwiw, we use 120 columns for Riot/Matrix stuff ( https://github.com/matrix-org/matrix-react-sdk/blob/develop/... ) - 80 is incredibly constraining for JS and JSX. The key metric is to ensure that a typical laptop can show two screens side by side, without any ugly line-wrapping. Also, any wider and you either end up having to scan a wide distance left to right (the same reasons that newspapers use columns to be more…

80 works fine for JSX if you have linter rules that put each prop on its own line, for when you have >80 characters of content.

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

#166

Post by ryandrake »

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 this idea is you then get these web site designers who take it as dogma and try to force a particular width, without regard for the browser window size. This results in sometimes 1/2 or more of the horizontal area on the page wasted by this giant white space border. If you must have a margin, at least make it a reasonable percentage of the browser window width. Or better yet, don’t force my browser to render a margin.

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

#167

Post by smabie »

falcolas wrote: post #148
DoubleGlazing wrote: post #124

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

No text editor that I know of intelligently word wraps code. Vim doesn't and Emacs doesn't either.

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

#168

Post by chj »

thangalin wrote: post #132

France named Basile Bouchon invented a way to control a loom using perforated paper tape in 1725. The descending lineage can be traced to 80-column terminals: https://dave.autonoma.ca/blog/2019/06/06/web-of-knowledge/ In his Elements of Typographic Style, Robert Bringhurst suggests that 66 characters per line, including spaces, for single-column pages is optimal: https://dave.autonoma.ca/blog/2020/04/11/interior-book…

4 spaces allows you to have manual line wrapping, for example: if (a < b || b < c || ... || d < e || ... ) Do something.

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

#169

Post by RHSeeger »

theonemind wrote: post #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.

> Optimal reading width is like 40-90 characters

That statement follows along the same line of thought that many people that want 80 char lines have. That it's better because "it's optimal". I have yet to see any significant study actually showing this to be true for the case of something like code.

Personally, I like longer lines where they make sense, and shorter lines where they make sense. But overall, I like a line configuration that lets me understand as much as possible with one screen of lines. That's the same reason I prefer short functions, because I can understand more in the same screen space from a single function call (by the name) than I can if the same code is inline.

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

#170

Post by catern »

ASalazarMX wrote: post #143
bsder wrote: post #119

Earlier quoted context omitted.

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.

What do you mean? Linux uses tabs.
Post reply on HN