
Rob Pike: Submit to the punched card tyranny - jcox92
https://github.com/golang/go/commit/a625b919163e76c391f2865d1f956c0f16d90f83
======
notacoward
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.

~~~
fluidcruft
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.

~~~
notacoward
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.

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

------
vezzy-fnord
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](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.)

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

------
GFK_of_xmaspast
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)

------
stonogo
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?

~~~
andrewchambers
His whining is funny, while yours is not.

