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

[William Tanksley]

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

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

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

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

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

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.

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

In fact, it's conceivable to have a case-insensitive language which prints
an error whenever an alternate case spelling is used.  I think that would
be silly, but it would seem to fit what you want FAR better than a
case-sensitive language ever could.

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

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

>I want my language to enforce the amount of parameters I pass to
>a function, unless I overrule it myself. I want my language to consistently
>enforce namespaces. I want my language to language to be consistent in
>the way I can call functions (foo(1, 2) and not also foo 1, 2). I want
>my language to be consistent in the way I spell keywords (I don't
>want to see code with IF and ELIF all over the place while other modules
>use 'if' and 'elif'). I want the language to be consistent about rejecting
>things that make no direct sense ( 1 + "foo"..see also the discussion on
>1/2).

And I like polymorphism (which implies 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, I won't
consider them prerequisites to using the new Python -- I'll use the new
Python if it feels like an improvement.

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

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

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

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.

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

>Martijn

-- 
-William "Billy" Tanksley