[Edu-sig] On case sensitivity

Kirby Urner pdx4d@teleport.com
Fri, 04 Feb 2000 10:43:17 -0800

At 01:20 PM 02/04/2000 -0500, you wrote:
>> >Why?  I've never seen any strong justification for case sensitivity other
>> >than backward-compatibility with some other language or library.
>> That's justification enough.  "Backward compatibility" in
>> this context means being able to write in that language,
>> even today.
>Perhaps, but you made the argument that case sensitive is how things *should

More just that's how things are.  Java isn't going to
change.  In my curriculum, Python is an on ramp into
the world of programming more generally.  Whether I 
like it or not, design decisions were made (no, I 
wasn't consulted).  I'd rather accept the status quo,
in this case, than use Python to tilt at wind mills.

>My understanding is that Guido looks at Python 2 as an opportunity to
>introduce a few incompatibilities to make the language a lot better, and
>programs that depend on case sensitivity *could* in theory be fixed

I like this as an option.  Kinda like MSFT Word and "IntelliSense"
-- always looking over my shoulder and being helpful (except 
sometimes we fight -- I reserve the right to _override_ any
stupid machine).

Sounds like a lot of good thinking has gone into the cs thread
already.  My two cents already given.

>> I don't insist that Chinese drop reliance on tonality
>> because "meaning through tone is difficult for the Western
>> ear".  Tone-sensitivity is here to stay as well -- if not
>> in Python :-D.
>If you did insist, they probably wouldn't pay much attention.  On the other
>hand, how many Westerners actually know Chinese?  If we are the Chinese in
>this analogy, and we want everyone to learn our language, we will get a lot
>farther by changing the language than by trying to change everyone else.

There's a billion of us and we'd have no hope of changing our
language.  Despite the reputation of Chinese authoritarianism,
there's no way committees "just decide" that tomorrow tone 
isn't going to matter.  Computer languages are a little less
"organic" but not a whole lot.  Python is somewhat unusual in
that there's this one guy named Guido overseeing it.  Other
languages have gotten away from their originators in large
degree (my own Xbase, for example).

My only thought re the Alice people is "hey, it's OK if your
program crashes sometimes because of cs issues.  Yes, it's
annoying, but don't let your whole attitude to programming
be colored by this little 'feature'.  As Miss Frizzle would
say:  make mistakes, get messy."  And when you go to China, 
don't give up if you say "screw!" instead of "please!" 
because of the tone thing.  xxxx happens.

>This analogy breaks down because there are a lot of Chinese speakers, and
>very few programmers.  The number of supporters of something doesn't predict
>it's value, but it DOES affect "conversion cost."  The cost of converting
>billions of people to think case sensitively exceeds the cost of converting
>all existing Python code.

You seem to assume that the default is to not be case sensitive.
But we DO know the difference between upper and lower case A (a).
A lot of time goes into this.  Kids know.  They don't need to
be patronized.  I find this bending over backwards to remove
case sensitivity to be patronizing, condescending.  It's not
a big deal, really.

>> The goal is to gradually erode this concept of OUR kind, versus
>> "normal" people.  There is no "they" versus "we" in the ideal
>> world for which CP4E strives.  No one gets to point the finger
>> at those "cockroach" others.
>This will not be accomplished by leaving the language and tools alone and
>converting everyone else.  Ideal or not, it's not going to happen.  At best,
>CP4E is asking a huge number of people to learn a huge number of new
>concepts.  We need to meet them *more* than halfway.

OK, let's agree to disagree.  I think my 5 year old girl will have
no problem with case sensitivity and I don't plan to shield her
from this ugly aspect of the real world.  On the other hand, if
there's some nifty feature in Python X.X that lets us sweep a 
module for possible bugs introduced by inadvertant typos, so much
the better.  I'd use that too.