Case-sensitivity: why -- or why not? (was Re: Damnation!)
wtanksle at dolphin.openprojects.net
Mon May 29 22:16:45 CEST 2000
On Sun, 28 May 2000 20:14:46 +0200, Thomas Malik wrote:
>Late answer, but here i go:
And a late reply on my part :-).
>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
A quick comment: Python has very little in the way of innovation. It
brings together many tried-and-true mechanisms in a very elegant manner.
Not even indentation is a true innovation; it was pioneered by ABC before
Python was born.
>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.
This is a very good argument. At the same time, there are already enough
plans to make Py3K a very different language in this sense; new policies
will have to be written before its use will be accepted anyhow. So I
agree with you, but I don't think you see that this point is already lost.
>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.
We'll see about your contentions for unreadability, but as to the general
tendancy here -- well, I'm not at all impressed. Can you even IMAGINE a
language which does NOT allow possibilities to write unreadable code? The
concept boggles my mind.
>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)
NO! You're not just wrong here; you're 180 degrees wrong. In a case
_sensitive_ language it's possible to have two different identifiers with
the same spelling but different cases; if you include both, and then try
to use one but mispell it as the other, you'll get no error, but your
program won't work.
If you try that trick on a case insensitive system, you'll get an error as
soon as you import the second module.
Case sensitivity WILL reduce this class of error by replacing a runtime
error with a compiletime one.
>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 ?
Your rhetorical questions answer themselves. Why should a programmer
enforce these things? Because it's stupid to NOT enforce them. So
enforce them already!
>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.
GOOD. Excellent. Now we don't have variables which differ only in case
-- which is the problem you spend so much energy exponding against on
>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
You seem to understand the reasoning behind this -- I have no idea why
you're asking the question.
>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
Why should it be more or less annoying to use a 'rational' division than
to use an integer division? They're both a pain; the difference is that
the rational division preserves certain properties of the integers, while
the integer division doesn't.
>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.
Such as, for example, Py3K?
>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
I doubt it. They're only postulating enough to get _something_ done by
people who are not currently being reached. It's a fair experiment, and
it _is_ being investigated.
>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.
Or so you've been told. Did you consider the C library as part of the
language? You can't do anything important without the library, and it's
>The syntax, to a beginner, looks extremely crude.
Hmm. I thought it was rather nice. So much more elegantly terse than
Pascal, yet familiar in a way that Forth wasn't (at the time).
The library, though, was barely adequate, and later experience has only
strengthened that hostile conclusion.
-William "Billy" Tanksley
More information about the Python-list