Language change and code breaks

[Justin Sheehy]

Guido van Rossum <guido at python.org> writes:

>> 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.

The problem here is that you control the language, but you don't
control the tools.  People use a variety of different editors to work
on Python, and adding this type of smarts to all such editors is
simply not going to happen.

If there is a rule that needs to be enforced, you can't count on the
tools to enforce it.  Python will either demand uniform case usage, or
it won't.  It is impractical to assume that everyone will choose
editors that enforce this sort of rule.

Having only a small number of "approved" editors or IDEs will not work
either, as that would alienate a large portion of the professional
programmers using Python.  Such people are very loyal to their tools.
As much as bringing non-programmers into the fold is a major goal, any
means used to do so that drives away programmers is questionable.

"Bjorn Pettersen" <BPettersen at NAREX.com> writes:

> I don't think anyone would be opposed to an auto-correcting IDE.

I beg to differ.

There are two problems with this.

The first is that many people don't want anything they type to be
"autocorrected".  I frequently hear about misadventures that people
have with Microsoft tools that "autocorrect" their spelling mistakes.
This feature often makes correct text incorrect, and even when it is
correct it is providing an obnoxious degree of invasiveness which many
people find very distracting while they try to work.

The second is something that I mentioned above.  Attempting to enforce
that everyone use such an IDE is a very bad idea.  If you can't count
on everyone using it, then you cannot count on it enforcing the rules.

A language's rules should be enforced by the language implementation
itself, not the tools that people use to program in that language.

(FWIW, I think that Python's implementions should not allow mixed tabs
and spaces, but that is a different argument.)

Guido van Rossum <guido at python.org> writes:

> If you use this a lot (message = Message() etc.) your code is less
> readable than it should be. 

Really?  People use capitalization semantically all the time, both in
programming and in the rest of life.  I don't understand at all what
makes the above code unreadable.

It has been stated a few times that this is "bad style", but I have
yet to see why.  The lowercase name as instance of uppercase class
convention seems to be a valid style, and I don't know of a reason to
make it disallowed.

> It also makes it harder to discuss code in person or over the phone
> -- spoken language is not case-preserving, as anyone who has tried
> to give someone a URL over the phone knows. :-)

This is a very funny argument in the context of Python.

Is spoken language indentation-preserving?

Clearly, you should make Python indentation-insensitive in order to
make it easier to discuss code over the phone.  Besides, we can always
just write an IDE that everyone will use that will enforce uniform
indentation...

Spoken language has very different rules than written natural
language, which has different rules than program text.  Trying to
pretend otherwise leads down a dark and ugly path.

I do not see that CP4E can ignore or change this fact.  Or that it should try.

-Justin