Language change and code breaks

[Bruce Sass]

On Thu, 26 Jul 2001 maxx at easynews.com wrote:
> On Wed, 25 Jul 2001 05:29:41 GMT, Guido van Rossum <guido at python.org> wrote:
<...>
> >The number of symbols available is so much larger than the number of
> >distinct names you need that the reduction is irrelevant.
>
> Plus, the day that symbols become so numerous in code that the usage of case is
> necessary to differentiate them, then software development will have become
> truly too complex for mortals such as myseld.

Sure, and we can generate as many identifiers as we need with only 2
symbols, "0" and "1".

Obviously there can be both too many symbols and too few symbols...
the question is, `how many is too many, and how few is too few'.
Furthermore, case-sensitive vs. case-insensitive can be handled as a
convention (if you don't like 52+<numbers> symbols then only use 26+),
no need to change the language and force 26+ on everyone.

> >> Everyone knows that in normal usage, case carries meaning (bob
> >> vs Bob). How could it possibly benefit the beginner to violate
> >> that naive expectation?
>
> Because writing code is a completely different function than "normal every day
> writing." Learning to write code means beginners must learn to structure their
> thoughts, and organize tasks, so that their code is not a potential jumble of
> ideas, as normal every day writing can be.

What does that have to do with case sensitivity... code, thoughts and
tasks can be organized just as well with case sensitivity as without,
and can be just as jumbled without case sensitivity as they can be
with it.  This is a function of the language's semantics and how well
the users have `wrapped their head' around the language.

> Creative writing and code writing are like apples and oranges. To expect that
> beginners do not need this distinction is to doom them to failure. In fact, some
> of the restrictions that Python places on users, forcing them to indent code for
> example, is what makes the language a great training tool.

Indentation is not a restriction, it is part of the language.
It would be a restriction if the semantics were clear without
indentation (e.g., we had block identifiers) but indentation was
forced anyways.

> Most every piece of problematic code I have dealt with in my career has been
> difficult to work with primarily because it is poorly formatted and structured.
> More often than not, I find code that does not work because novices just put
> commands down in the order that they think of them, not bothering to design the
> proper process flow first. Then they wind up with a malfunctioning mess that
> even they cannot decipher. If they learned on languages like Python first
> (instead of the popular stream of conciousness messes like VB), then they would
> develop "good habits", and be more successful.

That may be true, but "format" and "structure" have nothing to do with
case sensitivity.  Case sensitivity may affect readability, for those
who do not realize that "a" and "A" are different... a simple

>>> ord("a"), ord("A")
(97, 65)

should fix that problem though.


- Bruce