The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jon@fourwinds.com (Jon Steinhart)
Subject: [TUHS] 80 columns ...
Date: Fri, 10 Nov 2017 11:05:28 -0800	[thread overview]
Message-ID: <201711101905.vAAJ5SpV031420@darkstar.fourwinds.com> (raw)
In-Reply-To: <CAJfiPzz5ujn0Me-brHXrzMTumOxrDas6hE43bTQPuvJaEneY1g@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

Nemo writes:
> On 9 November 2017 at 14:14, Ron Natalie <ron at ronnatalie.com> wrote:
> > At least it’s not python where the indenting makes a semantic difference.
> 
> And for that reason, I have never used Python.  (I have a mental block
> about that.)

I agree on Python but for a slightly different reason.  In 1981 I wrote a
user interface for the Tektronix microprocessor development systems.  The
executable plus all of the script data had to fit in memory on the PDP-11.
This was an exercise in byte-counting to make everything fit because of the
cost of overflowing a segment by a byte.  Because of this I used indent
level as part of the scripting language.  Got beaten to a pulp by other folks
in the group about it and had to waste a few precious bytes processing curly
braces instead.  So I'm too scarred to be able to use Python without cringing.

Separate from this, I think that the whole 80 column thing is a bit silly.
I have used 132 as by default for a long time now.  Would go wider but just
because I have always found it worthwhile spending money on the best monitors
doesn't mean that everyone else can.  Everything including my laptop is now
a UHD monitor which rocks!

I feel that longer lines work better than one-character variable names.
And, longer lines are way more readable than wrapped lines.  I have never
been fond of the notion that code should be broken up into functions for the
purpose of keeping lines short; I feel that code should be broken up into
functions if it makes sense to do so, for example if the functions are used
more than once.  Writing for the limitations of the I/O device doesn't seem
to be a good paradigm.

In any case, I don't think that being an old UNIX person means that one has
to live in the past.  There was nothing magic about 80 columns; it was just
the technology of the time.  Technology has changed, so move on.

Jon


  reply	other threads:[~2017-11-10 19:05 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 [this message]
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
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=201711101905.vAAJ5SpV031420@darkstar.fourwinds.com \
    --to=jon@fourwinds.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).