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

[William Tanksley]

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:
>>>> On 30 May 2000 10:59:24 GMT, Martijn Faassen wrote:

>>>>>That's nice to say, but you don't agree with that yourself if you think
>>>>>Python's use of indentation is a good thing. It can help a lot if the
>>>>>language makes it impossible to be inconsistent. Unless you think the
>>>>>_only_ advantage of Python's indentation strategy is the lesser line 
>>>>>count.

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

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

>>>> 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 case sensitivity is not flexible: once you write a variable name
one case, you're required to write it the same way.

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.

>>>Consistency in style happens to one of the most important factors that
>>>makes code look good (on the syntactic level). Your indentation looks
>>>better in Python because Python complains loudly if you don't indent properly.
>>>That's not the most important thing though; you can indent properly in
>>>any language. It's just that everybody indents properly in Python, and
>>>more or less in the same way.

>> Again, Python code looks good not because consistent indentation is
>> enforced, but rather because indentation alone is used to draw a tree
>> structure.

>But indentation is *always* used to draw a tree structure. Python *enforces*
>this tree structure, but it's not as if you can't draw tree structures
>in C.

"indentation alone" I said, and "alone" is critical.

>> Consider the following example of inconsistent indentation:

>> if something:
>>        do_it()
>> else:
>>  dont_do_it()

>> Python will happily accept this.  It'll even happily accept this for long
>> blocks, here it can be inconvenient.  This makes the code a bit harder to
>> read, but it'll still not bad -- because Python expresses a 2-dimensional
>> structure (the syntax tree) in a 2-dimensional form.

>> Most ugly code I've seen isn't ugly because it has poor indentation
>> (although I have seen some); most of it's ugly because of horrible naming,
>> or bad structuring, or ...

>Well, obviously indentation can't help in case of horrible naming and
>bad structuring. But you say indentation makes code look better, and that's
>not because it improves horrible naming or bad structuring but because
>it improves something else. 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.  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.

>>>> More recently I've come to realise that the reason Python indentation
>>>> looks good is that Python, like most modern languages, is a
>>>> tree-structured language, and so is best represented in two dimensions.
>>>> Most modern languages, however, attempt to represent themselves in one
>>>> dimension: an ASCII stream which ignores lines and whitespace.

>>>Well, why shouldn't a programmer enforce such indentation in any
>>>language?

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

>>>Indentation looks good in any language, not just Python, so
>>>that's not really an argument for Python's indentation style.

>> Well, there you go -- my point exactly.  I was saying the same for case
>> (which Python enforces much more consistently than it enforces
>> indentation).

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

>> In fact, the nice thing isn't that Python enforces indentation consistency
>> (because it doesn't really, any more than the minimum): the nice thing is
>> that Python doesn't throw anything more in your way than you really need
>> to parse the tree.

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

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

Python breaks away from that.

>>>Besides, if you ignore case you ignore that words in Python are spelled
>>>consistently in case, which is *also* a property of lots of modern languages.
>>>Sometimes not enforced, but still a desired property of the programmer.

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

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

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.

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.

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

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

>>>> 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, and offers a
danger (but not a certainty) of becoming less readable.  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.

>> And I like polymorphism (which implies typechecking).

>I'm not quite sure what you mean by 'polymorphism' in this context. We
>seem to have polymorphism as far as I understand it already?

Sorry.  I meant parametric polymorphism, which does imply static
typechecking.

Of course, I also like to be able to do things the current way, with no
static typechecking.

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

>>>According to your argument, you will just enforce this consistency
>>>yourself. The problem is that, *even* if everybody enforces self
>>>consistency, people will enforce *different* consistency and their
>>>coding style will vary over time. From a maintenance and communication
>>>point of view, this is bad. 

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

>but
>if we grant that, I still disagree that case-sensitivity only matters
>for newbies. How does it not matter for case sensitivity? If Foo writes
>a module and you use it in your module, but you use a different case
>spelling for common variables (but consistently!), and then I get to
>maintain it while I've been using another case spelling when I used
>that module all the time, wouldn't that hurt me?

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

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

>>>> Take a lesson from the people complaining
>>>> about Python's indentation: one of the leading false accusations is that
>>>> it's inflexible, that it won't allow people to choose thier own
>>>> indentation.

>>>I don't see how this maps to the case sensitivity argument at all. 
>>>Python's indentation *is* less flexible in what code-layouts are
>>>allowed, and it *is* a silly accusation.

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

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

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

>There are other examples, which I'm
>sure the complainers can come up with. Where the complainers are wrong
>(though it's their personal taste, but they should actually *try* it
>before they complain) is that they don't see the significant advantages
>which outweigh these minor disadvantages.

I agree here.

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

>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 -- but I think it's far,
drastically, more important that there be consistency between how the
languages behaves and how it looks.  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.

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

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

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

>Martijn

-- 
-William "Billy" Tanksley