Case Sensitivity

Case Sensitivity is Bad:

One way in which Windows and Visual Basic tends to be better than Unix and C++: case sensitivity. Windows has a case-insensitive filesystem, and Visual Basic has case-insensitive variable names. It's a little annoying in Windows when the shell automatically recases filenames, but if you think DllHell is bad now, imagine if you had something like "MSVCrt.Dll". And one of my favorite things about the VisualBasic editor is that you can type in any case you want, and declared variables will snap into the correct case as you type.

Capitalization errors are as common as spelling errors and typos, but harder to spot because the human mind is trained to see lowercase and uppercase letters as equivalent. Well, the normal human mind is. People who have been knee-deep in Unix and C++ for years have probably learned that variable != Variable, and have finely-tuned their brains to remember capitalization as a vital part of the word, and not the simple matter of orthography it is in the English language.

Case sensitive systems lead to bad design decisions, such as making one include file named "string.h" and another named "String.h". I pity the fool who accidentally types "STring.h". On another Wiki, I saw a Python programmer struggling because he had a module named "TOOL" that imported a module named "tool". Case-sensitive command sets not only leave a program vulnerable to CapsLock-related disasters, but also create a user-hostile learning curve.

Most Unix commands and utilities have very specific command sets. From the ls command to the ViEditor and the NetHack game, your little finger resting on that SHIFT key means the difference between sorting by date and listing in columns, between moving the cursor and merging two lines, or between throwing an object and taking off your armor. In each case, two very different options, and as we all know, TwoIsAnImpossibleNumber. So both vi and nethack have metacommands that require you to press colon or hash and go into a whole other command set. And in vi, this set is case-sensitive as well. The Unix user accepts it gleefully, having been baptized in case-sensitivity. The Window user may accept it grudgingly. Your grandmother would see it as further evidence that your computer is filled with evil spirits.

It would be better if case sensitivity at least served some sort of consistent purpose. In Wiki, for example, uppercase letters are used in lieu of spaces, and the WikiName is a kind of markup, so it works and doesn't scare the user. The RubyLanguage enforces a naming convention where constant names, including classes and modules, must begin with uppercase letters, while variable names, including functions, must begin with lowercase letters. In this way, it actually reduces conflict and ambiguity, rather than creating it. It's still possible to create SmartAleckCode? that uses "TOOL", "Tool" and "tool", but at least the names give you a clue to what they might be. A similar use might be a ColorForth variant for the ColorBlind, where capitalization takes the place of one or more colors.

-- NickBensema

Case Sensitivity is Good:

It allows you to put the different kinds of symbols in a NameSpace of their own. That is, if you name all constants with all caps, classes with first-caps, methods and locals with lower-firsts, you never have to worry about a conflict of any kind. If the best name I can come up for an instance of "Listener" is "listener", then I can say "Listener listener" with ease.
It forces consistency. Consistency in the little things, such as capitalization, might be a case of FixBrokenWindows. ForcingPeopleToDoRight is an interesting (though dangerous) philosophy.
Most importantly, it is the only reasonable way to handle the problem in terms of internationalization. Different languages and character sets have different case-collapsing rules under different circumstances.
...?

Actually, the "Listener listener" example is the reason I don't mind RubyLanguage's case-sensitivity; as I said before, it serves a purpose. -- NB

I think what you want is not case sensitivity, but just EnforcedConventions?. To prove case sensitivity as good, you would need to prove the need for

 Listener listener

over the many variants (_listener, myListener, my_listener, listnr, l, separate namespaces for classes and variables, syntactic disambiguation, etc.).

"Listener listener" is smelly redundancy.