Case-sensitivity: why -- or why not? (was Re: Damnation!)

[Thomas Malik]

Late answer, but here i go:
1. By bringing the department of our bank into argument, i was saying, that
even very conservative - thinking organizations are starting to use your (as
it is) quite innovative programming language, because of the advantages it
has. For a bank, one of the most important points is reliability in the IT
systems, which, amongst others, can be achieved by a quite strict set of
programming rules. If these rules completely break with some new programming
language, or even with a new version of the language, it will have to be
reconsidered it the language is going to be used. If the language itself
provides for possibilities to write unreadable code (which
case-insensitivity does, see below), it will be extremely difficult to share
code with external programmers (we work a lot together with external
consultants), i can assure you of this fact from experience.
2. in your mail, you are kind of mixing up a computer language (Python) with
spoken/written language (english), i don't get the point here. I mean, if
you were critisizing me for my spelling, i could bother or not, depending on
whether i've slept well or not. With a computer program, that's a totally
different point: a program will run correctly or not, depending ONLY on the
correct syntax & semantics of the program. It's not a question of tolerance.
3. Removing case - sensitivity wouldn't reduce errors in any way, in
contrary, it will add a new and more difficult class of errors: those where
one uses the same identifier (possibly written with different case ...) with
two different meanings. For example, one uses a class 'Error' from library
a, and the function 'error' from library b, case-insensitivity will be a
great source of annoayance here. You are trading syntax errors (easy to cope
with) for possible semantic errors (extremely difficult to cope with)
4. the point, that bothers me most about case insensitivity, is, that
consistency in the spelling of identifiers will be lost. That means, because
case doesn't count any more, why should a programmer enforce any kind of
rules in the use of type case ? Why should one even consider using the same
case for the same identifier in different places ? What would the right
typing be anyway, if Python doesn't check it anymore ?
I find programs extremely hard to read, when they don't use consistent case
for, say, class names, method names & so on.
5. there are quite a lot of cases, where i would have to invent 'unnatural'
names for identifiers, just because the word i want to use is already used
by a class name, for instance.
6. Any wide-spread computer language in use today uses case-sensitive
identifiers. Oth, the only case - insensitive language i know of (pascal)
doesn't produce any real-world projects and even has it's case-sensitive
followup (Modula-2), by the same author (Niklaus Wirth). Lisp is another
case - i didn't use it for some time already, but as i remember, the
standard common lisp had case-sensitivity, and the syntax of the language
allows for totally different naming schemes (with hyphens, for example).

Ok, i hope that's enough to stop you claiming that i don't have or that
there arent't arguments against case - insentivity

On the other point, that has been discussed in the list, about promoting
integer divisions to float or something other:
I don't get the point here. I mean, during my college time, we have been
bored with stuff about groups and rings, just to see in the later courses,
that that kind of stuff can be quite useful. So, why should a division
between integers leave the set of integer numbers, but no so a muliplication
? Ok, it's more 'natural' to say 'ok, 1/3 is 1/3, a rational number, that is
(note that it's NOT the floating point representation 0.3333..., that's only
an approximation). The point is, again, that a programming language is NOT a
natural language (COBOL tried this already and failed laughable), but used
for programming. And in programming, i will need an integer division all
around, it were annoying if i would have to use some other
function/operator, whatever.
And then, i mean, once told, one shouldn't forget that 1/2 == 0. A person
forgetting that all the time should propably learn something else. CP4E, to
be honest, i have my vague doubts about that. In some way you are
postulating the same level of  intellectual potential for everyone, but
that's another question you might have investigated for a longer time
already.

The strong point about C is, that it succeeded with an absolutely minimum
set of language features to be capable of everything a programmer needs. The
syntax, to a beginner, looks extremely crude. But in all my time at the
university and after that, in profession, whenever i've seen a beginner to
start programming, it was with C ( not C++, get me right here! ). What i
want to say with that, it doesn't matter so much how 'resistant' the
language is against first-time-programmer's errors, but
1. how logical the language is.
2. how much it helps the programmer to detect errors.
3. how little the number of syntactic constructs is (for that reason, C++
certainly is NOT a beginner's programming language)

Ok, don't take all this personally, i like Python very much - but i hope
that will remain so...
Thomas