As typesetters have known literally for centuries and human-factors folks have confirmed since, there is a number of characters per line that is optimal for reading. Shorter than that, and you're going back to the beginning of the next line too often. Longer than that, and going back is too hard. Either one disrupts concentration, even if we're only talking about tiny fractions of a second.

Is 80 columns exactly right? Probably not. From what I've read, the ideal is probably a bit shorter. In any case, having a standard that's in the right ballpark is a good thing. There will always be some complainers, but 80 columns seems pretty good for most people. It's nothing to do with punch cards, except that their design was probably influenced by the same ergonomic principles.

When talking about ease of reading, one important nuance is to not to confuse "characters per line" with "columns per line"--whitespace doesn't matter.

Applying a block indent doesn't increase the number of printed characters per line. And consider multi-column text as seen in newspapers--generally the principle is that it's the width of the text that matters, not where the column is located on the page.

Generally, the layout of characters within a block of text is directed to the task of reading within a passage. The layout of blocks on the page/screen is more about conveying larger structure and toward the task of seeking/navigating among passages.

It's true that indented code is different than text, but I don't think it's different enough (or in a way) to affect the conclusion. Indented blocks don't go on forever before the eye must seek back to the beginning. Width limitations help reduce "indentation creep" which is bad for its own reasons. Block comments (including those extracted for documentation) are often full width. For these reasons and more, a column limit yields more readable results.

I don't care what the limit is, but there has to be a limit, because otherwise you always get that one asshole who likes to zoom his single editor pane fullscreen on a 30" monitor and then type, type, type until he wraps around the far side. Codebases like that are just painful to work with, and it's a waste of monitor space when you can't stack up a row of editors side by side.

I use 80 columns, personally, just because it's familiar, but I'd be just as happy with 100 or 112 or 120 or 160 or really anything as long as there's room to fit at least two editors on screen side by side.

Good on Pike and co.

Next up, let's deprecate the horrid mess that is the userspace terminal control subsystem on most modern Unix-likes: http://landley.net/notes.html#27-04-2015

(Keep in mind this is an orthogonal problem compared to the in-kernel VT subsystem, and I think it's Linux where CONFIG_VT is particularly bad.)

I disagree with Pike though I have mine fixed to 133 columns, not 80. A different historical set of handcuffs.

Live by the mandatory format, die by the mandatory format.

(also what the hell, why would you ever not use a fixed width font for coding)

Is this sample of ineffectual whining notable for any reason other than its author? Is its submission here to be taken as a challenge to improve text rendering on computers? What is the point here?

His whining is funny, while yours is not.

It is "whining" that godoc has to output at a max width of 80 characters because many people apparently still use that as the terminal width. I, personally, do not and can see his point.