The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: akosela@andykosela.com (Andy Kosela)
Subject: [TUHS] 80 columns ...
Date: Sat, 11 Nov 2017 15:33:21 +0100	[thread overview]
Message-ID: <CALMnNGh4zjaAQ+OYk8-NfOtx+na1npK0pGu=1mfZwWE91-4uMw@mail.gmail.com> (raw)
In-Reply-To: <201711102259.vAAMxNao015564@darkstar.fourwinds.com>

On Friday, November 10, 2017, Jon Steinhart <jon at fourwinds.com> wrote:

> Toby Thain writes:
> > On 2017-11-10 3:43 PM, Jon Steinhart wrote:
> > > Toby Thain writes:
> > >> Just don't move on without some limit. There are real
> > >> cognitive/typographic reasons why excessively long lines hurt
> > >> comprehension. This is why both 500 year old books and 5 month old
> books
> > >> have narrow measures.
> > >>
> > >> 80 might be too narrow for most, but at some point beyond 132 is "too
> > >> far". :)
> > >
> > > Well, I would claim that books have technological limitations that are
> > > different than computer monitors.  It's a matter of doing what's
> appropriate
> > > instead of taking a dogmatic approach.
> >
> > It's _reading_. Code doesn't magically escape typographic factors. The
> > human visual/processing system is the constraint, it does not care
> > whether you're reading paper or the more hostile LCD - and it has not
> > changed materially in the millennia we've been doing writing (and
> > certainly not the 500 years we've been doing books). There is also a
> > body of modern research on this. Even research specifically focused on
> > code, I believe.
>
> I'm not unfamiliar with the studies.  Most are focus on speed of reading
> which is not necessarily the most important thing in code.  Some studies
> have found that things that are easier to read are read less accurately
> which might be OK when reading a novel but is not necessarily optimal for
> code.
>
> Me, I try not to be dogmatic or to read what I want into studies.  Well
> written long lines trump cryptic short lines for me.  Your mileage may
> vary.
>
>
I don't think it is about being dogmatic.  Please believe there are still
some people who just _prefer_ 80 columns.  It could be because they were
introduced to computing when this was a standard and they still treat it as
a standard for text based computing, or they just find the aesthetics of
this format much more pleasant to their eyes.

For me there is something truly magical in the way 80 columns text look on
a dark CRT display -- I also love the glow of green or amber phosphor and
scanlines as visible clearly on vt220 for example.  So even though I am
also using xterms these days, my perfect UNIX computing platform is
still definitely a full screen text console 80x24 using CRT terminal.

HD widescreen LCD displays are nice...but for modern graphics and video at
high resolutions.  Try to display perfectly old Amiga or
C64 graphics/games on a modern widescreen and you will know what I am
talking about.  You need an old CRT for that, in 4:3 format.

The same is for displaying text -- I don't believe you need the next gen
monitor to display UNIX text based console (technology essentially from the
70s).  It actually looks worse on modern displays, which are optimized for
HD _graphics_ and high native resolutions.

If you think about it -- computing platforms and the Internet were text
only in the 70s, 80s and a good part of the 90s, but since the rise of
Windows 95 and the World Wide Web, the world has abandoned text and moved
fully into the graphical world.  But we also lost something -- full screen
text mode will always remain beautiful from an aesthetics perspective and
it is still the best stimulant of the imagination, just like books.

Todays generations do not even know how to stay focused on reading text --
all they do is swipe their fingers on next colorful images on Instagram or
Facebook...

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171111/e112fe55/attachment.html>


  reply	other threads:[~2017-11-11 14:33 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-08 20:52 ron minnich
2017-11-08 21:02 ` Larry McVoy
2017-11-08 21:19   ` Dan Cross
2017-11-08 21:24     ` Larry McVoy
2017-11-08 21:28       ` Steve Nickolas
2017-11-08 21:48         ` [TUHS] (cassette) tape coming back [was " Charles H Sauer
2017-11-08 22:46           ` Don Hopkins
2017-11-08 23:28         ` [TUHS] " Dave Horsfall
2017-11-08 23:35           ` Ron Natalie
2017-11-08 23:39             ` Dave Horsfall
2017-11-08 21:34       ` Dan Cross
2017-11-08 21:40         ` Dan Cross
2017-11-08 21:40         ` Larry McVoy
2017-11-08 21:43           ` Dan Cross
2017-11-09  1:00             ` Theodore Ts'o
2017-11-08 23:46     ` Steffen Nurpmeso
2017-11-09  6:52       ` Otto Moerbeek
2017-11-08 21:06 ` Bakul Shah
2017-11-08 21:18   ` Steve Nickolas
2017-11-08 22:17 ` Grant Taylor
2017-11-08 22:30   ` Arthur Krewat
2017-11-08 23:07     ` Andy Kosela
2017-11-08 23:15       ` Arthur Krewat
2017-11-08 23:15         ` Warner Losh
2017-11-08 23:49           ` Arthur Krewat
2017-11-09  0:04             ` Dave Horsfall
2017-11-08 23:24         ` Andy Kosela
2017-11-09  7:24 ` Lars Brinkhoff
2017-11-09 15:02   ` Don Hopkins
2017-11-09 19:14     ` Ron Natalie
2017-11-10 16:18       ` Nemo
2017-11-10 19:05         ` Jon Steinhart
2017-11-10 20:36           ` Toby Thain
2017-11-10 20:39             ` Larry McVoy
2017-11-10 20:46               ` Warner Losh
2017-11-10 20:59                 ` Larry McVoy
2017-11-11  9:24                 ` David Arnold
2017-11-10 20:43             ` Jon Steinhart
2017-11-10 20:58               ` Larry McVoy
2017-11-10 21:02                 ` Jon Steinhart
2017-11-10 21:09                   ` Larry McVoy
2017-11-10 21:12                     ` Jon Steinhart
2017-11-10 21:34                       ` William Corcoran
2017-11-10 21:50                         ` Jon Steinhart
2017-11-10 22:58                         ` Dave Horsfall
2017-11-10 23:05                           ` Jon Steinhart
2017-11-10 23:52                             ` Toby Thain
2017-11-11  0:24                             ` Larry McVoy
2017-11-11 16:40                   ` Ian Zimmerman
2017-11-11 16:47                     ` Larry McVoy
2017-11-11 17:23                       ` Jon Steinhart
2017-11-11 17:38                         ` Ralph Corderoy
2017-11-10 22:46               ` Toby Thain
2017-11-10 22:59                 ` Jon Steinhart
2017-11-11 14:33                   ` Andy Kosela [this message]
2017-11-11 17:19                     ` Jon Steinhart
2017-11-11 17:24                       ` Larry McVoy
2017-11-11 17:25                         ` Jon Steinhart
2017-11-10 23:59           ` Don Hopkins
2017-11-10 22:10         ` Dave Horsfall
2017-11-09 20:46     ` Lars Brinkhoff
2017-11-10 17:21 Norman Wilson
2017-11-10 17:56 ` Larry McVoy
2017-11-11 17:04 ` Ian Zimmerman
2017-11-11 17:30   ` Random832
2017-11-11 18:05     ` Ian Zimmerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALMnNGh4zjaAQ+OYk8-NfOtx+na1npK0pGu=1mfZwWE91-4uMw@mail.gmail.com' \
    --to=akosela@andykosela.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).