Computer Old Farts Forum
 help / color / mirror / Atom feed
From: clemc at ccc.com (Clem Cole)
Subject: [COFF] [TUHS] Algol 68 and Unix (was cron and at ...)
Date: Thu, 17 Dec 2020 10:22:39 -0500	[thread overview]
Message-ID: <CAC20D2M7Vs9m6_tedQYYfPG9dOS0GbACLkeN7kJRTEZFSBE5VQ@mail.gmail.com> (raw)
In-Reply-To: <20201217143558.GD13268@mcvoy.com>

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

Moving to COFF since this is really not UNIX as much as programming
philosophy.

On Thu, Dec 17, 2020 at 9:36 AM Larry McVoy <lm at mcvoy.com> wrote:

> So the C version was easier for me to understand.  But it sort of
> lost something, I didn't really understand Steve's version, not at any
> deep level.  But it made more sense, somehow, than the C version did.
>
 I'm not too hard on Steve as herein lies the dichotomy that we call
programming.   Looking back the BourneGOL macros were clearly convenient
for him as the original author and allow him to express ideas that he had
well in his source.  They helped him to create the original and were
comforting in the way he was used to.   Plus, as Larry notes, the action of
transpiling loses that (BTW -- look some time at comments in the C version
of advent and you can still vestiges of the original Fortran).

But the problem is that when we create a new program, we can easily forget
that it might live forever[1] - particularly if you are a researcher trying
to advance and explore a set of ideas (which of course is what Steve was at
the time).  And as has been noted in many other essays, the true cost of SW
is in the maintenance of it, not the original creation.  So making
something easy to understand, particularly in the future without the
context, starts to become extremely attractive - particularly when it has a
long life and frankly impact beyond what is was originally considered.

It's funny, coming across BourneGOL help to validate/teach/glue into me an
important concept when programming for real -> the idea of "least
astonishment" or "social acceptance" of your work.  Just because you
understand it and like it might not be the same for your sisters and
brothers in the community.  There is no such thing as a private program.
The moment a program leaves your desk/terminal, it will be considered and
analyzed by others.

So back to the time and seeing BourneGOL for the first time, please
consider that in the mid-70s, I was coming to C from BLISS, SAIL, Algol-W
as my HLLs, so I was used to BEGIN/END style programming and bracketing
lining up 4 spaces under the next line with B/E in the same column.   The
White Book did not yet exist, but what would become 'one-true bracing
style' later described in K&R was used in the code base for Fifth and Sixth
Edition.  When I first saw that, it just looked wrong to me. But I was
coming from a different social setting and was using a different set of
social norms to evaluate this new language and the code written in it.

At some point  I took CMU's SW engineering course where we had to swap code
3 different times with other groups for the team projects, and I had come
to realize how important making things be understood by the next team was.
So, I quickly learned to accept K&R style and like Ron and Larry cursed
Steve a little.  And while I admire Steve for his work and both ADB and
Bourne Shell were tools I loved and used daily, when I tried to maintain
them I had wished that Steve had thought about those that would come after
- but I do accept that was not on his radar.

That lesson has served me well for many years as a professional and it's a
lesson I try to teach with my younger engineers in particular.  It's not
about being 100% easy for you now, it is about being easy for someone other
than you that has to understand your code in the future.   Simply use the
social norms of the environment you live and work ("do as the Romans" if
you will).   Even if it is a little harder now, learn the community norms,
and use them.

FWIW:  You can actually date some of my learnings BTW with fsck (where we
did not apply this rule).  Ted and I have come from MTS and
TSS respectively (*i.e.* IBM 360), which you remember from this first few
versions had all errors in UPPER CASE (we kept that style from the IBM
system -- not the traditional UNIX style). For many years after its success
and the program spreading like wildfire within the UNIX community, I would
run it on a system and be reminded of my failure to learn that lesson yet.

Clem

[1] BTW: the corollary to living forever, is that the worst hacks you do
seem to be the ones that live the longest.


ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20201217/cb9a76ee/attachment.htm>


       reply	other threads:[~2020-12-17 15:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKH6PiVLgdPVEGvGfyVAwNMz66=0huVyvRY90E+PduwG4ssVRQ@mail.gmail.com>
     [not found] ` <0EA02917-243E-4612-9F7E-D370EE0A7C2E@ronnatalie.com>
     [not found]   ` <20201217143558.GD13268@mcvoy.com>
2020-12-17 15:22     ` clemc [this message]
2020-12-17 15:50       ` [COFF] [SPAM] " lm
2020-12-17 17:57         ` imp
2020-12-17 18:00           ` lm
2020-12-17 18:30             ` [COFF] " 
2020-12-17 21:10             ` [COFF] [SPAM] " clemc
2020-12-18 14:43               ` lm
2020-12-18 15:46                 ` clemc
2020-12-18 17:41                 ` tytso
2020-12-18 19:24                   ` [COFF] " lm

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=CAC20D2M7Vs9m6_tedQYYfPG9dOS0GbACLkeN7kJRTEZFSBE5VQ@mail.gmail.com \
    --to=coff@minnie.tuhs.org \
    /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).