Lorinda Cherry, a long-time member of the original Unix Lab
died recently. Here is a slightly edited reminiscence that
I sent to the president of the National Center for Women and
Information Technology in 2018 when they honored her with
their Pioneer in Tech award.
As Lorinda Cherry's longtime colleague at Bell Labs, I was
very pleased to hear she has been chosen for the NCWIT Pioneer
Award. At the risk of telling you things you already know,
I offer some remarks about her career. I will mainly speak of
things I saw at first hand when our offices were two doors
apart, from the early '70s through 1994, when Lorinda left
Bell Labs in the AT&T/Lucent split. Most of the work I describe
broke new ground in computing; "pioneer" is an apt term.
Lorinda, like many women (including my own mother and my wife),
had to fight the system to be allowed to study math and science
in college. She was hired by Visual and Acoustics Research
at Bell Labs as a TA--the typical fate of women graduates,
while their male counterparts were hired as full members of
technical staff. It would take another decade for that unequal
treatment to be rectified. Even then, one year she received
a statement of benefits that explained what her wife would
receive upon her death. When Lorinda called HR to confirm that
they meant spouse, they said no, and demanded that the notice
be returned. (She declined.) It seemed that husbands would not
get equal treatment until AT&T lost a current court case. The
loss was a foregone conclusion; still AT&T preferred to pay
lawyers rather than widowers, and fought it to the bitter end.
Lorinda moved to my department in Computing Science when
the Unix operating system was in its infancy. Initially she
collaborated with Ken Knowlton on nascent graphics applications:
Beflix, a system for producing artistically pixillated films,
and an early program for rendering ball-and-stick molecular
models.
She then joined the (self-organized) Unix team, collaborating
on several applications with Bob Morris.
First came "dc", an unlimited-precision desk calculator,
which is still a Unix staple 45 years on. Building on dc,
she would later make "bc", which made unlimited precision
available in familiar programming-language notation and became
the interface of choice to dc.
Then came "form" and "fed", nominally a form-letter generator
and editor. In fact they were more of a personal memory
bank, a step towards Vannevar Bush's famous Memex concept--an
interesting try that didn't pay off at that scale. Memex had to
sleep two more decades before mutating into the Worldwide Web.
Lorinda had a hand in "typo", too, a Morris invention that
found gross spelling mistakes by statistical analysis. Sorting
the words of a document by the similarity of their trigrams
to those in the rest of the document tended to bring typos to
the front of the list. This worked remarkably well and gained
popularity as a spell-checker until a much less interesting
program backed by a big dictionary took over.
Taken together, these initial forays foretold a productive
computer science career centered around graphics, little
languages, and text processing.
By connecting a phototypesetter as an output device for Unix,
Joe Ossanna initiated a revolution in document preparation. The
new resource prompted a flurry of disparate looking documents
until Mike Lesk brought order to the chaos by creating a macro
package to produce a useful standard paper format.
Taking over from Lesk, Lorinda observed the difficulty of
typesetting the mathematics (which the printing industry counted
as "penalty copy") that occurred in many research papers,
and set out to simplify the task of rendering mathematical
formulas, Brian Kernighan soon joined her effort. The result
was "eqn", which built on the way people read formulas aloud
to make a quite intuitive language for describing display
formulas. Having pioneered a pattern that has been adopted
throughout the industry, eqn is still in use forty years later.
Lorinda also wrote an interpreter to render phototypesetter
copy on a cathode-ray terminal. This allowed one to see
typeset documents without the hassle of exposing and developing
film. Though everyone has similar technology at their fingertips
today, this was genuinely pioneering work at the time.
You are certainly aware of Writers Workbench, which gained
national publicity, including Lorinda's appearance on the Today
Show. It all began as a one-woman skunk-works project. Noticing
the very slow progress in natuaral-language processing, she
identified a useful subtask that could be carved out of the
larger problem: identifying parts of speech. Using a vocabulary
of function words (articles, pronouns, prepositions and
conjunctions) and rules of inflection, she was able to classify
parts of speech in running text with impressive accuracy.
When Rutgers professor William Vesterman proposed a
style-assessing program, with measures such as the frequencies
of adjectives, subordinate clauses, or compound sentences,
Lorinda was able to harness her "parts" program to implement
the idea in a couple of weeks. Subsequently Nina MacDonald,
with Lorinda's support, incorporated it into a larger suite
that checked and made suggestions about other stylistic issues
such as cliches, malapropisms, and redundancy.
Another aspect of text processing that Lorinda addressed was
topic identification. Terms (often word pairs) that occur with
abnormal frequency are likely to describe the topic at hand. She
used this idea to construct first drafts of indexes. One
in-house application was to the Unix manual, which up until
that time had only a table of contents, but no index. This
was a huge boon for a document so packed with detail.
In her final years at Bell Labs, Lorinda teamed up with AT&T
trouble-call centers to analyze the call transcripts that
attendants recorded on the fly--very sketchy prose, replete
with ad-hoc contractions and misspellings. The purpose was
to identify systemic problems that would not be obvious from
transcripts considered individually. When an unusual topic
appeared at the same time in multiple transcripts, those
transcripts were singled out for further study. The scheme
worked and led to early detection of system anomalies. In one
case, it led AT&T to suspend publication of a house organ that
rubbed customers the wrong way.
Lorinda was not cut from the same mold as most of her
colleagues. First she was a woman, which meant she faced
special obstacles. Then, while there were several pilots
among us, there was only one shower of dogs and only one car
racer--moreover one who became a regional exec of the Sports
Car Club of America. For years she organized and officiated
at races as well as participating.
Lorinda was always determined, but never pushy. The
determination shows in her success in text analysis, which
involves much sheer grit--there are no theoretical shortcuts
in this subject. She published little, but did a lot. I am
glad to see her honored.
Doug McIlroy
The one I remember using in the 80s was called "fep" written by
Kazumasa Utashiro of Software Research Associates. It was probbaly posetd
posted to comp.sources.unix usenet group.
-Brian
Chet Ramey wrote:
> On 2/20/22 4:19 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> > Chet Ramey writes:
> >
> >> It always seemed like it would have been just the thing to implement as a
> >> tty streams module, but research Unix went in a different direction.
> >
> > I'm really surprised nobody has implemented a basic readline as a
> > tty line discipline by now. I was poking around the OpenBSD NMEA
> > line discipline code a few weeks ago and thinking it shouldn't be
> > that hard to do.
>
> It's not that hard. The complexity is in how sophisticated you want to get
> with redisplay and whether you want to allow user-specified key bindings.
>
> > Did anyone think about doing this in the past? If yes, what made you
> > decide against doing it? (Or a streams implementation, for that matter.)
>
> There have been several implementations (I never did one). I suspect that
> the people who were in a position to integrate that functionality into
> distributed kernels were not supportive, or the code didn't get to them
> at the right time.
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
On Feb 19, 2022, at 8:11 AM, Clem Cole <clemc(a)ccc.com> wrote:
>
>
> On Sat, Feb 19, 2022 at 11:04 AM Steve Nickolas <usotsuki(a)buric.co> wrote:
>> Apparently Bourne was heavily into ALGOL,
> That's sort of an understatement. I believe that when he was at Cambridge, he was one of the people that helped to take the Algol-X proposal and turned it into the Algol-68 definition. I also believe he worked on their famous implementation of same.
Some of you may be interested in this “A history of Algol68” paper:
https://dl.acm.org/doi/pdf/10.1145/234286.1057810
The author, Charles H Lindsey, still occasionally posts on comp.lang.misc
about Algol68. Among other things Bourne was a coauthor of Algol68C,
a portable implementation of Algol68.
Rob Pike:
I did the same to adb, which turned out to have a really good debugger
hidden under a few serious bugs of its own, which I fixed.
=====
Memories.
Was it you who replaced ptrace with /proc in adb, or did I do that?
I do remember I was the one who took ptrace out of sdb (which a
few 1127-ers, or perhaps 112-ers on alice and rabbit still used).
After which I removed ptrace from the kernel, and from the
copy of the V8 manual in the UNIX room. Conveniently ptrace
occupied two facing pages; I glued them together.
I also later did some work to try to isolate the target-dependent
parts of adb and to make them work in host-independent ways--e.g.
assembling ints byte-by-byte rather than assuming byte order--to
make it easier to make a cross adb, e.g. to examine PDP-11 or
68K core dumps on a VAX.
I miss adb; maybe it's time to revive it, though these days I'd
be tempted to rewrite it in Python so I could just load the right
module at runtime to pick the desired target.
Norman Wilson
Toronto ON
Second half of the 1980-tish when the computer division of Philips
Electronics started on their own Motorola M68010 / UNIX System V.3 (don't
remember for sure I'm afraid) they used a syntax.h with macros similar to
mac.h. Only I understand it's more Pascal like. Appended the 1987 version I
found in my archive.
Cheers,
rubl
--
The more I learn the better I understand I know nothing.
I have been poring through the v7 source code lately, and came across an
oddity I would like to know more about. Specifically, in sh. The code
for sh is c, but it makes *extensive* use of of macros, for example:
/usr/src/cmd/sh/word.c
...
WHILE (c=nextc(0), space(c)) DONE
...
The macros for sh are defined in mac.h:
/usr/src/cmd/sh/mac.h
...
#define BEGIN {
#define END }
#define SWITCH switch(
#define IN ){
#define ENDSW }
#define FOR for(
#define WHILE while(
#define DO ){
#define OD ;}
#define REP do{
#define PER }while(
#define DONE );
...
I can read the resultant code through the lens of my experience coding
c, but I'm curious why the macros and how this came about? In v6, the sh
source is straight up c. Is there a story behind it worth knowing?
Thanks,
Will
I was just reminded of this and thought others might enjoy reading it...
Customer Review
https://www.amazon.com/gp/customer-reviews/R2VDKZ4X1F992Q/
> PING! The magic duck!
> Using deft allegory, the authors have provided an insightful and intuitive explanation of one of Unix's most venerable networking utilities. Even more stunning is that they were clearly working with a very early beta of the program, as their book first appeared in 1933, years (decades!) before the operating system and network infrastructure were finalized. ...
-r
Perhaps the best irrefutable source for Lorinda's contribution
to dc is that cited by https://en.wikipedia.org/wiki/Lorinda_Cherry?
It is, by the way, Doug's A Research UNIX Reader. Those who
subscribe to this list and haven't read it ought to do so; it's
full of tidbits of history.
Norman Wilson
Toronto ON
All,
1. I have a physical copy of the V7 UPM published by Holt, Rinehart and
Winston (HRW) from 1983 (2 volume phone book). In it, there is a C
Reference Manual (pp. 247-277, reprinted with minor changes from the
first C book by K&R and including a Recent Changes to C addendum). I
also have a PDF that was supposedly created from sources that has a C
Reference Manual in it, but, in /usr/doc/cman, there's an inscription
that reads, "Sorry, but for copyright reasons, the source for the
C Reference Manual is not distributed." and the one in the pdf appears
to be identical to the one in the V6 UPM (which I have a print-on-demand
version of). Are the *roff sources (or a clean PDF) available for the
reprint? I have located a PDF copy of the HRW edition, but it's got the
usual deficiencies of being a scanned copy.
2. In same manual, there is an article entitled, UNIX Programming --
Second Edition by K&R. Where is the first edition located? It isn't in
the V6 UPM.
Regards,
Will
