Am I the only one who would love these extentions? - Python 3.0 proposals (long)

[Michael Geary]

When *I* have used case-insensitive languages, I have certainly
used various forms of capitalization to represent different types
of information, such as functions or constants. I am definitely
not alone in this approach, as I have learned it from reading
others' code.

In fact, mixed case names have always been very popular in the case-independent Pascal language.
Just look at any Apple code. The original Mac toolbox was written for Pascal and it's full of
MixedCaseNames.

Mixed case names with an initial capital letter are sometimes even called PascalCase.

http://www.google.com/search?q=Pascal+CamelCase

http://www.google.com/search?q=PascalCase

-Mike

 

[Douglas Alan]

Douglas Alan wrote:

This is the second ludicrous thing I've seen you write today. The
first was when you claimed Fredrik Lundh was "dead wrong" about the
use of tuples vs. lists, when your own view is in direct contradiction
to a very widely used convention in the Python programming world,
and supported by the FAQ entry and Guido's own views.

He was dead wrong to resort to ad hominem attacks in a debate over
programming aesthetics, for which my position is completely reasonable
and supported by other respected and accomplished software engineers.
The idea that people should resort to insults in this type of debate
is what is ludicrous, and I feel should be something of an
embarrassment to the Python community. I have met people who use Perl
and can't be convinced to try Python merely because they have gathered
an opinion that Python devotees are rude and unfriendly, and they'd
rather stick with the friendly Perl people. And who can blame them?
Who wants to join a community where unwarrented insults are the
norm?

When *I* have used case-insensitive languages, I have certainly used
various forms of capitalization to represent different types of
information, such as functions or constants. I am definitely not
alone in this approach, as I have learned it from reading others'
code.

If you are talking merely about putting constants, or somesuch, in all
upper case, then perhaps there is a significant minority that does do
this, but this doesn't typically open oneself up to numerous
opportunities for confusion, and might merely fall under my
description of using upper case for emphasis. Some people, for
instance, put all syntax keywoards in upper case for emphasis, though
personally, I find that practice to be ugly.

If, on the other hand, you are referring to using StudlyCaps (aka
CamelCase) in a case-insensitive language, then we have a serious
disagreement. I have read and written a lot of code in
case-insensitive languages, and I have never seen anyone code as you
say. There may certainly be people out there who do so (it sounds as
if such people have trouble breaking their case-sensitive habits), but
that doesn't mean it is a good idea. You can do whatever you want to,
but then you open yourself up to just the sort of maintenance
headaches that the previous respondent was complaining about.
Consequently, it would appear to be a bad idea.

*You* might not do so, but your opinions are clearly not held by
all other programmers,

Clearly not. The existence of Perl is conclusive proof of that.

nor perhaps even the majority, so please stop writing as though they
are.

Regarding tuples, I never said that I represented any kind of majority
-- only what is obviously correct to *me* and some other accomplished
people. Regarding case-insensitive languages, according to my
experience, I do represent the vast majority and to plain common
sense.

|>oug

 

[Douglas Alan]

In fact, mixed case names have always been very popular in the
case-independent Pascal language.

Yet another reason not to use Pascal! The only language silly enough
(at least in the original version) to have functions not be able to
accept array arguments of arbitray size.

|>oug

 

[Peter Hansen]

Regarding tuples, I never said that I represented any kind of majority
-- only what is obviously correct to *me* and some other accomplished
people.

Your statement that Fredrik was "dead wrong" when he asserted the
opposite could be interpreted to mean you didn't think it was just
your own opinion. You've now clarified that the "dead wrong" statement
was about his allegedly calling you names, not about his assertion that
you were incorrect in your view so clearly I misinterpreted you (quite
justifiably, I believe).

Regarding case-insensitive languages, according to my
experience, I do represent the vast majority and to plain common
sense.

At least we're agreed that it is not proven whether it is you or I
who is in the majority, and unless and until one of us does something
to prove it which is more rigorous than merely asserting the point,
we'll progress no further.

End of discussion from my point of view.

-Peter

 

[Lulu of the Lotus-Eaters]

|If you are talking merely about putting constants, or somesuch, in all
|upper case, then perhaps there is a significant minority that does do
|If, on the other hand, you are referring to using StudlyCaps (aka
|CamelCase) in a case-insensitive language, then we have a serious
|disagreement. I have read and written a lot of code in
|case-insensitive languages, and I have never seen anyone code as you

On the other hand, *I* have almost certainly read and written a lot more
code in case-insensitive langauges than Douglas Alan has... and I found
the use of case (both constants-in-caps and CamelCase) to be quite
pervasive. Certainly a large majority use the ALLCAP constant
convention. But a majority also use various mixed case conventions (not
always consistent between programmers and/or languages, however).

FWIW, doing the above is ALSO a GOOD idea, not just empirically true.

Yours, Lulu...

 

[Douglas Alan]

Douglas Alan <[email protected]> wrote previously:

|If you are talking merely about putting constants, or somesuch, in all
|upper case, then perhaps there is a significant minority that does do
|If, on the other hand, you are referring to using StudlyCaps (aka
|CamelCase) in a case-insensitive language, then we have a serious
|disagreement. I have read and written a lot of code in
|case-insensitive languages, and I have never seen anyone code as you

On the other hand, *I* have almost certainly read and written a lot more
code in case-insensitive langauges than Douglas Alan has... and I found
the use of case (both constants-in-caps and CamelCase) to be quite
pervasive. Certainly a large majority use the ALLCAP constant
convention. But a majority also use various mixed case conventions (not
always consistent between programmers and/or languages, however).

FWIW, doing the above is ALSO a GOOD idea, not just empirically true.

I certainly cannot speak as to whose experience of how the majority
programs, represents reality better, since neither of us is using a
statistically sound sampling method, but I *can* speak to whether it
is a good idea to use CamelCase in a type insensitive language:

It is clearly not! CamelCase gives you no advantage (except perhaps
to save a few charactes in your identifiers) to using identifiers with
underscores or dashes, and it has the significant disadvantage that
apparently different identifiers, such as "eaTime" and "eatIME", will
be confounded by the language. This is a sand-trap wating to snare
you, if you program this way in a case-insensitive language.

You will notice that CamelCase was extremely uncommon (if used at all)
before the advent of case-sensitive languages, and there is good
reason for this. It didn't make sense then, and it doesn't make sense
now! (In a case-insensitive language.)

|>oug

 

[Paul Rubin]

You will notice that CamelCase was extremely uncommon (if used at all)
before the advent of case-sensitive languages, and there is good
reason for this. It didn't make sense then, and it doesn't make sense
now! (In a case-insensitive language.)

The convention always annoyed me, but I think it was customary in the
old days of Smalltalk. When object-oriented programming became a fad
in the 80's, it spread into other languages from there.

 

[David Eppstein]

You will notice that CamelCase was extremely uncommon (if used at all)
before the advent of case-sensitive languages, and there is good
reason for this. It didn't make sense then, and it doesn't make sense
now! (In a case-insensitive language.)

The convention always annoyed me, but I think it was customary in the
old days of Smalltalk. When object-oriented programming became a fad
in the 80's, it spread into other languages from there.[/QUOTE]

This doesn't make sense to me as an explanation. Smalltalk didn't reach
much of a mass audience until Goldberg's book was published in 1983, and
other object-oriented languages (e.g. C++) did not immediately adopt
CamelCase (I see none in Stroustroup's 1986 C++ book). In the meantime,
CamelCase (with or without the initial capital) was certainly used prior
to 1983 in languages such as Pascal.

 

[Douglas Alan]

This doesn't make sense to me as an explanation. Smalltalk didn't reach
much of a mass audience until Goldberg's book was published in 1983, and
other object-oriented languages (e.g. C++) did not immediately adopt
CamelCase (I see none in Stroustroup's 1986 C++ book). In the meantime,
CamelCase (with or without the initial capital) was certainly used prior
to 1983 in languages such as Pascal.

Someone else in this thread claimed that CamelCase came to Pascal via
Apple. And we know that Apple was lapping at the time from the font
of Xerox Parc. This would explain how CamelCase made it from
Smalltalk to Pascal.

I used Pascal in the very late '70's and very early '80's, and I never
saw anyone use CamelCase in it. And now that David Epstein has jogged
my memory -- it is indeed in SmallTalk that I first saw people using
CamelCase, and, I must say, I was rather aghast.

IfCamelCaseWereAGoodIdeaEvenInACaseSensitiveLanguage,thenPeopleWouldWriteLike
ThisAllTheTime.

|>oug

 

[Paul Rubin]

Someone else in this thread claimed that CamelCase came to Pascal via
Apple. And we know that Apple was lapping at the time from the font
of Xerox Parc. This would explain how CamelCase made it from
Smalltalk to Pascal.

Yes, that sounds plausible to me. While Smalltalk may not have had a
mass audience pre-1983, hacker culture at the time centered around
academia and places like PARC, which didn't need mass audiences. The
MixedCase thing seemed cult-like even at the time, which fits in with
Apple taking it up.

 

[David Eppstein]

Someone else in this thread claimed that CamelCase came to Pascal via
Apple. And we know that Apple was lapping at the time from the font
of Xerox Parc. This would explain how CamelCase made it from
Smalltalk to Pascal.

I used Pascal in the very late '70's and very early '80's, and I never
saw anyone use CamelCase in it.

I still have Pascal code lying around from 1980-1982 that does use
CamelCase (with initial capital for variables and functions, without for
procedures). This would have been with Rutgers Pascal on the
DECsystem-20, so unlikely to have much Apple influence.

 

[rzed]

Someone else in this thread claimed that CamelCase came to Pascal
via Apple. And we know that Apple was lapping at the time from the
font of Xerox Parc. This would explain how CamelCase made it from
Smalltalk to Pascal.

I used Pascal in the very late '70's and very early '80's, and I
never saw anyone use CamelCase in it. And now that David Epstein
has jogged my memory -- it is indeed in SmallTalk that I first saw
people using CamelCase, and, I must say, I was rather aghast.

IfCamelCaseWereAGoodIdeaEvenInACaseSensitiveLanguage,thenPeopleWouldWr
iteLike

There's nothing about case standards that suggests that removing
spaces between lexical units is a good thing. In any event, it would
be preferable to
"IFCAMELCASEWEREAGOODIDEAEVENINACASESENSITIVELANGUAGE,
THENPEOPLEWOULDWRITELIKETHISALLTHETIME." in either a case-sensitive or
case-insensitive language.

The worst-case (as it were) scenario that I can remember happened when
I was working with PL/I on an IBM mainframe, using 3270 terminals.
This was a case-insensitive language, so some people adopted the
conventions others have mentioned (constants in ALL_CAPS, functions
and procedures in camelCase (sometimes) -- but some didn't. Some coded
with the terminal set to *display* all caps (which allowed typing in
lower case without being aware of it), and some didn't. Some of each
group modified the code of programmers from the other group, and when
the terminals displayed case as entered, the result was an unholy
hodgepodge of upper and lower case clumps of letters in the oddest
places imaginable. There was no apparent rhyme or reason to the case
changes, even though everyone was utterly systematic about how they
did their coding.

The reason people chose to mix their cases is that one-case code is
difficult to read. That's why alphabetic languages developed case
conventions in the first place; the cases contain information in
themselves.

 

[Tim Jarman]

On Sunday 07 Dec 2003 8:53 pm, Douglas Alan wrote:

[snip]

You will notice that CamelCase was extremely uncommon (if used at all)
before the advent of case-sensitive languages, and there is good
reason for this. It didn't make sense then, and it doesn't make sense
now! (In a case-insensitive language.)

|>oug

Er, I may be missing something, but why is this enthralling discussion taking
place in a newsgroup devoted to a case-*sensitive* language? Is this an
attempt to wind up the Martellibot or something?

 

[Douglas Alan]

Douglas Alan wrote:

There's nothing about case standards that suggests that removing
spaces between lexical units is a good thing.

Right -- removing spaces is not a good idea, because spaces aid in
readability. The traditional (i.e. pre-CamelCase) way of separating
words in indentifies was to use dashes or underscores. As in,

If-dashes-used-to-seperates-words-within-identifiers-were-a-good-idea-
then-everyone-would-write-like-this-all-the-time.

And they probably would, if there weren't able to use spaces. It's
much more readable than the CamelCase version.

In any event, it would
be preferable to
"IFCAMELCASEWEREAGOODIDEAEVENINACASESENSITIVELANGUAGE,
THENPEOPLEWOULDWRITELIKETHISALLTHETIME." in either a case-sensitive or
case-insensitive language.

That's for sure, but I don't think that that idea is on the table.
It's always been common, when not using CamelCase, to use dashes or
underscores.

The worst-case (as it were) scenario that I can remember happened when
I was working with PL/I on an IBM mainframe, using 3270 terminals.
This was a case-insensitive language, so some people adopted the
conventions others have mentioned (constants in ALL_CAPS, functions
and procedures in camelCase (sometimes) -- but some didn't. Some coded
with the terminal set to *display* all caps (which allowed typing in
lower case without being aware of it), and some didn't. Some of each
group modified the code of programmers from the other group, and when
the terminals displayed case as entered, the result was an unholy
hodgepodge of upper and lower case clumps of letters in the oddest
places imaginable. There was no apparent rhyme or reason to the case
changes, even though everyone was utterly systematic about how they
did their coding.

All the more reason to standardize on dashes or underscores.

The reason people chose to mix their cases is that one-case code is
difficult to read.

no it isn't. it isn't even difficult to read one-case english.

|>oug

 

[rzed]

[...]

The reason people chose to mix their cases is that one-case code is
difficult to read.

no it isn't. it isn't even difficult to read one-case english.

so you say, and you illustrate by showing one line.
but if instead you have a block of a lot of text,
or if you have code that is placed
in close proximity for line after line
you may have reason to think otherwise. i know
i did in the monocase pl/i world and i was not alone
in that; everyone else in the shop complained about
it from time to time. it is never an issue that a single
identifier is easier or more difficult to read in a single case;
it is an issue when the context is broader. a secondary issue
is that underscores require the use of the shift key on a
standard typewriter so they are no easier to enter than
upper case letters and they add no information that the
interspersed capitals do not. whether they make text easier
to read than camelcase stuff is a matter of opinion and is
based on what people are used to. i went from one form to
the other and had no trouble adjusting; it took very little time
for me to come to prefer camelcase. judging by its prevalence
in a big chunk of the coding world, others have managed to
make the same adjustment, and i would guess at least many
of them have the same preference.

 

[Douglas Alan]

Douglas Alan wrote:

so you say, and you illustrate by showing one line. but if instead
you have a block of a lot of text, or if you have code that is
placed in close proximity for line after line you may have reason to
think otherwise.

no, i really don't. all-lowercase text is perfectly easy to read. i
will grant that traditionally-cased english is a bit *easier* to read,
but that doesn't mean that all-lower-case english is *hard* to read.
i converse in email all the time with people who have apparently
removed the shift key from their computer, and i've never had much
reason to complain about it. unless they have it wired ON all the
time, in which case, i get very IRATE.

i know i did in the monocase pl/i world and i was
not alone in that; everyone else in the shop complained about it
from time to time. it is never an issue that a single identifier is
easier or more difficult to read in a single case; it is an issue
when the context is broader.

when the context is broader, you learn to use things like

#-----------------------------------------------------------------------------
# function FOO
#-----------------------------------------------------------------------------

and what-not to provide visual structure to your code. Which you should
do even when using camelCase.

a secondary issue is that underscores require the use of the shift
key on a standard typewriter so they are no easier to enter than
upper case letters

all the more reason that languages should use dashes, rather than
underscores, for this purpose. but my reasoning never had anything to
do with easy of typing -- only with ease of reading. camlCase is just
hard to read, and is a maintenance quagmire in a case-insensitive
language.

and they add no information that the interspersed capitals do not.

in a case-insensitive language, the dashes most certainly DO add
information, since there is no chance of confounding

myVar

and

mYvar

if you write

my_var

and

m_yvar

instead.

whether they make text easier to read than camelcase stuff is a
matter of opinion and is based on what people are used to.

i_really_don't_think_it_is_a_matter_of_opinion. i_think_it_is_a
matter_of_human_cognition, and_i'm_willing_to_bet_that_cognitive
psychology_experiments_would_prove_me_right, although_i_have_no_such
experiments_to_cite_at_the_moment.

IHaveBeenUsingCamelCaseEveryDayForAboutTenYearsNow,
andIStillFindItMuchMoreDifficultToReadThanTheAlternatives.
ItNoLongerMakesMeWantToHurlTheWayThatItUsedTo,ButEasyToReadItIsNot.

just compare the preceding two paragraphs for readability. that
should be all the proof one needs.

i went from one form to the other and had no trouble adjusting; it
took very little time for me to come to prefer camelcase.

a chaque son gout, but if you are using camelCase in a
case-insensitive language, i believe that you are still making a
serious mistake.

judging by its prevalence in a big chunk of the coding world, others
have managed to make the same adjustment, and i would guess at least
many of them have the same preference.

there's no accounting for taste, but i still think that they are
making an ergonomic mistake. people often prefer things for strange
reasons that have nothing to do with real ergonomics, but that doesn't
mean that they wouldn't be more efficient and produce code with fewer
bugs if they didn't use camelCase, especially in a case-insensitive
language. (just read some of tufte's books or "The Design of Everyday
Things" to see many examples in other domains of misguided but popular
designs that are counter to good ergonomics.) personally, i would
would look for work elsewhere if i were told that i had to use
camelCase in a case-insensitive language.

|>oug

 

[rzed]

[snip]

whether they [underscores] make text easier to read than camelcase stuff is a
matter of opinion and is based on what people are used to.

i_really_don't_think_it_is_a_matter_of_opinion. i_think_it_is_a
matter_of_human_cognition, and_i'm_willing_to_bet_that_cognitive
psychology_experiments_would_prove_me_right, although_i_have_no_such
experiments_to_cite_at_the_moment.

IHaveBeenUsingCamelCaseEveryDayForAboutTenYearsNow,
andIStillFindItMuchMoreDifficultToReadThanTheAlternatives.
ItNoLongerMakesMeWantToHurlTheWayThatItUsedTo,ButEasyToReadItIsNot.

just compare the preceding two paragraphs for readability. that
should be all the proof one needs.

I can see we won't agree about this. I find it much more distracting
to have interspersed underscores. So, while I agree that's all the
proof we need, I can't agree with you on what is proved.

a chaque son gout, but if you are using camelCase in a
case-insensitive language, i believe that you are still making a
serious mistake.

I couldn't agree more, there! But I was talking about switching to a
case-sensitive language.

In case-insensitive coding, I do believe it *could* be useful to adopt
case conventions for some purposes, but it's far too easy for
programmers with conflicting views on case to much with each other's
code, and the result is a mess.

It'll be interesting to see which way Python 3K goes, don't you think?

 

[Nick Vargish]

I have met people who use Perl
and can't be convinced to try Python merely because they have gathered
an opinion that Python devotees are rude and unfriendly, and they'd
rather stick with the friendly Perl people.

Who are they? I'll set them straight!

But seriously, I'm somewhat surprised that anyone would characterize
the Python community as being rude and unfriendly. Have they never
been to comp.object or rec.pets.cats?

Sure, I've had some less than happy encounters with folk here, but I
understood that the tone of the reply I got was in response to the
tone of my original post.

Nick (or should that be "|\|1c|<"? :^)

 

[Douglas Alan]

Douglas Alan wrote:

I'd go even further : identifiers longer than 6 characters are evil.

I assume you are joking?

|>oug

 

[Jarek Zgoda]

I assume you are joking?

Just think about typing all those identifiers... I thing the old
(pre-RPG/400) RPG should be treated as shining template. Nobody thinks
of programmers, like IBM thinks.