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.** I cannot recall ever encountering the word "catenate" prior to this thread, and my knee-jerk reaction was "typo." Based on actual experience trying, and mostly failing, to teach college undergraduates to read man pages, 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." > 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.) > Zack also overlooks the process by which speakers and readers of a > language grapple with unfamiliar words that they encounter > unexpectedly. 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.[4] 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 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 -- *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. > 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. zw
