The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Larry McVoy <lm@mcvoy.com>
To: Will Senn <will.senn@gmail.com>
Cc: TUHS <tuhs@tuhs.org>
Subject: [TUHS] Re: Old documentation - still the best
Date: Sat, 1 Jun 2024 19:53:58 -0700	[thread overview]
Message-ID: <20240602025358.GC30164@mcvoy.com> (raw)
In-Reply-To: <5fe1dc07-7598-47c7-ac44-9e113d946cac@gmail.com>

Good writing is an art form.  I used to be awful, then I met Udi Manber
and did some work with him.  When I told him I struggled to write a good
paper (I was either a senior or a grad student, so not a lot of practice)
he was flabbergasted and said "writing papers is easy".  I said "do tell".
Here is what he told me:

A) You have to know what you are writing about, no amount of writing chops
will cover up a lack of knowledge.  
B) You have to have a good outline.  Organize what you want to tell
people and get it in the right order and with the right level of detail.

The outline is like the skeleton of a ship.  Once you have that, you are
just nailing on boards.  Same thing for a paper.  A good outline and 
good knowledge, now you are just typing and filling in the details.

But to get back to your point, Will, great writing is all of that but
just enough words, no more, no less.  You need skill to do that but you
also need to care about what you are writing, it's easy to write crap
if you don't care.  It's hard to write well, even with all skills, I
used to call writing being mentally constipated, the good stuff didn't
come out easily.

The early Unix papers were very well written.  The Bell Labs technical
journal papers about Unix are fantastic in my opinion.

On Sat, Jun 01, 2024 at 08:59:42PM -0500, Will Senn wrote:
> A small reflection on the marvels of ancient writing...
> 
> Today, I went to the local Unix user group to see what that was like. I was
> pleasantly surprised to find it quite rewarding. Learned some new stuff...
> and won the door prize, a copy of a book entitled "Introducing the UNIX
> System" by Henry McGilton and Rachel Morgan. I accepted the prize, but said
> I'd just read it and recycle it for some other deserving unix-phile. As it
> turns out, I'm not giving it back, I'll contribute another Unix book. I
> thought it was just some intro unix text and figured I might learn a thing
> or two and let someone else who needs it more have it after I read it, but
> it's a V7 book! I haven't seem many of those around and so, I started
> digging into it and do I ever wish I'd had it when I was first trying to
> figure stuff out! Great book, never heard of it, or its authors, but hey,
> I've only read a few thousand tech books.
> 
> What was really fun, was where I went from there - the authors mentioned
> some bit about permuted indexes and the programmer's manual... So, I went
> and grabbed my copy off the shelf and lo and behold, my copy either doesn't
> have a permuted index or I'm not finding it, I was crushed. But, while I was
> digging around the manual, I came across Section 9 - Quick UNIX Reference!
> Are you kidding me?!! How many years has it taken me to gain what knowledge
> I have? and here, in 20 pages is the most concise reference manual I've ever
> seen.
> 
> Just the SH, TROFF and NROFF sections are worth the effort of digging up
> this 40 year old text.
> 
> Anyhow, following on the heels of a recent dive into v7 and Ritchie's
> setting up unix v7 documentation, I was yet again reminded of the golden age
> of well written technical documents. Oh and I guess my recent perusal of
> more modern "heavy weight" texts (heavy by weight, not content, and many
> hundreds of pages long) might have made me more appreciative of concision -
> I long for the days of 300 page and shorter technical books :). In case you
> think I overstate - just got through a pair of TCL/TK books together
> clocking in at 1565 pages.
> 
> Thank you Henry McGilton, Rachel Morgan, and Dennis Ritchie and Steve Bourne
> and other folks of the '70s and '80s for keeping it concise. As a late to
> the party unix enthusiast, I greatly value your work and am really thankful
> you didn't write like they do now...
> 
> Later,
> 
> Will
> 
> 
> 
> 
> 

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

  reply	other threads:[~2024-06-02  2:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-02  1:59 [TUHS] " Will Senn
2024-06-02  2:53 ` Larry McVoy [this message]
2024-06-02  3:02 ` [TUHS] " Grant Taylor via TUHS
2024-06-02  3:12   ` Will Senn
2024-06-02  4:34     ` Grant Taylor via TUHS
2024-06-02  7:28     ` Scot Jenkins via TUHS
2024-06-03 16:47 ` Jim Capp
2024-06-03 16:52   ` Jim Capp
2024-06-08  1:58 ` Greg A. Woods
2024-06-02 15:52 Douglas McIlroy
2024-06-02 22:35 ` sjenkin

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=20240602025358.GC30164@mcvoy.com \
    --to=lm@mcvoy.com \
    --cc=tuhs@tuhs.org \
    --cc=will.senn@gmail.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).