Language change and code breaks

[Corran Webster]

In article <cppuawfqbm.fsf at cj20424-a.reston1.va.home.com>, Guido van
Rossum <guido at python.org> wrote:

> "Tim Randolph" <timothyrandolph at yahoo.com> writes:
> 
> > > (2) Potentially, the group of non-programmers is much larger than
> > >     the group of programmers (and it's easier to teach programmers
> > >     an arbitrary rule than non-programmers).
> > 
> > I think the distinction between programmers and non-programmers
> > misses a third important group: "sometime programmers" -- people who
> > code occasionally to for fun or to solve problems, but aren't in the
> > trenches (or the cubes) day in and day out.
> 
> Thanks for reminding me!  This is in fact the group I have in mind
> when I say non-programmer -- true non-programmers of course wouldn't
> be using Python... :-).  In my usage, a "programmer" is someone who
> is a professional code-slinger, 8-12 hours a day.  A "non-programmer"
> is someone whose profession is something else (e.g. chemist, or
> webdesigner, or rocket scientist) but who occasionally needs to
> program.

I probably fall into this "non-programmer" mould: my main profession is
a mathematician, but I use Python to support my teaching and research.
To be fair, I am far from a "novice," having been programming for the
majority of my life, have had formal instruction in programming, and have
taught programming as a teaching assistant.

I very much appreciate the ability to distinguish between "n" and "N"
or "omega" and "Omega" when I am converting math to Python.  I don't
recall ever having been bitten by confusing variables due to case, but
again, this may reflect the fact that I am used working with variables
in different cases (and, indeed, alphabets and scripts) possibly having
vastly different meanings.

It may be considered bad style to write something like:

sum = 0
for n in range(N):
  sum += n**2

but it is useful when translating a mathematical expression like:

  __ N-1   2
  \       n
  /__n=0

into a Python program.

Since one major audience for Python at present is the Numerical Python
community, I would think that case insensitivity would be a problem
for users in this context, and quite a number of these would be such
part-time programmers as you are trying to help with this proposal.

> > As a member of this group, who is especially fond of Python for how
> > easy it is to pick up where I left off days or weeks before, I would
> > very much prefer a case *insensitive* language with tools that
> > enforce *uniform* case usage.
> 
> And that's of course what I have in mind.

I think a far better solution would be a case sensitive language with
tools that allow the user to enforce uniform case usage.  Having taught
novice programmers, I can appreciate that case sensitivity can lead to
problems in that community (although I do not remember it being a major
obstacle for the students I taught, I can never-the-less see that it may
have caused some students confusion).

However, I think that the best way to deal with this is in the tools that
are provided with the language, such as IDLE, or by providing a case
insensitive version of the language for a teaching environment.

> > Nobody wants to see fOo and FOO and foo with the same meaning, but
> > nobody wants to see foo and FOO and foo at all in the same program
> > with distinct meanings.  I also don't think the cutesy c=C() makes
> > for readable code -- at least for this sometime programmer.
> 
> Exactly.

And I have to disagree.  While I don't want to see "oMegA" and "omega"
*at all* in the same program, I do want "omega" and "Omega" to be able
to refer to distinct (albeit probably related) objects.

how-about-allowing-blackboard-bold-and-greek-letters-in-variable-names-ly
yours, Corran