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

[Martijn Faassen]

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:
>>>>William Tanksley <wtanksle at dolphin.openprojects.net> wrote:
>>[snip]
>>>>> Your rhetorical questions answer themselves.  Why should a programmer
>>>>> enforce these things?  Because it's stupid to NOT enforce them.  So
>>>>> enforce them already!

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

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

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

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

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

All right.

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

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

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?

> In fact, it's conceivable to have a case-insensitive language which prints
> an error whenever an alternate case spelling is used.

That's not a case-insensitive language. That's a case-sensitive language
which forbids words which vary only in case-spelling.

> I think that would
> be silly, but it would seem to fit what you want FAR better than a
> case-sensitive language ever could.

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

> So if you wrote:

>   no = 1
>   No = 2 # error!
>   print NO # error!

> I don't like that -- but it proves that case insensitivity can be more
> powerful in terms of enforcing style.

Ahum? Is this case-insensitivity or case-enforcing? This is currently
what happens in Python, as long as you haven't assigned to 'No' or 'NO'
elsewhere. The case enforcing addition would then reject assigning to
'No' or 'NO' after the assignment to 'no'.

> It also seems to indicate to me at
> least that I don't want a language enforcing THAT much style, any more
> than I'd want Python to require exactly one tab or two spaces or any other
> fixed amount for indentation.  Thank you, I'll decide that on my own.

Right, but it turns out to be the case that the current setup doesn't enforce
that much style (because the language becomes harder to write). It does
give you plenty of errors if you spell things case-inconsistently, but
you can if you want to. A few more warnings would be nice, though this would
require some code analysis. The recent patches for 'NameError' seemed nice,
though.

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

[snip examples of consistency that are nice]

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

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

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

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

It's easy to say that it won't matter for communication and maintenance,
but could you try backing that up?
 
>>> 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. 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 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. 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.

> 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. There are minor disadvantages which apparently confuse newbies,
so we ought to think about how to improve matters. But case-insensitivity
gives up consistency and case-enforcing gives up flexibility; so it
seems we shouldn't go anywhere. :)

>>So I don't see why I should take a lesson from this complaint or those
>>people. Besides, people who make this silly accusastion generally use
>>languages which *are* case sensitive. So I don't see how this relates to
>>anything.

> Are you trying to miss the point?  I don't think it's working, because you
> previously argued on the point.  I'll confess that you're trying hard,
> though -- three consecutive sentances which miss the point in three new
> ways.

There must be some error in communication here. I genuinely miss the
point. Next time you say I miss the point would you please be so
kind as in explaining what the point is, even though you suspect I'm
deliberately missing the point? It's generally kinder to assume
stupidity and not malice. :)

Regards,

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