Hi Zack,
At 2023-11-27T13:35:01-0500, Zack Weinberg wrote:
> On Mon, Nov 27, 2023, at 11:59 AM, G. Branden Robinson wrote:
> > At 2023-11-27T16:08:17+0100, Alejandro Colomar wrote:
> >> On Mon, Nov 27, 2023 at 09:33:56AM -0500, Zack Weinberg wrote:
> >> > [English pedant mode on]
> >> >
> >> > "Concatenate" is the correct term; "catenate" means something
> >> > completely different, probably "hang between two posts like a
> >> > chain". You can't chop prefixes off a Latinate word and have it
> >> > still mean the same thing.
> >
> > In some cases, you can. Witness the case of
> > "flammable"/inflammable", which are synonymous.
>
> Yeah, and (after seeing Alejandro's reply) I did look up both
> "concatenate" and "catenate" and find that they are synonymous in
> English and both are attested from the 1600s.
>
> **But I had to look that up.**
That's not a bug. When we stop learning, our brains die.
> I cannot recall ever encountering the word "catenate" prior to this
> thread, and my knee-jerk reaction was "typo."
The patellar reflex is not a reliable guide to purposeful development.
> Based on actual experience trying, and mostly failing, to teach
> college undergraduates to read man pages,
I empathize with you here. I have a bit of background in teaching and a
bit more in man page composition. Over the years my emotional response
to being frustrated that I have to quote a man page to other software
professionals in an email or message board has evolved into relief that
I have material of reasonable quality to quote to people...when that
happens. Sometimes a person raises an issue and my internal Gilbert
Gottfried yells, "you FOOL![1] That's plainly documented in--wait, uh,
give me a second. Uh...sh*t, I need to write a patch to this man page."
> I believe someone new to English technical documentation would have a
> different, much more troublesome knee-jerk reaction: "There must be
> some subtle reason why this documentation is using an unfamiliar term
> 'catenate', instead of 'concatenate' that I already know." Followed by
> wasting a bunch of time trying to research that unfamiliar term, and
> when they find it's an exact synonym, adding another tick mark to
> their mental tally for "manpages are badly written and hard to
> understand."
I think your hypothesis is sorely in need of testing. My own feeling is
that unfamiliarity with standard English vocabulary is well down the
list of things that people find frustrating about man pages, if we take
the product of annoyance level times the number of people perceiving a
defect.
> > Man pages are specialized technical literature demanding a bespoke
> > vocabulary. Some employment of jargon is inescapable, even
> > necessary. In any case, "catenate" has ~50 years of attestation in
> > this domain alone, which constitutes approximately the entire
> > history of Unix discourse.
>
> This is no excuse. Specialized technical jargon is only appropriate
> when there is an actual difference in meaning. (Thus, your "open
> source" vs "free software" counterpoint is bogus.)
I offered them in a tongue-in-cheek effort at humor. I don't regard
"Emacs" and "vi" as synonymous, either. Also I know they'll take away
your GNU card if you claim "open source" and "free software"
equivalence.[2]
Analogously, "disenfranchise" and "disfranchise" are also synonymous,
and I prefer the latter to the former for the same reason, popularity be
damned.
> > Before undertaking to reach for dictionaries (online or otherwise),
> > many readers morphophonemically analyze them to see if they can
> > infer their meanings from familiar components.
>
> In grappling with general literature, yes. In grappling with
> technical writing, *no*, and again I am speaking from direct
> experience as an educator. Readers who encounter an unfamiliar word
> in technical documents will most probably assume that the word has a
> precise meaning that they must learn, and that they *cannot* deduce
> that meaning from context.
If that's the case, then our field is doing a crap job at terminology
selection. (Stop the presses, right?)
> If they can't find a definition -- and they might not even try looking
> in a general dictionary, since they may assume that the relevant
> definition is too specialized to appear there; also it seems to me
> that schoolchildren are not being taught how to use dictionaries
> anymore
Enough of them seem to be using urbandictionary.com that the concept
remains familiar.
> -- *they will give up on the entire document*.
>
> Yes, this is bad. It's an instance of learned helplessness, and it's
> going to take decades and major educational reform at the grade-school
> level to fix. But there's one thing we, authors of technical
> documents, can do about it right now, and that is embrace plain talk.
> For example, whenever there really is no difference of meaning, the
> most common word in general usage is the word that should be used.
Again I'm going to have to disagree with you. Where we can
morphologically simplify without loss of meaning, I think that fits a
meaning of "plain talk" that is reasonably robust across the many
cultural contexts in which English is used. Your popularity metric is
vulnerable to sampling biases, particularly of the geographical sort.
And the plainer the talk, the more it is exposed to confounding regional
factors. When I moved to Australia, I had a frustrating experience at
the grocery store. I need to replace a light bulb. No sign anywhere in
the store helped me. While searching fruitlessly, I vaguely noted a
sign for "globes", and a thought that didn't quite reach the top of my
brain observed that globes are a damned weird thing to sell in a
grocery--but hey, it's Australia, maybe they need a _reminder_ that
they're hanging from the Earth's underbelly.[9] After a few more
minutes, these two threads joined.
Q: How many seppos does it take to screw in a light bulb?
A: What's gardening got to do with it?
> > In Unix culture, one will need to remain conversant with the term
> > "catenate" to know why cat(1) is not named "concat(1)". ;-)
>
> This is how I would teach it: 'concat' is too long for Kernighan and
> Ritchie's 1970s (or more precisely ASR33) tastes; 'con' was already in
> use as an abbreviation for 'console' (not in Unix itself, but in other
> contemporary OSes); and 'cat' is the next three letters of
> "concatenate". So that's what they picked.
Please don't teach that. There's a lot about it I find dubious.
1. Thompson was the primary human force for extreme terseness in Unix
culture, as far as I can tell from my readings in CSRC history.
(There were other technical and ergonomic forces driving it, like
low line speeds and the Fortran linker on the PDP-11--which C
initially re-used--being limited to six significant characters in
external identifiers.) Kernighan's own writings suggest that he
preferred clear labels over cryptic ones (see his _The Elements of
Programming Style_, with Plauger; _Software Tools_, also with
Plauger; and _The Unix Programming Environment_, with Pike). I
speculate that Thompson reasoned that he'd never need more than
26*26 commands anyway, so there was no reason to use an encoding
space larger than that to denote them.[3]
2. "ASR33" is a misleading misnomer in a couple of respects. You're
referring to a Western Electric Teletype Model 33. "ASR" is neither
a manufacturer nor a model, but a configuration option.
Specifically, "ASR" devices didn't have keyboards--just a paper tape
punch and reader--so they were not much used for Unix development.
"KSR" (keyboard send and receive) was the relevant configuration.
3. The Bell Labs CSRC didn't use Model 33s anyway. Western Electric
was also part of the Bell monopoly, and by late 1972 at the latest,
Labs personnel got to drive Cadillacs--the Model 37, and moreover
the ones used to produce Unix had the "Greek" character set
extension.[4] You will find references to both devices in the
Seventh Edition man pages, but the terminal driver was "tuned for
Teletype Model 37's"[5], and troff(1) named it as a supported
terminal device rather than the 33.[6] That said, Model 33s were
supported, and widely used at Unix installations outside the Labs.
4. Your deployment of "CON" to refer to the console device may be
anachronistic. I can't find any evidence that Multics used this
name for it. I'm not familiar enough with IBM's OS offerings over
the decades to be able to navigate online material about it. Many
people likely know that MS-DOS called its console device that, but
cat(1) is about a decade older than that product.[7][8]
Regards
Branden
[1] https://www.youtube.com/watch?v=2NpTmKmWdzk
[2] https://www.gnu.org/philosophy/open-source-misses-the-point.en.html
[3] I base this surmise on more than an attempt at mind reading. See
the first footnote on page 6 of McIlroy's "A Research Unix Reader".
https://www.cs.dartmouth.edu/~doug/reader.pdf
[4] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V3/man/man7/greek.7
[5] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man4/tty.4
[6] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man1/troff.1
[7] https://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man1/cat.1
[8] https://www.os2museum.com/wp/dos/dos-1-0-and-1-1/
[9] I'm teasing. I'd have loved an "upside-down" globe, not least as a
reminder that the melting of the Antarctic ice sheets will pour
inundating destruction down on most of us thanks to the superior
qualities of billionaires. I already had a counter-clockwise clock,
but didn't take it with me to Oz. Also the moon is wrong there.
Attachment:
signature.asc
Description: PGP signature
