🚀 go-pugleaf

> g-rh@cca.CCA.COM (Richard Harter)
> 	Something that may be relevant is that I have been trained as
> a mathematician.  I am much more comfortable with "let x be ..., y be
> ..., etc" and a body of work that uses x, y, etc, then with a style that
> use wordy names instead of x, y, etc.

I straddle the long-names/short-names camps, and Richard's comment here
is relevant to my rationale.  I use long names for data that has
extensive scope, and short names for data of local scope.  That is, I
might have a global entity number_of_errors, but if I were manipulating
it extensively, to calculate statistics or whatnot, I'd enclose the
relevant calculations in a scope that coins the nickname "ne".

My greatest gripe for most programming languages is that they don't
provide methods of coining restricted scope names by by-reference
binding (with optimization, of course).  My general programming style
has evolved so that I often write code consisting of a large windup
phase of let x ..., y ..., z ... and then conclude with a small, often
trivial evaluation (most of the work having been done in the "let"s).

Thus: I define the long names to the compiler, so that I'm not hiding
important information in comments, and then use what name-coining
facilities I can to make the expression of the needed calculations
compact and readily comprehensible, to both me and the compiler instead
of just to me.

> Another point is that the sort of code that I write and
> prefer to maintain is written in small modules -- short names are much
> more supportable if their scope is small.

Exactly.  I've found that my method allows the blending of small scopes
with small names with larger scopes with more mnemonic names cleanly.
Or, so it seems to me.

--
A program without a loop and a structured variable isn't worth writing.
                                        --- Alan J. Perlis
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw