Case-sensitivity: why -- or why not? (was Re: Damnation!)

[James Logajan]

Fredrik Lundh wrote:
> 
> James Logajan <JamesL at Lugoj.Com> wrote:
> > > The Alice study only proves that users can memorize the case conventions
> > > used in a single specific library (in this case, the Alice environment), not that
> > > they won't get into trouble again when they stumble upon a library that uses
> > > different conventions.
> >
> > Slow learners until proven otherwise? What target IQ level would you
> > consider an appropriate cutoff?
> 
> given that I have to figure out the conventions of every new library, and
> end up getting NameErrors and AttributeErrors now and then, I suppose
> that target is 20-100 points above my own level.
> 
> not that the IQ level has anything to do with it -- any decent designer
> knows you'll get better results if you assume that users are very smart,
> but also very busy.

Frankly I'm amazed that so much is being written regarding this issue. If
what is being discussed is a completely new language, then there is nothing
to argue about. Case-insensitivity appears to be the way to go. If what is
being discussed is an incremental improvement, where backward compatible is
in some ways hoped for, then the issue is a non-starter and should not have
been brought up.

There is now a large body of production code and programmers conversant and
comfortable with the existing language, so I think GvR is being somewhat
irresponsible to suggest such drastic changes to Python. I would strongly
suggest he consider calling it something non-Pythonic (I think "Homer" came
up in another humorous context).

Also, I think that the conventions that you mention encompass much more than
case. I have found myself programming in Python, Java, C++ (standard strings
and ACE strings) and often have to try and remember what function or method
gives me the correct string length. Is it len(s), s.length(), s.size(),
s.len(), strlen(s), or something else? Even within a single language such as
C++ I find I have to check the class library for the proper convention. And
this has nothing to do with case per se. Besides, I find that cut-and-paste
tends to solve many of these problems.

Lastly, I did a quick scan of the Alice documentation and found that in some
spots it incorrectly used "Print ..." in some spots:

   To determine the length of a string, use the len() function:

    Print len(`This is a string.') 

                  17

    Incidentally, this works for arrays as well:

    Print len( [`This', `array', `has', `five', `elements'] ) 

and the correct "print ..." in others. And the method names were very long
and mixed case in some places:

Tree.SetTransparentTextureColor(White)

and all lower case in others:

     for o in scene.getchildren(all):
           o.setlightingstyle(lit)

So in one sense you are correct, but it strongly appears that it took some
pathological naming conventions and some misinformed documentation (print vs
Print) to draw out the problem. This wouldn't be the first dissertation
where the conclusion turned out to be incorrect.

That said, it would appear that a dynamically-typed language with
Python-like semantics should probably be case-insensitive since such errors
would often only be found at run-time. Statically-typed languages should in
general flag such errors at compile time, so this may be why it has not been
an issue in C/C++.

Nevertheless, I think it is much much too late to consider this change
creating a language that is even within the same family as Python. Why?
Because attribute names can no longer be implemented as string types.  A new
attribute-name class must be invented with case-insensitive comparison
operators. Backward compatibility will be made even more difficult. I
suspect the introspective aspects of the language may require further
reengineering than one may think.

> 
> > Also, if you wish to be taken more seriously, may I humbly suggest that you
> > avoid posting statements like the following:
> >
> > > Maybe non-geek programmers have better things to do with their time?
> 
> if you have problems with that statement, I suggest reading more HCI
> literature.  for a popular account, start with Cooper's "The Inmates are
> Running the Asylum".

About 20 years ago I did some intense reading on studies of human-computer
interfaces. (I assume that is what you mean by HCI?) People were full of
opinions but research studies were few and far between. "Double-blind" was
either a foreign concept or the money wasn't there to do it. Haven't read
Cooper's tome, but it does look like it is opinionated. How many
double-blind studies does he site? How many studies or any sort does he
site? I normally now avoid "popular works". Have you read any of Ben
Shneiderman's work? How about studies of the advantages and disadvantages of
stable development environments? You and GvR may find it profitable to
investigate those....