case sensitivity redux (was Re: Language change and code breaks)

[Quinn Dunkan]

On Tue, 31 Jul 2001 11:24:18 +0200, Alex Martelli <aleaxit at yahoo.com> wrote:
>One aspect I haven't seen mentioned in this huge thread is the
>issue of visually impaired programmers.  Case sensitivity is an
>extra burden for such people (with whom I strongly empathize: my
>sight is still OK, sufficient to drive a car &c, but it's going
>downhill with time, and I must face the very real possibility
>that I'll be _seriously_ visually impaired a few years from now).

I don't see what case insensitivity in the language would give you over a
case-correcting editor, aside from you having to use the case correcting
editor.  This could be a major inconvenience (or none at all if it's already
your current editor), but I think it at least balances out with the
incovenience of everyone else having to switch to a case insensitive language.

I also can't imagine anyone seriously proposing that I, l, 1 and 0, O be
treated as the same characters in identifiers, but these cause problems for
everyone.  Just today someone was trying to get a network card working using
the lO driver.  Or was it the I0 driver?

>Think of a useful tool for such an audience, a special-purpose
>'screen reader' that will read out loud a snippet of Python code:
>what's the tool going to do about distinguishing upper and lower
>case?

The output tool would never distinguish case, and the input tool wouldn't
either, but if you typed or spoke an identifier that was the same as another
except case it would change it to match.

>For those of you who can't really empathize with other's issues
>and misfortunes, imagine being in a situation where you'd often
>need to have source code read out loud to you (e.g. over a
>phone), and/or you'd often want to dictate code (e.g. to some
>kind of voice-recognition, dictation-taking automatic system).
>What's case sensitivity giving you, that would compensate for
>the serious bother it causes in those situations?

In that situation case sensitivity is more trouble than it's worth.  But we
optimize for the common cases.

The main thing I see against case sensitivity is the stylistic ambiguity.
Some people use lower case class names, many use CamelCase, and some use
Initial_capitalization, and some even use smallTalkCase.  I think this is more
due to the fact that python has never had a clear style guidline.
Unfortunately now we have an int vs.  StringIO wart (i.e. built-in types
didn't follow class name conventions, presumably because classes didn't exist
back then).

But case sensitivity wouldn't have helped this at all, it would just make it
worse because then names could be not only inconsistent with each other, but
inconsistent with themselves.  Some people would consider it more consistent
to write Int and Str, many would use the old int and str, and probably some
would try to be consistent with whatever code they're modifying and do it both
ways (but of course do it their favorite way for their own code, and when the
two get integrated...).

-- irrelevant digression --->

Even though eiffel is case insensitive (although some compilers can be case
sensitive, which is not useful), it has a well defined "correct" naming style.
I like the idea of one simple rule you can easily follow if you want to be
"right".  It would also probably be easier on newbies if you could say "class
names always start with a capital letter, and the rest are always lowercase,
even acronyms" than "class names are usually capitalized on each word, and
sometimes acronyms are all caps, and sometimes small noise words are lower
case, and sometimes underscores are used, but often they're not, etc.  Or you
could say "all names are lowercase, period".  Actually, I like the last best,
since why should I care whether it's a RealClass or a factory_function?  Of
course local variables can be named anything you like, so math people can have
their H and h, but if they made both names externally visible, they'd have to
be more descriptive.