Hi All,
Anybody use variables/names longer than 31 character
and finds it really useful ?
Then please respond why, where, when.
I have folks here in comp.lang.fortran who will die claiming that they
- "never seen a well written, legible program
that uses any identifiers longer than 18-20 characters..".
- "long variables names are *hard* to read. And, you have to
read though all the characters of every instance of them...".
- "it degrades the legibility of a program to use identifiers that
can't be easily remembered...."
As a result, despite 90% of computer languages have long, very
long or 'infinite' identifiers, fortran folks seems plan to stay
with their 6...aargh ...sorry this was just not far ago... 31 character
limit intil year 3000.
cheers
00001111 <········@my-deja.net> writes:
> Hi All,
>
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
Several respondents to this (both on comp.lang.lisp and on other
language newsgroups) have run statistics and posted them, and indeed
the average maximum seems to be in the 30-40 range. I would like to
respond with a more philosophical point of view.
As stated by others, I also detested the 6 (and sometimes effectively 5)
character identifiers that Fortran allowed many years ago. It was
one of the rule which contributed to Fortran's being laughed at as
a "write-only" language.
I also think that in general, too-long names are just as hard to read
as too-short names, but for a different reason. When I see too-long
names it is usually because the programmer is trying to make up for
poor design and modularity by forcing a code commentary into the name
of the function or variable. How long is too-long? I'm not sure of
the correct number because I've never really counted, but I usually
know it when I see it. Sometimes a name is also too long if it doesn't
pretty-print nicely with its surrounding text, but that is a
lisp-specific thing...
But there is one other aspect that is lisp-specific (not specific to
the language, but to techniques used in lisp and lisp-like languages):
Identifiers, like code, can be created on the fly, and so concatenated
symbols may grow to huge lengths due to this concatenation. In a
sense, these identifiers are really defining a heirarchy, and the
components within them are individual identifiers, but such heirarchy
would be impossible to do with limitations on the lengths of names.
An example of this is Allegro CL's old def-c-type facility. C structures
were built and accessors generated by concatenating nested structure
references. So you might for example define an HP context array
based on /usr/include/ucontext.h and then in lisp code access it via
uc_mcontext.ss_wide.ss_64.ss_reserved (a single symbol in lisp, but
really representing many tokens).
Ironically, we moved away from this style, and went to more of a
component-based naming style in our newer def-foreign-type facility,
because it was easier to match the semantics of the foreign types
being emulated.
> Then please respond why, where, when.
> I have folks here in comp.lang.fortran who will die claiming that they
>
> - "never seen a well written, legible program
> that uses any identifiers longer than 18-20 characters..".
18-20 seems too small. Perhaps if the programmers were more used
to longer names and didn't have to worry about the 31 character limit,
they would get out of the habit of using abbreviations, and that
number might jump to at least 30.
> - "long variables names are *hard* to read. And, you have to
> read though all the characters of every instance of them...".
I agree that they are sometimes hard to read, but sometimes the very
length of the identifier causes it to stand out precisely because of
its length. This new dimension of distinguishability can actually
contribute to the program's readability.
> - "it degrades the legibility of a program to use identifiers that
> can't be easily remembered...."
This is a real hot-button for me, in any language. If an identifier
can't be remembered mnemonically for what it does, then it is misnamed.
That is precisely why short names can be so hard to read. Short or
long, if the name is not indicative of the usage of the name, it
degrades the legibility of the program.
> As a result, despite 90% of computer languages have long, very
> long or 'infinite' identifiers, fortran folks seems plan to stay
> with their 6...aargh ...sorry this was just not far ago... 31 character
> limit intil year 3000.
Six yesterday, 31 today, how many tomorrow?
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
"00001111" <········@my-deja.net> wrote in message ·····················@my-deja.net...
> Hi All,
>
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
>
> Then please respond why, where, when.
> I have folks here in comp.lang.fortran who will die claiming that they
>
> - "never seen a well written, legible program
> that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read. And, you have to
> read though all the characters of every instance of them...".
> - "it degrades the legibility of a program to use identifiers that
> can't be easily remembered...."
>
> As a result, despite 90% of computer languages have long, very
> long or 'infinite' identifiers, fortran folks seems plan to stay
> with their 6...aargh ...sorry this was just not far ago... 31 character
> limit intil year 3000.
>
IMHO, this kind of language bashing is unproductive. Most early compilers
suffered from `C programmer's disease' when it came to naming variables
and functions. Given the space limitations at the time, this is hardly
suprising. I haven't read the ANSI document for FORTRAN, but I'm guessing
that the 31 is the _minimum_ an implementation is required to allow and
use for distinction between names. In the FORTRAN implementations I used,
names over 6 were allowed in the program, but were truncated to 6 during
compiliation, the additional characters were more for the programmers
benefit for documentation purposes. Once you had gotten used to it,
it was only a problem when the code size was large and you were running
out of distinct, sensible variable names. 31 seems to be a reasonably
roomy space to work in, if you find yourself getting stuck for names,
you really do have a problem. :-)
Geoff
------------
From: http://www.rinkworks.com/stupid/cs_programming.shtml
At my previous job, we were porting a UNIX system to Windows NT using
Microsoft VC++. A colleague of mine, that was in the process of porting
his portion of the code, came to me, looking really upset.
Colleague: "Hey! I hate these Microsoft guys! What a rotten compiler!
It only accepts 16,384 local variables in a function!"
-------------
>>>>> "Geoff" == Geoff Summerhayes <·············@hNoOtSmPaAiMl.com> writes:
Geoff> IMHO, this kind of language bashing is unproductive. Most early compilers
Geoff> suffered from `C programmer's disease' when it came to naming variables
Geoff> and functions. Given the space limitations at the time, this is hardly
Geoff> suprising. I haven't read the ANSI document for FORTRAN, but I'm guessing
Geoff> that the 31 is the _minimum_ an implementation is required to allow and
Geoff> use for distinction between names. In the FORTRAN implementations I used,
Geoff> names over 6 were allowed in the program, but were truncated to 6 during
Geoff> compiliation, the additional characters were more for the programmers
Geoff> benefit for documentation purposes. Once you had gotten used to it,
Geoff> it was only a problem when the code size was large and you were running
Geoff> out of distinct, sensible variable names. 31 seems to be a reasonably
Geoff> roomy space to work in, if you find yourself getting stuck for names,
Geoff> you really do have a problem. :-)
According to the Fortran 77 standard (see http://www.fortran.com), a
variable name is 1 to 6 characters long. Although lots of F77
compilers allowed longer names, Fortran 77 also has the silly 72
character line length limit, and the first 6 characters are already
taken for the line number and continuation field.
So with a reasonable amount of indented code, long variable names make
Fortran code very hard to read when you get just one variable per
line, even when it's beautifully structured. :-)
Later versions of Fortran got rid of these limits, I think, and many
vendors extended their Fortran 77 compilers to have longer limits.
And I also hated compilers that allowed longer names but only kept the
first 6. I tended to forget that, and then spent unnecessary time
wondering why coolvar1 kept changing when ever coolvar2 changed. :-)
Ray
"Raymond Toy" <···@rtp.ericsson.se> wrote in message ···················@rtp.ericsson.se...
>
> According to the Fortran 77 standard (see http://www.fortran.com), a
> variable name is 1 to 6 characters long. Although lots of F77
> compilers allowed longer names, Fortran 77 also has the silly 72
> character line length limit, and the first 6 characters are already
> taken for the line number and continuation field.
>
> So with a reasonable amount of indented code, long variable names make
> Fortran code very hard to read when you get just one variable per
> line, even when it's beautifully structured. :-)
>
> Later versions of Fortran got rid of these limits, I think, and many
> vendors extended their Fortran 77 compilers to have longer limits.
>
> And I also hated compilers that allowed longer names but only kept the
> first 6. I tended to forget that, and then spent unnecessary time
> wondering why coolvar1 kept changing when ever coolvar2 changed. :-)
>
Blame the line lengths on the size of punch cards. 80 characters to
a card with 5 chopped off for the label and 1 for a continuation(!).
I doubt there was anyone who managed to escape completely unscathed
from the truncation of variable names, but people did have a tendency
to get paranoid about naming policy quickly. xrectangle as opposed to
rectanglex, for example. I actually miss it in a masochistic way, it
was my first language and I wrote in it for about 4 years before being
exposed to COBOL. Hmmm...make that 5 years, I detested COBOL, too much
work to do before actually writing code. :-)
Geoff
>>>>> "Geoff" == Geoff Summerhayes <·············@hNoOtSmPaAiMl.com> writes:
Geoff> "Raymond Toy" <···@rtp.ericsson.se> wrote in message ···················@rtp.ericsson.se...
Geoff> Blame the line lengths on the size of punch cards. 80 characters to
Geoff> a card with 5 chopped off for the label and 1 for a continuation(!).
Yes, so you really only had 66 (72 - 6) characters of actual code
space. But why 72 out of 80? I know the remaining 8 characters could
be used for sequence numbers or something, but why 8? (In college, I
actually preferred to use the card punch machine because I never had
to stand in line or fight any one for the few keypunch machines. I'd
be in and out before some people waiting for terminals every got a
terminal.)
Geoff> I doubt there was anyone who managed to escape completely unscathed
Geoff> from the truncation of variable names, but people did have a tendency
Geoff> to get paranoid about naming policy quickly. xrectangle as opposed to
Geoff> rectanglex, for example. I actually miss it in a masochistic way, it
Geoff> was my first language and I wrote in it for about 4 years before being
Geoff> exposed to COBOL. Hmmm...make that 5 years, I detested COBOL, too much
Geoff> work to do before actually writing code. :-)
Basic was my first language, closely followed by Fortran. Which
lasted for quite a few years, with a mix of Pascal and C. Several
years later I went full C, then a few years after that went to C++
because I wanted native complex numbers that I sorely missed from
Fortran. Somewhere along the way I was exposed to Emacs and lisp, and
got really going in Lisp some 6-7 years ago when I had to learn some
crypto stuff in hurry.
I wish I had known lisp earlier....
Ray
"Raymond Toy" <···@rtp.ericsson.se> wrote in message
···················@rtp.ericsson.se...
> >>>>> "Geoff" == Geoff Summerhayes <·············@hNoOtSmPaAiMl.com>
writes:
>
> Geoff> "Raymond Toy" <···@rtp.ericsson.se> wrote in message
···················@rtp.ericsson.se...
> Geoff> Blame the line lengths on the size of punch cards. 80
characters to
> Geoff> a card with 5 chopped off for the label and 1 for a
continuation(!).
>
> Yes, so you really only had 66 (72 - 6) characters of actual code
> space. But why 72 out of 80? I know the remaining 8 characters could
> be used for sequence numbers or something, but why 8? (In college, I
> actually preferred to use the card punch machine because I never had
> to stand in line or fight any one for the few keypunch machines. I'd
> be in and out before some people waiting for terminals every got a
> terminal.)
Had to go back in my library for this. The breakdown of a punch
card for Fortran is:
col 1 -Comment marker
cols 2 to 5 -Statement number
col 6 -Continuation marker
cols 7 to 72 -Statement
cols 73 to 80-Label- ignored by computer, available for programmers use
"Up to 19 continuation cards may be used with most computers, though
for small machines the number may be less than this. Since each card
can have up to 66 Fortran characters, this implies that the maximum
length for a Fortran statement is 1320 characters."
-from Computer Programming by Richard Murray-Shelley
>
> Basic was my first language, closely followed by Fortran. Which
> lasted for quite a few years, with a mix of Pascal and C. Several
> years later I went full C, then a few years after that went to C++
> because I wanted native complex numbers that I sorely missed from
> Fortran. Somewhere along the way I was exposed to Emacs and lisp, and
> got really going in Lisp some 6-7 years ago when I had to learn some
> crypto stuff in hurry.
>
> I wish I had known lisp earlier....
>
Actually the book I quoted from was the first book I'd read on
programming. Shame I didn't have access to a computer at the time. :-(
As luck would have it, when I reached high school, my first programming
course turned out to be in Fortran. I became aware of Lisp fairly early,
but avoided it due to the lack of an editor, trying to match parenthesis
by hand was excruciating. Now I'm playing catch up, I'd say 80% of my
recent book purchases involve Lisp. It is a beautiful language.
Geoff
Raymond Toy <···@rtp.ericsson.se> writes:
> And I also hated compilers that allowed longer names but only kept the
> first 6. I tended to forget that, and then spent unnecessary time
> wondering why coolvar1 kept changing when ever coolvar2 changed. :-)
Bad enough when a language does it but then some programmers follow the
language's lead. Cases in point:
* Don Woods' original adventure program looked only a the first 5 letters
of user input. This worked ok for things like
SOUTH
or
GET CHEST
but was really bad with
EXPLODE
and
EXPLORE
which it truncated to five characters (EXPLO) and gave some very peculiar
results for if you thought you were saying one of those words and it
thought you were saying the other. (I also seem to recall there was
a place where it actually needed to distinguish WATER from WATERFALL
and had some special kludge that let it win...)
* BayBank asked for 8character passwords on its bank cards a million years
ago, then wrote ATM programs that only compared the first four letters.
So if you password was 1234XZQY someone just had to guess the 1234.
This well-known bug survived the BankBoston takeover and wasn't fixed
until Fleet moved in and everyone who'd gotten used to typing only the
first four characters of their password suddenly found their accounts
didn't work because the system started requiring characters they hadn't
typed in years. (I often used to speculate that the bug was that the
password checker was in FORTRAN and someone had done IF (GIVEN.EQ.STORED)
(comparing the first word of a longer array GIVEN to the first word of a
longer array STORED) rather than iterating over the array; I guess the same
bug could have happened in C, though--anywhere that allows you to confuse
an array with its first element....
Better for the language to set a good example by itself supporting
rational decisions (e.g., supporting full names correctly) than to
give programmers the nod saying "being cryptic" and/or "dropping bits
at random" is acceptable style. In some cases, maybe that even causes
the language deisgners to realize that the users need better tools for
manipulating/comparing such data...
00001111 <········@my-deja.net> writes:
> Anybody use variables/names longer than 31 character and finds it really
> useful ?
Not all programs (especially in Lisp) are written by humans. Some are
written by other programs.
Imagine transformation software, that takes a program or program fragment as
input, and produces another program based on that. Forget about Lisp for a
second: the C macro preprocessor, or the C++ -> C "compiler" might be cases
of such things.
When you're writing such a piece of transformation software, you want to take
identifiers that humans have written, and automatically construct new legal
identifiers in the language based on the original ones. It's pathetic to have
to worry about identifier name length limits at such a time.
These cases feel very similar to adding fixnums together, where overflow might
result. Here we're having "overflow" in the length of automatically
constructed variable names. At least in the fixnum case, there's a machine
efficiency argument that the (e.g. C) folks can make. But with the length
of source code identifiers, there's really no benefit and occasional pain to
arbitrarily restricting their length.
-- Don
_______________________________________________________________________________
Don Geddis www.goto.com ······@goto.com
VP of Technology, GoTo Shopping Phone 650-403-2220
1820 Gateway Drive, Suite 360, San Mateo, CA 94404 Fax 650-403-2201
Are people more violently opposed to fur rather than leather because it's much
easier to harass rich women than motorcycle gangs?
Hello!
In article <··············@jedi.tesserae.com>,
Don Geddis <······@goto.com> wrote:
>[...]
>These cases feel very similar to adding fixnums together, where overflow might
>result. Here we're having "overflow" in the length of automatically
>constructed variable names. At least in the fixnum case, there's a machine
>efficiency argument that the (e.g. C) folks can make. But with the length
>of source code identifiers, there's really no benefit and occasional pain to
>arbitrarily restricting their length.
In ancient times, there *were* an argument for limited identifier lengths:
the core the compiler uses during compilation.
However, for usual nowadays computers, that shouldn't really matter.
Kind regards,
Hannah.
00001111 wrote:
>
> Hi All,
>
> Anybody use variables/names longer than 31 character
> and finds it really useful ?
I don't know about *really-useful* but I know I occasionally use them.
I'm sure I could live with a 31 character limit for names, but it is
nice not to have to worry about it.
>
> Then please respond why, where, when.
I just checked a program of mine. It has 150 symbols I defined (not counting
local variables whose length, I admit, tend to be more parsimonious),
here are the statistics on symbol length:
MAX 37
MEAN 13
MEDIAN 11
MIN 2
I would guess it to be pretty representative of the way I write code.
> I have folks here in comp.lang.fortran who will die claiming that they
>
> - "never seen a well written, legible program
> that uses any identifiers longer than 18-20 characters..".
> - "long variables names are *hard* to read. And, you have to
> read though all the characters of every instance of them...".
> - "it degrades the legibility of a program to use identifiers that
> can't be easily remembered...."
Here are just a few of the longer names:
initialize-dc-huffman-encoding-tables
*ac-huffman-chrominance-values*
convert-image-rgb-to-ycbcr
write-quantization-tables
To be sure, the names could be reduced in lenght by using abbreviations,
e.g. init-dc-huff-enc-tbl instead of initialize-dc-huffman-encoding-tables
but I certainly don't see it as being more readable. I don't even want to
think about trying to constrain myself to 6 chars and be in any way
readable.
>
> As a result, despite 90% of computer languages have long, very
> long or 'infinite' identifiers, fortran folks seems plan to stay
> with their 6...aargh ...sorry this was just not far ago... 31 character
> limit intil year 3000.
I remember writing FORTRAN years ago on my first job out of college. I remember
being *very* frustrated by having only 6 chars for names. And when maintaining
other peoples programs, it was a pain trying to understand the meaning of
the variables.
"Christopher J. Vogt" <····@computer.org> writes:
Warning: Gratuitous statistics ahead.
> 00001111 wrote:
> >
> > Hi All,
> >
> > Anybody use variables/names longer than 31 character
> > and finds it really useful ?
>
> I don't know about *really-useful* but I know I occasionally use them.
> I'm sure I could live with a 31 character limit for names, but it is
> nice not to have to worry about it.
>
> >
> > Then please respond why, where, when.
>
> I just checked a program of mine. It has 150 symbols I defined (not counting
> local variables whose length, I admit, tend to be more parsimonious),
> here are the statistics on symbol length:
> MAX 37
> MEAN 13
> MEDIAN 11
> MIN 2
> I would guess it to be pretty representative of the way I write code.
I did the same with a package of mine, which counting all symbols,
contains 290 identifiers. They break down like this:
N 290
MIN 1
MEAN 14.54
MEDIAN 15
STDDEV 7.24
MAX 37
Furthermore, it contains:
Symbols of length >= 5: 261
Symbols of length >= 10: 210
Symbols of length >= 15: 155
Symbols of length >= 20: 70
Symbols of length >= 25: 23
Symbols of length >= 30: 5
The 5 symbols >= 30 characters are:
+MAXIMUM-SAFE-MIME-TOKEN-LENGTH+ 32
PARSE-CONTENT-DISPOSITION-STRING 32
+MAXIMUM-SAFE-HTTP-METHOD-LENGTH+ 33
MAKE-MULTIPART-ENTITY-ITERATOR-FUN 34
GET-ERROR-RESPONSE-CLASS-USING-SERVER 37
As can be seen, the second to last one should really be
MAKE-MULTIPART-ENTITY-ITERATOR-FUNCTION 39
And thus even longer.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> N 290
> MIN 1
> MEAN 14.54
> MEDIAN 15
> STDDEV 7.24
> MAX 37
> [...]
> The 5 symbols >= 30 characters are:
>
> +MAXIMUM-SAFE-MIME-TOKEN-LENGTH+ 32
> PARSE-CONTENT-DISPOSITION-STRING 32
> +MAXIMUM-SAFE-HTTP-METHOD-LENGTH+ 33
> MAKE-MULTIPART-ENTITY-ITERATOR-FUN 34
> GET-ERROR-RESPONSE-CLASS-USING-SERVER 37
Various thoughts:
(a) Lisp symbols are often somewhat self-documenting, Fortran's aren't
much at all unless you have a secret decoder ring. It is true that
the IMSL FORTRAN library I used to work with tried to consistently
name its routines so you could look at something named LEQT1F and
have half a chance of knowing something about it... but there's a
limit to what you can pack into short names...
(b) Heavily used symbols are fine short, since their mere use refreshes
their meaning. Less-used symbols both need more explication and
need to occupy a namespace less likely to intrude on longer-term ones.
So "i" is a fine name for an iteration variable, but not a fine name
for the largest machine integer, which we call "most-positive-fixnum".
Since the longer names are less often used, it's easy to tolerate their
length.
(c) As a point of style, I subscribe to the rule first popularized for
the Lisp Machine (I think maybe by Dave Moon) saying that "there are many
abbreviations for something, but only one correct spelling". Once you
start abbreviating little-used terms, it becomes hard to remember.
Was it mkblk or mkblock or makeblk or make-block? Easier to just
subscribe to a consistent style rule.
(d) Spelling words out makes there be half a chance that apropos will work.
You may have decided you will consistently use "mk" for "make", "inz"
for "initialize" and "clz" for "close" in a 6-character system, but
will a new person on your team? How long will it take them to decipher
your theory? Lisp is built around APROPOS, and it works best if you
put morphemes into your terms that allow users to quickly find them.
(e) My recollection of Fortran is that it has no namespacing, so it might be
fair when thinking of Lisp's symbol length to count the package name as
well to get a true sense for the length of the symbols we use.
I frequently find myself typing things like:
(COM.HYPERMETA.HTTP.SERVER:START-HTTP-SERVER)
Since I usually do it from a foreign package, that's a 43-char long
function name.