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

[Martijn Faassen]

William Tanksley <wtanksle at dolphin.openprojects.net> wrote:
> On 6 Jun 2000 12:19:25 GMT, Martijn Faassen wrote:
>>William Tanksley <wtanksle at dolphin.openprojects.net> wrote:
>>> On 5 Jun 2000 12:01:04 GMT, Martijn Faassen wrote:
>>>>William Tanksley <wtanksle at dolphin.openprojects.net> wrote:
[snip]
>>>>> This is a classical example of false dichotomy ;-).

>>>>It's not.

>>> It actually is.  You're claiming that I hold one of two opinions; I hold
>>> neither one.

>>I'm claiming you haven't shown yet that consistency has nothing to do
>>with 'code looking good'. Anyway, you should've said something like that
>>in your first post -- now you explain what you meant. Now I'll explain
>>what I meant. :)

> You're claiming something that you've never written before -- I don't even
> understand what you're claiming that you claimed.  (Whew.)

Anyway, you pulled a false dichotomy out of your hat. I pulled the
"it's not out of my hat". It would've helped if you explicitized 
the dichotomy. :) Then I explicitized my 'no'.

> What I disagreed with was your false reduction of my argument to two
> views, neither of which I held.

All right; the views were consistency or decreased line count. Your view
appears to be that the advantage is lack of delimiters. Then we got into
an argument about consistency and I was continuing that argument there. :)

>>>>> I liked Python's
>>>>> indentation not because it enforced consistency, but rather because it
>>>>> makes code look good.  In fact, it could be argued that Python does _not_
>>>>> enforce consistency; the programmer is free to choose any indentation for
>>>>> each block, so long as each block can be parsed (which does require
>>>>> internal consistency).

>>>>"""
>>>>I liked Python's
>>>>case sensitivity not because it enforced consistency, but rather because it
>>>>makes code look good. In fact, it could be argued that Python does _not_
>>>>enforce consistency; the programmer is free to choose any case-spelling for
>>>>each variable name, as long as each variable name can be parsed.
>>>>"""

>>> But now you've converted my paragraph from a true statement to a false
>>> one.  The programmer is not in fact able to choose any case-spelling for
>>> each variable name; they must use the same one which was originally used,
>>> unless they wish to create or access another variable.

>>Perhaps that's unclear, but my reading of 'for each variable name' is for
>>each unique variable name -- I mean, a name can be referred to multiple
>>times, but it's not a different name each time.

> But again, this doesn't match with what I said about indentation.
> Python's indentation is flexible because you can choose your own
> indentation for each block, regardless of how other blocks are indented.
> This can be very handy!

Python's indentation is less flexible because you can't choose variable
indentation for a *single block*. You also can't choose not to indent.
Let alone that all options on where to place the delimiters are removed.
This means a definite cramping of indentation styles. I'm making the parallel 
with case sensitivity, where you can allow variable case-spelling for a 
single name or not. Not allowing variable case spelling for a single name is
less flexible and enforces consistency in case-spelling.

> Python's case sensitivity is not flexible: once you write a variable name
> one case, you're required to write it the same way.

Right. It's less flexible, just like Python's indentation strategy is
less flexible.

> I think I'm just stretching the metaphor, though.  I don't really think
> there's enough similarity between variables and indentation to really use
> effectively.

The argument is that reduced flexibility reduces variability in coding styles
(and decreases the chances of inconsistent style or absence of style).
I think there's a clear similarity there.

[snip]
>>So either you're saying you like Python's
>>indentation because it doesn't have braces (and that's the only reason),
>>or you're buying into the consistency argument after all. I believe I
>>gave you the braces option before, speaking of dichotomies.

> You did NOT give me the brace option before, as you can clearly see by
> reading the first paragraph.

You're right; I gave the reduced line count option; I checked. My
apologies.

> Now you give me it as though it were the
> ONLY reason; clearly, by my own discussion, it's not the ONLY reason;
> however, I will agree that it's a strong one.

The other reason (showing the tree structure) applies to all languages.
In those languages delimiters and not indentation is used to indicate
tree structure. For some reason those delimiters alone make code harder to
read for humans than the use of indentation.

[snip]
>>> Of course they should.  Lisp programmers get really mad if people post
>>> non-standard formatted code on c.l.lisp.  EMACS enforces it when writing,
>>> and angry programmers enforce it when reading ;-).

>>So in your case there's no reason to prefer Python's way of indenting,
>>*except* that there are no delimiters. Okay, thanks for making that 
>>clear. Or am I still missing something? :)

> You got it right.  Not *exactly* right, since you still seem to insist
> that I'm only allowed to like Python's indentation for exactly one reason.

I don't see how there can be another reason for you than a combination
of reduced line count and absence of delimiters. The tree structure argument
alone doesn't work, as delimiters show tree structure as well. But indentation
makes tree structure easier to grok for humans. Since other languages *can*
use indentation as well, the only reason that remains to prefer Python's
style would be that you like the absence of the delimiters/reduced line
count. Or more broadly speaking, an absence of redundancy.

[snip]
>>Yes, you were saying the same for case. Now, if I understand you right,
>>you like Python's indentation strategy more than the delimiter strategy.
>>The only two reasons I can come up with is:

>>  * less redundancy because there are no delimiters
>>  * less space taken by the delimiters

>>(because the two-dimensional structure argument makes sense for any language
>>if only you indent I'm not including that)

> You'd best include it anyhow -- because it's the reason.  It does NOT make
> sense for languages in which it's not, in fact, used.  There are not many
> languages in which indentation is used.

But indentation *can* be used in those languages. The *programmer* can
consistently enforce indentation. In most languages this is possible and
common practice. Therefore, the *only* reason you can like Python
better than those other languages is because of the lack of delimiters.
Because you don't buy the consistency argument, that's the only thing
left. Unless this is another false dichotomy and I'm missing something
essential. Coming up next, I see. :)

[snip]
>>Right, so that's the redundancy argument. Of course, if you used Lisp or C
>>without any indentation, you'd have that same feature too. Why do you
>>prefer the indentation approach to the delimiter approach? According to
>>your opinions on case-spelling one would think you'd prefer the former, as
>>it offers more freedom while the programmer still has the option just
>>fine to enforce any indentation strategy they want, if they want it.

> Excellent question, and this will hopefully clarify EXACTLY why you should
> include reason #3 in your list of reasons why I like Python's indentation.

> Almost all modern languages are tree-structured.  Therefore, they're most
> efficiently written and displayed as a tree.  Trying to write them as a
> delimited stream may be effective for computers (although it's still
> difficult), but it's terrible for humans.

Right. Agreed. Human interface reasons make indentation a better way to
display a tree than delimiters.

> Therefore, we write even languages which use only delimiters as though
> they were trees.

> Python breaks away from that.

So the only reason you prefer Python's approach would be the lack of 
delimiters. :) Reason #3 is no reason to *prefer* Python's approach --
you gain the same advantage in C as long as you indent properly, after all.

[snip]
>>> But in case-sensitive languages, words can be spelled *differently* in
>>> case: NO is not the same as No or no.  If the language were
>>> case-insensitive this would be impossible.

>>Hm, I'd say those would be different words, which vary only due to 
>>case-spelling. Not that the same word can be spelled differently in 
>>case.

> Notice how hard it is to communicate that those are different words,
> though?

That's because you confused the natural language 'English' (which is
tolerant of misflusner to vlibracious extent) with the programming
language Python (which isn't). It's harder to communicate the difference
between 'NO' and 'no' in Python than it is to communicate the difference
between 'x' and 'y' in Python because of this confusion, true.
But the difference between natural language words and words in
programming languages will have to be made clear to newbie programmers
pretty quickly anyway.

>  Even in typed communication we're not consistent, and in spoken
> communication we can't communicate that info at all.  Is it any wonder
> that newbies get confused?

It's no wonder newbies can get confused, but newbies will get confused
in any case about far worse things like immutability/mutability. It could
actually be good in a didactic sense to make newbies care about consistency
on all levels right away, because consistency is of extreme importance
if you want to produce good code. Also, newbies will have to read their
own code, and one can argue that the more readable this code is the
more easily they can understand it.

>>Ignoring that point, spelling the same word in different case-spellings
>>is only possible in case *insensitive* languages!
>>So I'm not quite sure what you mean here?

> Those words are pronounced and subvocalised the same -- unless, of course,
> the programmer was boorish enough to use any two of them in the same
> routine, in which case you'll probably have to read the routine again,
> this time subvocalising differently.  With case-insensitivity, you won't
> have to; your first reading was correct.

Except that now it's harder to read. Actually programmers use case
in many conventions. If something is spelled with a starting uppercase
in idiomatic Python code it's usually a class. If something is spelled
in all caps it's usually something intended to be a constant. So if I
see 'Foo', I think 'the class Foo', and if I see 'foo', I think 'the
instance foo'. If I see 'foo()' I think 'the function foo'. And if I see
'.foo()' I think 'the method foo'. It's almost like Perl; context changing
the meaning of the variable. As they're all objects. :)

> You know, for the first time it occurs to me that our learning styles may
> differ -- I'm somewhat auditory, and from the way you talk, I'm guessing
> you're primarily visual.

That's of course possible (though you do like indentation, which is of course
purely visual -- the auditory argument would be in favor of delimiters).

> The obvious solution is to compromise so that both styles of perceptivity
> are accomodated: the visual learners must be able to see things exactly
> the same (or they don't recognise them as being the same), and the
> auditory learners have to be able to vocalise and subvocalise things.

> Both of these are solved not by language fiat, but rather by convention:
> always use lower case.

Hm, but that will remove important visual cues that exist now. You'd have
to reintroduce those cues in some other sense that's both visual and
auditory. That's hard to do for names which have (MultipleWords or 
multiple_words), also hard for function calls. For classes you could
work with a prefix, perhaps. Obviously one has to engaged in a visual to
auditory translation when one reads code anyway. 'foo()' becomes 'here
foo is called', unless you vocalize the (). For me those are just 
*umph*. Hm. No real vocalization. :)

>>No, because I as a programmer happen to like the freedom different
>>case-spellings happen to offer. It's up to the *programmer* to
>>enforce the right conventions here. Throwing your arguments back at you
>>again. :)

> EXACTLY!  Now you're arguing 100% on my side -- only thing that's puzzling
> me is that you imagine you're disagreeing with me.  Evey single thing
> you're saying there is an argument ONLY for case-insensitive languages;
> because only with them can you choose case-spellings with freedom.

No, the argument is that I want *one single* case spelling for each
name in the system. I want to have freedom *there*. I don't know if that's
really a 'freedom', but I happen to like the restriction, which I'd
lose. I also like having the actual freedom of foo (instance) versus Foo
(class).

> And it's always up to the programmer to enforce conventions; I'm glad you
> finally agree on that.

No, I didn't say it *always* is up to the programmer to enforce conventions.
It's up to the programmer to enforce conventions when the system either
_can't_ enforce conventions or if the system enforcing certain conventions
makes that system significantly harder to use (and of course the system
needs to enforce the right conventions :).

I want my system to enforce the convention that 1 + "foo" makes no sense.
There are systems which don't enforce this convention and have another
one where it does make sense. But I like those less.

The system has to help enforcing conventions whenever possible, because
I want consistency, simplicity and clarity. Not only in my own code,
but elsewhere too. And a technological aid will help here in many cases.
The 'one best way to do it' principle (though of course in many cases
this best way can only be determined by social conventions).

>>>>> So I don't really care about languages enforcing consistency; if I need
>>>>> it, I'll enforce it myself.

>>>>A computer language would be worth less if it brought no consistency at
>>>>all.

>>> Granted.  But this doesn't seem to justify your slippery-slope treatment --
>>> we don't need to enforce your amount of consistency just because no
>>> consistency is bad.  We already enforce _some_.

>>In the case-sensitive version we have now, we already enforce some, but
>>not to the point the language becomes unwritable. It's also a simple
>>rule, which helps fit it in people's minds. The case-insensitive rule
>>would also be simple, but the code becomes less readable and not 
>>significantly more writable (in my opinion). The case-enforcing rule
>>makes code even more readable (possibly -- there are arguments about
>>this by the people who like different case-spellings), but it becomes
>>far less writable, and the rule has a bit of extra complexity.

> Code with case-insensitivity becomes vastly more writable,

I disagree. I don't like writing: foo = TFoo() or aFoo = Foo(), for
instance. I also like to be able to write: CONSTANT = 12 and know people
will always know it's that. Or for that matter, 'class Foo' and people
will always see instantly that 'Foo' is probably a class.

Perhaps classes should be in a separate namespace:

foo = classes.foo()

and constants too:

constants.foo

It's an idea.. :)

When I write code I think of the readers.

> and offers a
> danger (but not a certainty) of becoming less readable.

Consider that a certainty. Look at some Delphi code to see some variations
of *keyword* spelling, even.

> The writer must
> be instructed to prefer lower case -- but this is the same instruction you
> have to give to writers in a case-sensitive language.

Except that there, it's enforced by the libraries. If the beginner wants
to use a library, the beginner has to follow the library conventions. That's
a good technically enforced way to spread case idioms and consistency. 

[snip]
>>> And a lot of other
>>> things, all of which I hope to see.  I'm curious to see whether other
>>> people like them, and I'll defend them -- but unlike most of the people
>>> arguing about case sensitivity, an ENORMOUSLY minor issue,

>>Note that you're arguing about it as well. It's a minor issue with a lot
>>of effects on readability. And it's easy to argue about. So that's why
>>we do. :)

> Oh, of course.  I'm not annoyed by arguing about anything; I'm annoyed by
> the overstatement of the importance of case-sensitivity.

I think there's a disagreement on the importance of case-sensitivity.
While the issue is very simple, that doesn't mean the issue isn't
important. It's only minor in the technical sense. 

>>> I won't
>>> consider them prerequisites to using the new Python -- I'll use the new
>>> Python if it feels like an improvement.

>>Oh, I'll likely use the new Python if it's case-insensitive. But I'd
>>prefer it would not be so, and I'm just trying to spread a meme here;
>>the link with indentation. Your own meme-complex seems to reject it,
>>so I'll stop trying with you. :)

> It's not a terrible link, really; it just works the opposite of the way
> you'd like it to.

You haven't convinced me any more than I have convinced you. I won't
reiterate the arguments *yet again*, though. :)

[snip]
>>> And for case sensitivity it _just doesn't matter_.  The only people who
>>> are strongly helped or hurt by case sensitivity appear to be newbies, and
>>> they're being hurt.

>>I'd like some more evidence about how the newbies are being hurt,

> Guido cites some studies in CP4E, and the Alice people claim the same
> (although I've not read the studies).

Hm, haven't seen the studies Guido cites, except the Alice one, which 
is anecdotal and not focused on teaching programming but on teaching
a GUI with scriptability; in a GUI I'd probably prefer case insensitivity
at many points.

[wouldn't case insensitivity hurt the maintainer?]

> Honestly, it wouldn't hurt me; I wouldn't even care for more than a couple
> of seconds, as I decided which tradition I should follow (I'm good at
> adapting my coding style to that of the code I'm maintaining).

I'd rather have a single coding style (in that respect) so I don't have to do
any adapting. That's not only important when you go from application
to application, but also in a single application.

>>It's easy to say that it won't matter for communication and maintenance,
>>but could you try backing that up?

> It seems to be easy to say it'll hurt you -- do you mind backing that up?
> How much experience do you have with large projects (or small ones) in
> case insensitive languages?

I do have a year's worth of experience with Delphi, which is case
insensitive. Even though this was a single programmer project, I've
encountered code fragments that used uppercase for keywords, which I
adapted. I also worried about my own case-consistency; I wanted my code
to be case consistent but since the compiler didn't check I was never
sure, which did give me a 'messy' feeling.

I haven't waded through lots of Delphi source code written
by others though, except the Delphi Visual Component Library that
comes with it. Ask Tres Seaver, who is elsewhere in this thread; he
has more experience with this.

[snip]
>>> It may or may not be silly -- but it's _definitely_ false.  Python is
>>> _not_ inflexible; you can lay your code out in any way you want, so long
>>> as it's in the same tree shape as its semantic structure implies.

>>It's more inflexible. I can't do:
>>  start()
>>    do_a()
>>    do_b()
>>  commit()
>>And occasionally that would be nice.

> Granted.  But as I said, Python is still not "inflexible"; it's at worst
> less flexible (as you accurately said).  Case sensitivity _is_ accused of
> inflexibility, and in fact it IS inflexible.

Depends on the ways you look at it; just like indentation. It's
inflexible in the sense that if I write 'foo', you'll have to write
'foo' too if you want to refer to it. (I happen to like this inflexibility
because I like the enforced consistency)

It's *more* flexible than case-insensitivity in another way though. I can
use both 'foo' and 'Foo' for different names in the same namespace. 
This flexibility is exploited in common Python idioms.

> Furthermore, there's not
> even any linguistic reason for its existance; its only effect is to
> increase the number of possible symbols, and no programmer wants to
> maintain a program which actually uses case sensitivity to its full power.

Um, I use it to its full power because I like the enforced consistency.
I know you don't buy that argument, but that doesn't mean I don't. :)

What would 'using it to the full power' mean in your opinion?

> And for that matter, this example is easy enough to "solve" using a blank
> try-block:

> try:
>    start()
>    do_a()
>    do_b()
> finally: commit()

No, the semantics of this are entirely different and *wrong*. This
always commits, even if an exception was raised in my code, which is
*exactly* what I didn't want.

[snip]
>>> I don't think it's silly, either; I've complained enough about languages
>>> which don't do this right, such as Make.

>>Right -- Make is rather unwritable. There are no advantages there.
>>I still don't see how these people relate to our present case;
>>these people are complaining (without having actually tried it; anyone else
>>complaining is of course in his or her right to complain) about decreased
>>freedom you get with Python's indentation scheme.

> They're not complaining, by and large, about decreased freedom; if they
> were it would be a lot easier to ignore them (because they'd be correct).
> They're complaining about total lack of freedom.  They're wrong because
> Python has considerable freedom.

All right. Though there is a total lack of freedom in placing the
braces; you don't at all, really.

>>Now you say we should cater to people like that, offering them more
>>freedom (in case spelling), while nobody of *those* people appears to be
>>complaining about that, and while the reason many people (not you) like
>>Python's indentation *is* increased consistency and therefore increased
>>readability.

> Actually, I like the enforced consistency as well --

*faints* :)

> but I think it's far,
> drastically, more important that there be consistency between how the
> languages behaves and how it looks.

Ah. And but currently the language behaves in a case sensitive matter;
classes behave in a dictionary-like way, and string dictionary keys are
case sensitive unless you do something special. As a consequence,
getattr() and friends are case sensitive. It might be possible to
write a Python script that can determine if it's running in a case
sensitive version of Python or not.

> I really don't care if the programmer
> is required to dot his i's, keep case consistent, or use the same
> indentation for all 'if' clauses.  Those consistencies are _minor_
> compared to the ones we really need -- things like good variable names,
> clear syntactic structure, and so on.

Oh, agreed. Though again, the didactic argument might make sense that if
a newbie is taught consistency on the lower syntactic level, he is then
more likely to be also consistent on the other levels. Besides, 
consistency *is* important on the syntactic level anyway to get your
code through the compiler.

>>> There are two obviously terrible errors: inconsistency and inflexibility.
>>> There's no reason to assume that avoiding one will force everyone into the
>>> other, and I'm not making that mistake about you.

>>I'm not quite sure I understand the language. Right now we avoid
>>inconsistency and we also avoid inflexibility in the case-spelling
>>domain.

> Right now we are almost as inflexible as we could get.  We're not at a
> level I would call "bad" (I would imagine recieving errors when using
> alternate casings of words to be "bad").  On the other hand, loosening up
> a bit isn't going to bring us anywhere near to the realm of anarchy some
> Of yOu SeEm to PiCtuRe.

Yes, though perhaps a bit nearer than you suspect. Besides that, there's
the decreased flexibility (foo = Foo()) and definite increased inconsistency
*between* modules if not intra module.
 
>>There are minor disadvantages which apparently confuse newbies,
>>so we ought to think about how to improve matters.

> Good way of stating things.  Do you have any alternate ideas on this
> issue?  I don't -- but that's because I'm reasonably satisfied with this
> solution.

Better NameError and AttributeError reporting could help (there was a
patch posted to the newsgroup).

>>But case-insensitivity gives up consistency and case-enforcing gives up
>>flexibility; so it seems we shouldn't go anywhere. :)

> A false consistency is the hobgoblin of little minds.

Consistency-makes-it-easier-for-little-minds-to-read-code-ly yours,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?