[Edu-sig] On case sensitivity

[David Scherer]

I hate to be the devil's advocate here, because I *do* believe that Python
is an excellent language for education or I wouldn't be in this SIG.

Nevertheless, you have made some points here that I think need to be
corrected.

> One of the best keynotes was given by Randy Pausch, who demonstrated
> Alice, a 3D virtual reality builder that uses Python as the control
> language (www.alice.org).  Randy is a very motivating speaker, and his
> stories and demos of small teams of 19-year old non-cs students
> creating interactive virtual worlds using Alice (and hence programming
> in Python) had the audience in awe.  He reminded us that we (the
> audience) were geeks -- who make up only one percent of the population
> -- and that we need to think about how we talk to non-geeks.

Alice has been tested on non-cs students at the University of Virginia using
a two-person talk-aloud protocol, but this testing only covered a short
tutorial.  I wasn't at the conference, but the demos that Randy usually
shows off were created by teams of students in his Building Virtual Worlds
class here at CMU, each of which are composed of programmers, artists, and
writers.  Programmers are required to show some competence with Python to
get into the course, and are generally CS majors from the rather competitive
CS program here at Carnegie Mellon.  The computer labs on campus are often
filled with bleary-eyed BVR students trying to write their own collision
detection algorithms for Alice at 4:30 in the morning.  The stuff that comes
out of BVR is proof that Randy is good at motivating people, not that Alice
is easy to use.

> Randy explained the importance of user testing, and mentioned that
> only two Python language issues were a problem: (1) case sensitivity
> and (2) integer division.  I believe he said that case sensitivity was
> by far the worst offender, affecting as many as 75% of the students.
> He also said that *that's it*.  No other Python features (used in
> Alice) caused problem for his audience.  The rest of the user testing
> dealt with things like how to express a quarter turn (the answer is
> 1/4, not 90, as we geeks think :-), and what to name rotations along
> the x/y/z axes (the answer is, surprising, turn left/right, turn
> up/down, and *roll* left/right).

I strongly suggest reading
http://www.alice.org/advancedtutorial/ConwayDissertation.PDF
which I believe describes the result you are referring to, and perhaps also
walking through the latest alice tutorial to get an idea of how far it goes.

I believe that the tutorial used in the testing involved interactive use of
the interpreter to move objects around in the world, as well as some short
scripting.  Because of the way Alice works, very few of the constructs in
Python were involved in the testing at all.  At a guess, there were no
loops, no conditional statements, no variable assignments, few arithmetic
operations, no lists, no dictionaries, no class definitions, no function
definitions, etc, etc.  Some of Python's syntax was surely exercised, in
particular function call syntax (keyword arguments are used extensively and
to good purpose by the Alice API).  However, I think this is an extremely
weak "scientific" assessment of Python's ease of use.

Further, the problem with case sensitivity is described this way by Conway:

| To make matters worse, the specific stylistic case rules for
| the Alice API were very confusing to novices.  We employed a
| rather standard set of rules that most programmers would find
| familiar: constants in ALL_CAPS, class names in
| LeadingCapsMixedCase, method names in lower_case_and_underscores
| This kind of consistency helps programmers understand, read, and
| navigate through large programs, but to a novice, these rules
| are arbitrary and confusing.  To explain that FORWARD is a
| constant and move is a method makes no sense to a person who
| does not know or care what a constant or a method is.  To a
| novice these are both just "words" that are used in the Alice
| command language; words that play more-or-less equal roles in the
| novice programmer's mind.  As such, novices perceive the case
| rules not as evidence of organization, but of deep inconsistency.

It is clear that such "inconsistent" use of case in the standard library is
confusing to novices, especially when (as in Alice) users are asked to use
many constructs such as functions, classes, and methods well before the
stage of sophistication where they could create any of those things and
hence understand that they are distinct.  However, this use of case in the
Alice standard library severely confounds the result that case sensitivity
in the *language* is crippling.  Conway does make a convincing argument that
case insensitivity makes sense:

| Case sensitivity is an artificial rule that fights against
| older knowledge that novice users have, namely that while
| forward and FORWARD may *look* different, they should at
| least *mean* the same thing.

However, this latter argument does not constitute "scientific evidence."

It is possible that Randy has done more recent and comprehensive testing.
We should discuss this with him directly.  Is he on this list?  (Hi, Randy!)

> Alice now uses a modified Python interpreter which is case insensitive
> and where 1/4 returns 0.25.

The integer division problem *is* rather well documented both by the Alice
team and others.

> Randy's scientific evidence swayed many who were there into accepting
> that a language for "everybody" has to be case insensitive.

I believe that case insensitivity, either in the language itself or enforced
through the IDE in some way, is a good idea.  But this particular study is
only weak evidence in favor of this.

> For those who still don't like it, trust me that the programming
> environment will enforce case *consistency* -- if you name a function
> or variable "Spam", later references to it as "spam" or "SPAM" will
> quietly be changed to use "Spam".  There are also some ideas on how to
> start warning about dependencies on case sensitivity in Python 1.6.
> (We'll probably have to change the standard library in some places to
> make it conform!)

This seems reasonable.  It may be that these changes are even sufficient.

I assume that the IDE would search lexically for variables in order to
enforce consistency?  How would it search the module system?  The dynamic
nature of python makes this problem intractable in general:

# pathological case

a = raw_input('Select module: ')
if a=='foo':
  from foo import *
elif a=='bar':
  from bar import *
else:
  from foobar import *

# at this point the correct case of every
# identifier is basically up in the air

I know this seems a little far-fetched, but the standard libraries actually
do this sort of thing.

Dave Scherer