Case sensitivity

[Alex Martelli]

Greg Ewing (using news.cis.dfn.de) wrote:

> Alex Martelli wrote:
>> If you think so, then I believe you should reply to Marc
>> Andre Lemburg's explanation of the rationale for that design
>> in his followup to my post.  I happen to agree with Marc
>> Andre that the rationale is sound
> 
> Marc, I'd like to apologise for any aspersions I may
> have inadvertently cast on mxDateTime. I'm not
> familiar with that particular module, and I was
> taking at face value Alex's apparent suggestion that
> it made random choices about use of case.
> 
> I now understand that the choices are not random, and
> that there is a rationale behind them. But then, if
> there is a clear rationale, the cases shouldn't be
> so hard to remember as Alex was making out.

The rationale is perhaps clear, but it just doesn't
clearly APPLY to every single case -- thus you need to
memorize e.g. which functions have been conceptualized
as factories/constructors and which have been instead
conceptualized as utilities/just functions.  This extra
memorization burden is sheer cost, without benefit, and
ONLY because of case sensitivity.


>> Think of the issue more generally.  Classes by convention
>> should have capitalized names, while functions have names
>> that are lowercase.  So what we do for factory functions,
>> which are, yes, functions, but also "constructors" for
>> class instances?
> 
> Yes, I know situations like this occasionally arise. An
> example occurs in Plex, where I have a bunch of things for
> constructing regular expressions. Most of them are classes,
> but a few are factory functions. I decided to make them
> all start with an upper case letter, because as far as
> the user is concerned, they're all constructors of one
> kind or another.

Yep, same situation as in mx.DateTime and any other module
that has "constructors"/"factories" of such kinds.

> But, in my experience, situations like this are rare, and

We've already seen two modules -- Flex and mx.DateTime --
where they happen, not to mention the many cases in the
Python standard library, such as audiodev.AudioDev.

You seem to alternate between criticizing any such
occurrence as "bad design" (as you've done for the
standard library in general, though I haven't seen you
doing it specifically for audiodev for example) and
handwaving if away as "rare",

So basically, you're trying to deny or minimize this
COST of case-sensitivity, no doubt because you are so
attached to it for other reasons that you just need
to convince yourself and/or others that it MUST be a
good thing, period.

But if there should (unlikely as it may be) be any
readers of this useless and interminable thread who
are neutral on the issue, I suspect such readers would
see the repeated denials as meaningful in this way.


> the vast majority of the time I don't have any problem
> deciding whether something ought to start with an upper
> case letter or not. *Most* things are either clearly
> classes or clearly functions.

Granted -- so what if the cases in which this isn't clear
are a minority?  They still do occur, over and over and
over again, and each and every time they impose a sheer
memorization cost.

Really, I think that of all the "arguments" brought by
the sensitivity-defender camp, the most telling is the
one about "it's easier to implement this way" (in a few
guises).  Case sensitivity is an implementation artifact
that happened to "leak over" into the interface -- and
sadly, now, ingrained habit has engendered large groups
who are wilfully blind to its human-factor costs.  (I
do not know if there were other widespread case sensitive
languages before C went that way 30 years ago, but C's
success is IMHO what spread the case-sensitive meme, just
as it's what's making some people eager for x?y:z...;-).


>> And people who still have not
>> entirely memorized the exact capitalization of every name
>> exported by the module will get runtime errors
> 
> Again in my experience, it only requires getting to know
> the conventions used by the authors of the modules I'm
> using -- in other words, it's a per-module piece of
> knowledge to memorise, not per-name. But perhaps I'm

Except that inevitably you come across, over and over
again, things that can be perfectly well be conceptualized
either way, such as function 'today' in mx.DateTime that
might be thought as either a constructor or a utility, &c.

> lucky enough not to have encountered too many different
> sets of conventions, or any that are too wacky to get
> my head around. If Alex's experiences are different,
> he may well see things differently.

Careful: you're contradicting your stance in another
post, where you condemn the design of Python's standard
library for using "too many different sets of conventions".

Now, you can hardly claim to NOT have "encountered" the
Python standard library, can you?  So in one post you
criticize that library for its multiple conventions, and
in this one you claim you just haven't encountered such
multiple conventions (and the memorization burden they
impose "thanks" to your beloved case-sensitivity).  Don't
look now, but I think your bias is showing...;-).


Alex