Language change and code breaks

[Joseph A. Knapka]

Justin Sheehy wrote:
> 
> 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.

Ugh. Sounds like VB. No thanks.

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

A case sensitive language, along with a development environment
for beginners that encourages and enables case consistency, sounds
like the best of both worlds. No one would *have* to use it, but
anyone who wanted to could.

FWIW, I am a relative newcomer to Python, with a lot of general
programming experience (C,C++,Java,Tcl,Prolog,LISP,Perl...). I
really love Python, but making it case-insensitive would put a
very significant damper on my enthusiasm. Why would you want
to intentionally reduce the symbol space available for names?
Everyone knows that in normal usage, case carries meaning (bob
vs Bob). How could it possibly benefit the beginner to violate
that naive expectation? 

<Yes yes, argument from personal incredulity, I know.>

-- Joe
 
> "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

-- Joe Knapka
"You know how many remote castles there are along the gorges? You
 can't MOVE for remote castles!" -- Lu Tze re. Uberwald
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
2nd Lbl A + 1 = 2nd Pause 2nd Prt GTO 2 R/S