The ARPAnet reached four nodes on this day in 1969 (anyone know their
names?); at least one "history" site reckoned the third node was connected
in 1977 (and I'm still waiting for a reply to my correction). Well, I can
believe that perhaps there were only three left by then...
Hmmm... According to my notes, the nodes were UCSB, UCLA, SRI, and Utah.
-- Dave
We lost Dr. John Lions of this day in 1998; he was one of my Comp Sci
lecturers (yes, I helped him write The Book, and yes, you'll find my name
in the back).
-- Dave
As every computer programmer should know, John Backus was emitted in 1924;
he gave us the BNF syntax (he is the "B"), but he also gave us that
FORTRAN obscenity... Yeah, it was a nice language at the time; the
engineers loved it, but tthe computer scientists hated it (have you ever
tried to debug a FORTRAN program that somebody else wrote?).
Trivia: there is no way that FORTRAN can be described in any syntax; it is
completely ad-hoc.
-- Dave
I did just that. The National Bureau of Standards picked it up
in NBS Handbook 131, "Using ANS FORTRAN" (1980). It is expressed
in the same formalism that Burroughs used for Algol.
Doug
Thhis is a cross-posting from the groff mailing list, where
it was speculated that without roff there might be no Unix.
Old hands will be familiar with the story.
> Without roff, Unix might well have disappeared.
The patent department and the AT&T president's office are the
only in-house examples I know where Unix was adopted because
of *roff.
The important adoptions, which led Berk Tague to found
a separate Unix Support Group, were mainstream telephone
applications and PWB, a Unix-based IDE.
The first telephone application happened in the field. An
engineer in Charlotte, NC, heard of this cheap easily programmed
system and proposed to use it to automate the scheduling and
dispatch of maintenance on the floor of a wire center. Ken
visited to help get them started.
The first Bell Labs telephone application was automating
the analysis of central-office trouble reports. These had
been voluminous stacks of punched cards that reported every
anomaly detected in huge electromechanical switches. The Unix
application captured the data on line and identfied systematic
failures in real time.
The patent adoption was a direct result of Joe Ossanna's
salesmaship. Other early adopters were self-motivated,
but the generous support lent by Ken, Joe, and others was
certainly a tipping force that helped turn isolated events
into a self-sustaining movement.
Doug
Regardless of standards considerations, if there's any advice
that needs to be hammered into man authors, it's to be concise
and accurate, but not pedantic. As Will Strunk commanded,
"Omit needless words."
The most needless words of all are promotional. No man page
should utter words like "powerful", "extraordinarily versatile",
"user-friendly", or "has a wide range of options".
As another instance of the rule, it would be better to recommend
short subtitles than to help make them long by recommending
quotes. If anything is said about limited-length macros, it
would best be under BUGS.
As editor for v7-v10, I would not offer v7 as a canonical
model. It owed its use of boldface in SYNOPIS to the limited
number of fonts (Typically R,F,I,S) that could be on our
typesetter at the same time. For v9 we were able to follow
Kernighan and adopt a distinct literals font (L, which happened
to be Courier but could have been identified with bold had we
wished). I still think this is the best choice.
As for options, v7 is a very poor model. It has many pages
that describe options in line, just as v1 had done for its
few options (called flags pre-v7). By v10 all options were
displayed in a list format.
For nagging reasons of verbal continuity, the options displays
were prefaced by *needless words* like, "The following options
are recognized". A simple OPTIONS heading would be better.
Unfortunately, an OPTIONS heading would intrude between the
basic description and less important details that follow
the options. (I don't agree that it would come too closely
after DESCRIPTION; a majority of man pages already have even
shorter sections.) OPTIONS could be moved to the end of
DESCRIPTION. However, options may well be the biggest reason
for quick peeks at man pages; they should be easy to spot. It
has reasonably been suggested that OPTIONS should be a .SS
subsection. That might be followed by .SS DETAILS.
Doug
Grant:
Sorry, I mistook the context to be that you wrote something to write the
cf file / language for you.
===
Yep, evidently I didn't write clearly enough. Sorry about that.
(Which links us nicely back to the Subject: line, and
the concise clarity of the original manual-entry style!)
Norman Wilson
Toronto ON
WIlliam Cheswick <ches(a)cheswick.com> wrote:
> As for the configuration: when Norman Wilson moved to Toronto, he
> implemented some form of little language for configuring sendmail,
> treating it somewhat as an assembly language.
Bill's half right. I didn't invent a language; I used what was there.
I decided that the best way to deal with Sendmail's own configuration
language was to treat it as I would the assembly language for a
specialized, irregularly-designed microprocessor:
1. Understand as well as possible what the instructions actually do;
2. Write the simplest possible program that will get the job done;
3. Avoid extra layers of macros and so on that hide the details, because
that also hides the irregularities and makes it harder to understand
and debug;
4. By the same reason, don't just copy someone else's program that
does something complicated; write your own and do things simply.
Sendmail has plenty of design flaws (not just in the language), as
I'm sure Eric will acknowledge; but I think the biggest problem
people have had with it that most people copied the rather-complicated
sample configuration files shipped with the source rather than just
reading the manual, doing a few experiments to understand the behaviour,
and writing something simple.
On the other hand, I've never quite understood why so many people
treat device drivers as scary and untouchable, copying an existing
one and hacking it until it seems to work rather than understanding
what the device actually does and writing a simple program to control
it. So perhaps my brain just doesn't work normally.
Norman Wilson
Toronto ON
