The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: torek@torek.net (Chris Torek)
Subject: [TUHS] really Pottering vs UNIX
Date: Fri, 15 Sep 2017 12:10:18 -0700	[thread overview]
Message-ID: <201709151910.v8FJAIuv025809@elf.torek.net> (raw)
In-Reply-To: Your message of "Thu, 14 Sep 2017 22:42:55 -0700." <d92047c5a36c6e72bd694322acb4ff33e3835f9f@webmail.yaccman.com>

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

>... He made the point that a good program never dies, and many
>people will read it and modify it and try to understand it, and
>it's almost a professional duty to make sure that you
>make this as easy as possible for them.  

This is true of many good programs.

On the other hand, many programs are not good programs.  And it
winds up being true of many bad programs too. :-)

>Maybe a guild is a bit too stuffy, but being mentored by someone
>with their head screwed on straight, and consequently making a
>point to seek out excellent examples of the programming art and
>learn from them had a profound effect on my skill as a programmer
>and my career.

>I don't think I would have found this in a book or long midnight
>hours hacking away...

I'm not so sure: I learned some of this myself when working on my
Z80 assembler written in (some Microsoft variant of) BASIC.
Because it was such a terrible language, I had to keep a master
"notes" table giving each subroutine's line numbers, input
variables, and output variables (no call-by-anything in BASIC so I
had to stuff a register name like "BC" "DE" "HL" "IX" "IY" into
one global variable, "GOSUB 10100", and take the result back in
more global variables).

Nonetheless, it's true that seeing / recognizing "good" vs "bad"
software is a valuable pattern matching skill.  As with all such
things, the best trick I've ever discovered is not just to learn
from my own mistakes, but to learn from *other people*'s mistakes
too!

Chris


  parent reply	other threads:[~2017-09-15 19:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14 20:46 Clem Cole
2017-09-14 21:15 ` Bakul Shah
2017-09-15  1:24   ` Dan Cross
2017-09-15  1:39     ` Wesley Parish
2017-09-15  3:00     ` Kurt H Maier
2017-09-15  5:42     ` Steve Johnson
2017-09-15 13:26       ` Clem Cole
2017-09-15 19:10       ` Chris Torek [this message]
2017-09-15 19:19         ` Paul Winalski
2017-09-16 18:05         ` [TUHS] How do we learn about maintainability - was " Toby Thain
2017-09-16 19:12           ` [TUHS] Maintainability, Guilds, RMS, etc. all lumped into one Jon Steinhart
2017-09-17 18:50             ` Bakul Shah
2017-09-18 14:44           ` [TUHS] How do we learn about maintainability - was Re: really Pottering vs UNIX Clem Cole
2017-09-15  6:43     ` [TUHS] " Bakul Shah
     [not found] <mailman.1021.1505464341.3779.tuhs@minnie.tuhs.org>
2017-09-16 20:09 ` David
2017-09-18 14:17   ` Clem Cole
2017-09-18 14:23     ` David

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=201709151910.v8FJAIuv025809@elf.torek.net \
    --to=torek@torek.net \
    /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).