On Mon, 19 Sep 2005 00:27:56 -0400, Anton Sherwood <bronto@...>
wrote:

> Andrew Dunbar wrote (Aug.03):
> > http://en.wikipedia.org/wiki/Talk:CamelCase#Early_Usenet_Sightings
> Lower on that page:
> It says that CamelCase originated as a C programming convention.
> Is this documented?

Having been a programmer, occasionally, I think it's safe to say a couple
of things. As the hardware and programming languages developed together,
what the programmer writes, inched closer to descriptive words, and often
short collections ("strings") of words. They were one heck of a lot easier
to learn and remember than almost arbitrary-seeming very-short collections
of letter and numbers (think DOS filenames, for examples of
primitiveness!). (As I think of it, programming commands and file name
formats progressively became somewhat more "humane".)

However, embedded spaces often made a mess in a program, because a space
code, much as it acts as a word separator, can also be very useful as a
separator in "low-level" commands, such as Linux/Unix commands. For
instance, "chmod 600 lilo.conf" (don't bother with what it means) uses
spaces to separate the command, itself ("chmod"); separates it from the
change you want to make (600) and from what file you want to change
("lilo.conf").

If you were to use the same parser to cope with a file name such as
"Working document.txt", the space would separate "Working" from the rest,
considering them as separate entities. Permitting file names with embedded
spaces required some (imho, long-delayed) common-sense advances in
programming; it seems that only recently were Linux and Unix freed from
such nuisances as "Working_Documents.txt", in which the [_] was one of a
few characters that substituted for space codes. Nevertheless, there is
still a need in some environments, afaik, to quote: "Working
documents.txt" is a required form, to prevent misinterpreting the embedded
space from being misinterpreted.

Trying to use multiword programming commands with embedded spaces seems,
even now (I might be out of touch), to be expecting more than one is
likely to find. I wouldn't expect to see "Get corner coords", but
"GetCornerCoords" would look completely believable. At that level, space
codes still serve as functional, not just trad. text-word separators.

(I do realize that there are a few Qalamite programmers, Richard
Wordingham, I think, for one; if I'm saying partial nonsense, I'll welcome
any corrections, either on-list or off-list. However, "[Off list]" really
gets my attention in my daily e-mail triage!)

Okay, more than enough about space codes as more than simple text-word
separators.

=

The other thought is that when one is defining a new programming language
(it happens rather often!), multiword commands such as "GetCornerCoords"
are really desirable to most people. As I said, dealing with embedded
spaces is just too messy; reliably determining the end of a command as the
parser looks left to right (does it, btw?) is apparently not practical,
although I don't know why. (Habit?)

So, one needs to consider other ways to maintain some degree of
readability, and embedded caps/InterCaps/CamelCase seems to be about the
easiest. "Get_corner_coords" surely could be made to work, I'd think, but
the [_] is less convenient to type.

===

It seems to me that this matter of a special significance of embedded
spaces in a command ("chmod 600 lilo.conf") and human reasons for
embedding caps to improve readability is a small part of the special
significance of typable characters in the computer field. It seems that
trailing paired parens., such as "arctan()" have a particular meaning; I
don'tthink it's necessary to explain what that is (it's a function, but
that's not helpful...).

Another item is a leading hyphen, such as "-v", or "-vv", parts of a
Linux/Unix command that say "tell me more about what's happening (or what
happened) when the computer did the command". The "v" is for verbose, and
more "v's" sometimes mean "tell me a lot -- give lots of detail". IIrc,
even "-vvv" is occasionally recorgnized. (This message probably rates two
"v's", maybe three.)

Yet another is [!], afaik spoken sometimes as "bang" when used a lot;
that's a usefully-concise single syllable. (There used to be a whole
delightful Victor-Borge-like collection in the New Hacker's
Dictionary/Jargon File, but, sadly, it seems to have been removed, or cut
back a lot, from recent revisions.)
That [!] usually signifies logical negation as a prefix; "!off" would mean
"not-off".

===

I've been meaning to mention two Unicode characters I find very useful in
personal handwritten notes, one being the graphic for space [␣], U+2423. I
use it to transcribe exactly some item of interest. I first became aware
of it in a Springer-Verlag textbook (ca. 1985) on the Modula-2 computer
language, where it was used extensively. I also use [⇀], U+21C0, one of
the harpoons, to simplify note-taking, when I abbreviate to save time, but
wish to transcribe accurately. This symbol, in my personal usage,
signifies that I did the abbreviating, and that the original was spelled
in full. It's the inverse of the trailing period/full-stop that ends a
traditional, literate abbreviation*. (Occasional Delights dept.: Both
these Unicode characters rendered in Opera e-mail; I've pushed i18n about
to the hilt in 98 SE.)
*Illiterate abbreviations: For instance, two-letter US postal (mostly
state) codes. I'm a holdout, maintaining against hopeless odds that a
double capital is not a literate abbreviation. Even the USPS has conceded
defeat, although when introduced, the codes were described as something
different from abbreviations. My .sig (leading dot is a long-standing Unix
convention, with its owen special significance -- routinely hides stuff
you don't bother with a lot) -- anyhow, my embedded .sig comment implies
that the .sig's contents is not a postal address. Any time I address an
envelope, I always use two-cap codes.

I run the risk of becoming a hated snob when I say that considering
two-letter codes to be abbreviations means a lack of something I call
"literary sense". In fact, they are part of what I think is the
present-day nascent counterpart to Vulgar Latin, although I'm woefully
ignorant about V.L. Although I'm tempted to call the nascent dialect by a
pejorative name, I've settled on Popular English. If I ever get off dead
center (steam engineer's term -- can't start the engine) and put up a Web
site (expect <nbodley.us>, concise and easy to remember), I'll have lots
of earmarks by which one can recognize the P.E. dialect.

===

Speaking of word separators, a neighbor who has responded to my pestering
about scrambled case and Turkish dotted capital İ's in hand-lettered
flyers still·uses·centered·dots·as·word·separators. I find what seems like
"cultural persistence" over perhaps more than a millennium (?) since they
were last used by literate people to be a notable phenomenon. Maybe
there's something subtly satisfying about making a mark as a word
separator.

My regards to all, with apologies for overloading a message with various
topics,

--
Nicholas Bodley /*|*\ Waltham, Mass. (Not "MA")
The curious hermit -- autodidact and polymath
Opera browser 8.02 -- E-mail, too.