Re: [TUHS] The Elements Of Style: UNIX As Literature

[Jon Steinhart <jon@fourwinds.com>]

Larry McVoy writes:
> On Fri, Nov 06, 2020 at 05:37:25PM +1100, Greg 'groggy' Lehey wrote:
> > On Friday,  6 November 2020 at  0:04:28 -0500, John Cowan wrote:
> > > On Thu, Nov 5, 2020 at 8:41 PM Larry McVoy <lm@mcvoy.com> wrote:
> > >
> > >> I click but I mostly live in terminal windows.  Which are all 80
> > >> columns because that's the right width (I can go on and on about
> > >> that).
> > >
> > > Aw, c'mon.  You're going to tell us that the number of punch holes
> > > that IBM could fit on a punch card in 1928 that was exactly the size
> > > of the dollar bill used in the U.S. from 1862 to 1923 so that it
> > > could be stored in a mechanical cash register is miraculously the
> > > Right Thing when it comes to reading monospaced text on a screen?
> > 
> > I think you're jumping to conclusions.  The importance of 80
> > characters (for small values of 80) is that it's a comfortable text
> > width for human eyes.  
>
> Exactly this.  I'm a very fast reader, easily 2-3x the average.  I read by
> running my eyes down the middle of the page and get the left and right
> from peripheral vision.  It's super fast but it doesn't work when you
> get much bigger than 80 columns.
>
> Even if you read normally, the wider it is, the more back and forth your
> eyes do so less is more.
>
> It's also why I'm fine with smaller screens, I tried the giant apple
> displays and found that those required head movement along with eye
> movement.

We're getting into religion again here, and I've never found that to be a
sound basis for policy.  I'm going to quote liberally here from a screed
that I wrote (but have not published) when trying to understand parts of
the linux kernel.

I've always been willing to spend buckets of money on the monitors because
to me that's an area where bigger and higher resolution is always better.
I've been using 132 column terminal windows since sometime in the 90s when
I got myself a monster 24" Trinitron monitor from Sun.  I seem to recall
that it listed for $3,300, thanks to the unnamed person who got me the
employee discount :-)  I tried going to 160 columns but that was too wide
for the monitors that people I worked with had.

I hated Shakespeare in high school.  One of the big reasons was that I felt
that he made up a word whenever he didn't have a good one available.  The
flipping back and forth to the list of definitions completely interrupted
the cadence of reading.  The insistence on short line lengths in coding
standards and the contortions that people go through to meet them has the
same effect for me.

I've coined the phrase "mental locality of reference" to describe this; at
least I think that I'm the first one to use it.  Short lines and modern coding
styles ask the human brain to contort itself in ways that we are loath to ask
hardware to do.

As near as I can tell, the belief that people do best with line lengths between
50 and 75 characters long is the result of people repeating "wisdom" that they
heard from someone else that orginates from what I consider to be a misreading
of Emil Ruder's book "Typographie: A Manual of Design".  While Ruder does make
this statement about line length, it's in the context of normal typography.
It does not even remotely consider computer code where long lines are long
mainly due to leading whitespace.  To the best of my knowledge nobody has
studied this - does the line length when counting begin at the first column or
the first non-whitespace character?

While readers might "lose focus" part of the way through long lines, that has to
be balanced against the loss of focus that comes from 'mental carriage-returns"
when text is too narrow and broken across several lines.  Again, not studied as
far as I know.

The linux coding standard makes the unsubstantiated claim that having more than
three levels of indent is a problem.  And it's really hard to understand,
because on one hand, it says that you "should fix your program", and then says
that "nesting functions too deep" is a problem.  Sounds like a catch-22 to me;
how are you going to minimize indent if you can't nest functions?  I'm guessing
that someone typed this without reading what they wrote and really meant
"statements", not "functions".

We're back to the mental locality-of-reference thing that was mentioned earlier.
I'd much rather have a few more levels of indent and longer lines than have to
go chasing gratuitous function calls.  Think about every diversion from the
stuff in front of you as a cache miss.

When I look at the linux kernel code, I see incredibly bad contortions made in
attempts to meet the coding style.  I also observed that the code only loosely
follows its coding style.  How are people limiting their code to three indent
levels?  By including dozens of header files that contain static inline
functions.  Gak!  I feel that style rules should be observed in some sort of
priority order, and mental locality of reference, which isn't in anybody's
rules but mine, is at the top of the list.

I could go on, but hopefully I've made my point.

Jon