[Edu-sig] Case sensitivity

[Bruce Sherwood]

I was intrigued by the comments of my colleague Dave Scherer on treating
with caution how well proved is the assertion that case sensitivity is a
problem for novices. Let me offer some context to provide another view on
the issue of case sensitivity.

CONTEXT

Ruth Chabay and I have been teaching an unusual introductory university
freshman physics course at Carnegie Mellon University taken by science
students, in which computer modeling plays a central role:

   http://cil.andrew.cmu.edu/mi.html

We spend just two 50-minute periods teaching a subset of the cT programming
language developed in our Center for Innovation in Learning, after which
the students write programs with 2D graphic output including a spacecraft
coasting to the Moon, a planet in an elliptical orbit, the motion of a mass
on a spring with or without friction or air resistance, the scattering of
an alpha particle off a gold nucleus (the Rutherford experiment that
discovered the nucleus), and statistical mechanics calculations of the
entropy and specific heat of a solid modeled as quantized harmonic
oscillators. A sizable minority of our students have not previously written
a computer program, but they are able to do serious computer modeling with
little instruction, and they are able to do this on Windows, Mac, or Linux,
with no installation or environment difficulties.

A group of us at Carnegie Mellon including David Andersen, Ruth Chabay, Ari
Heitner, Ian Peters, Dave Scherer, and I are investigating the possibility
of having our physics students use Python instead, with 3D graphics
implemented through an innovative package being developed by Dave Scherer
that talks to Open GL. The challenge is to make a package installable and
usable by novices, with 3D graphics, that works on Windows, Mac, and Linux.
(We don't see it to be feasible to build 3D graphics onto cT.)

Note that we have chosen a very narrow focus: Making it possible for
science students in a university physics course to learn quickly and use
productively Python plus 3D graphics in order to do computer modeling of
physical systems. This is a different focus from that of many contributors
to this SIG, whose main interest is in using Python as the language of
instruction in computer science or programming courses. One possible
overlap of interests is this: We believe that those just beginning to write
programs want in the year 2000 to write graphics-oriented programs, not
programs that just calculate mathematical quantities. Graphics is a huge
motivator and of the highest interest in the public at large. We define
"computer programming for everybody" as starting with graphics, not in
getting Joe Public to write Python code to control his web server, at least
not at first! It is possible that what we may be able to do in making 3D
graphics available to the masses would find use in introducing programming
to newcomers.

CASE SENSITIVITY

In our physics teaching we have not seen any hint of a problem with case
sensitivity, even though cT is case sensitive. There are confounds,
however, so I don't want to claim too much.

In cT one is required to declare all variables, so it seems plausible that
the student will use the name that the student defined. Also,
system-defined commands that might be problematic don't cause trouble
because these commands are at the beginning of a line, followed by TAB, so
there is no problem if the student declares a variable named "disk" and
also uses the "disk" command. System-defined names that can collide with
user-defined names, such as "zred" for the color red, all start with a z to
help avoid collisions.

It is possible that these special considerations are the reason why we have
seen no hint of an issue with case sensitivity. But there may also be
significant contextual differences between our physics environment and that
of an English student trying to command a bunny to hop in Alice.

The algebra-savvy science student is used to making distinctions between t
(time) and T (temperature), between a (acceleration) and A (area), etc. A
particularly nice pair is e (charge on an electron) and E (electric field
operating on that electron), so that the force on the electron is
represented by e*E. (Of course there may also be a collision with the
natural-log base e!)

The reason for these letter pairs in physics is a shortage of letters in
the Roman alphabet coupled with a historical style that mandated
single-letter names for algebraic quantities. We are now accustomed to
using multiletter names in computer programs, so we could write Qelectron
instead of e and Efield instead of E. But I would be cautious in throwing
out case sensitivity on the basis of usage problems in one particular
community. Perhaps it could be optional on a per module, based on a
directive found at the start of the module, in order to accommodate the
needs of different communities?

FLOATING-POINT DIVISION

I have a very different view of the other problem that was reported, the
problem with division indicated by "/". Here I VERY much want a change so
that "/" means floating-point division, even if both operands are integer.
I VERY much want 1/4 to be 0.25, not 0. There are a variety of possible
solutions to provide backward compatibility. At worst, a conversion could
change all occurences of a/b into "olddivision(a,b)" which would mimic the
current behavior. And of course there would be a new syntax such as "a div
b" to do integer division. The current convention causes trouble even for
expert programmers when they're in a mathematical frame of mind.

OTHER ISSUES ARE BIGGER

The division issue is important. The case sensitivity issue may be
important. But both of these issues pale into utter insignificance compared
to the huge barriers currently facing novices with respect to installation,
running (search path issues, IDE issues), graphics, and cross-platform
issues.

Bruce Sherwood
Center for Innovation in Learning and Department of Physics
Carnegie Mellon University