Language change and code breaks

[Bruce Sass]

On Wed, 18 Jul 2001, Guido van Rossum wrote:
> Roman Suzi <rnd at onego.ru> writes:
>
> > Windows is case-insensitive and thus "easy to use" only before one needs
> > to put web-pages on the real (UNIX) web-server. Then they understand all
> > the troubles with mised case, national-charset filenames, abbr~ted
> > filenames, local file references "C:\Mydocs\lalala", bmp-images etc.
>
> But it's still open for debate whether the problem here is Windows or
> Unix!  All programming languages and file systems used to be
> case-insensitive, until the designers of Unix and C decided that it
> was too much work to write and use a case-insensitive comparison
> routine.  It wasn't necessarily intended to be better, just easier to
> implement.  But times have changed, and that's a lousy excuse.

[Ok, I'll bite]

I don't see either Windows or Unix as the problem, they are just
different.  Problems only arise when you try to move between the two
possible worlds without a mapping function.

Mapping from Windows to Unix is trivial because case-insensitivity is
a subset of case-sensitivity; mapping from Unix to Windows with the
same 1:1 rule is impossible for the same reason... so you need a more
complicated mapping function, and will end up with a longer string of
characters in the Windows world than in the Unix world.  In the
very least, case-sensitive Unix can convey information more succinctly
than case-insensitive Windows, and I would go so far to say that Unix
is more expressive than Windows in this aspect.

I don't think the question is "whether the problem here is Windows or
Unix!", but rather...

Would a less expressive programming environment be better for programs
or programmers?

or if you prefer...

Would restricting program text to a subset of the available symbols be
better for programs or programmers?


The way I see it, going case-insensitive would be like ripping the
"shift" key out of the keyboard... such a move would not even be
considered in the real world; since programming is an effort to
simulate what goes on in the real world, and it seems to have been
found to take more than 36 symbols and some punctuation to express
real world ideas, it seems counter-productive to artificially restrict
the expressiveness of programmers.

Someone who has trouble figuring out case-sensitivity is going to have
a hard time with programming <period>.  If such a person is looking at
programming it will be within a restricted domain, so there should be
a language tailored to that audience and that domain.  Languages
intended for wider domains should be as expressive as the natural
language used to describe them.  There is nothing stopping a small
domain language from being a subset of that used in a larger domain,
but the requirements of the subset should not limit the expressiveness
of the whole language.

Exposing Python to a non-programmer, so the non-programmer can (say)
program their cell phone, does not require any aspect of Python be
designed to make things easy for the non-programmer... all that is
required is that a subset of Python can be made to appear to be
non-programmer friendly.

Maybe PyChecker should grow an option to check for mixed case
labels in programs, or perhaps rexec should be able to force
case-insensitivity.


- Bruce