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

[William Tanksley]

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

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

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

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
>function/operator, whatever.

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

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

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

>Thomas

-- 
-William "Billy" Tanksley