[Edu-sig] On case sensitivity

[David Scherer]

> If case sensitivity is a big problem for non-CS
> Alice programmers, my first response would be
> to front load the intro with plenty of warnings
> to students that they'll likely introduce bugs
> by forgetting about such sensitivity.  But I
> wouldn't make the sensistivity go away necessarily,
> as this would encourage laziness and bad habits.

The Alice tutorial used in the relevant testing DID include strong warnings
to such effect, and I believe the testers even explained it verbally to
people who had trouble, and they found problems nevertheless.

However, as I've already discussed, those results were confounded by the
case conventions in their API.

> Truth to tell:  most sophisticated programming
> languages care about case.

So what?  Cockroaches are much more numerous than humans, but I prefer
humans to cockroaches in all respects.

> If they hand hold,
> trying to catch bugs of this nature, that's great,
> but at the end of the day, SPAM, Spam and spam
> are three different names, and should be allowed
> to co-exist if that's trully the author's intent.

Why?  I've never seen any strong justification for case sensitivity other
than backward-compatibility with some other language or library.

eNGLISH IS NOT cAse SenSitiVe, although there are certainly strong
conventions!

> I happen to write a lot of code in Xbase, which
> does NOT care about case.  I've gotten comfortable
> with this and sometimes stumble in a case sensitive
> environment.  But I've never whined about it.  The
> problem is MY reflex-conditioning, not someone
> else's.

If the goal is really Computer Programming For Everyone, everything is OUR
problem.  The needs of the (10M?) programmers in the world are vastly
outweighed by the needs of the six billion normal people.  They are always
right and we are always wrong.  Randy and Guido are 110% right about that.

However, I agree that forking Python is not desirable.  If Python 2 can
somehow help everyone to migrate to case insensitivity, fine.  Otherwise,
implementing case correction at the IDE level seems like the most sensible
approach.

I note that backwards-incompatible syntax changes are most acceptable if
there is a reliable automated translation which converts all correct code in
the old syntax into correct code in the new syntax.  Given the availability
of Python parsing code, this should be quite possible as long as such a
mapping is defined for a given syntax change.

The REAL problem occurs when there is no general way to do such a
translation lexically.  This is the case for integer division,
unfortunately, in the absence of static typing:

# Python 1.5 code
a = input('A:')
b = input('B:')
c = a/b	# what is the type of a? b? c?
print c

Dave Scherer