Why is there still case sensitivity in some programming languages?

Question

I don't see any use for case sensitivity in a programming language, apart from obfuscating code.

Why implement this in a programming language?

Update:

It looks like someone you know made a statement on this.

Answer 1

While case folding is fairly trivial in English, it's much less so in some other languages. If a German programmer uses ß in a variable name, what are you going to consider the upper-case equivalent? Just FYI, "ß" is only ever used in lower case. OTOH, "ss" is equivalent -- would you consider a compiler obliged to match them? When you get into Unicode, you get even more interesting problems, such as characters with pre-composed diacritical marks versus separate combining diacriticals. Then you get to some Arabic scripts, with three separate forms of many letters, rather than just two.

In the dark ages most programming languages were case-insensitive almost out of necessity. For example, Pascal started out on Control Data mainframes, which used only six bits per character (64 codes, total). Most such machines used the "CDC Scientific" character set, which only contained upper-case characters. You could switch to other character sets, but most had either upper-case or lower-case, but not both -- but used the same codes for both. The same was true of the ancient Baudot codes and such considered standard in the beginning days of COBOL, FORTRAN, BASIC, etc. By the time more capable hardware was widely available, their being case-insensitive was so thoroughly ingrained that changing it was impossible.

Over time, the real difficulty of case-insensitivity has become more apparent, and language designers have mostly decided ("realized" would probably be a more accurate term) that when/if people really want case insensitivity, that it's better handled by ancillary tools than in the language itself.

At least IMO, compiler should take input exactly as presented, not decide that "you wrote this, but I'm going to assume you really meant something else." If you want translations to happen, you're better off doing them separately, with tools built to handle that well.

Answer 2

Why would anyone WANT case insensitivity? In what scenario is it useful to be able to refer to a single variable as VARIABLE in one place, Variable in another, and variable in a third? Case insensitivity is exasperating. I’d much rather get a compiler error when I accidentally type VAriable instead of Variable rather than let case-typos like that slip into my code.

In conclusion, many programming languages have case sensitivity not just for historical/inertial reasons but because case insensitivity is a Bad Idea.

Answer 3

In Java case sensitivity is NOT used to provide more options in code, but rather for a very clear and consistent semantic meaning. ClassesLookLikeThis. objectsLookLikeThis. methodsLookLikeThis(). STATIC_VARIABLES_LOOK_LIKE_THIS. Classes.WithInnerClassesLookLikeThis. It does NOT provide greater freedom: it allows you to pack some information concisely into what is an otherwise overly verbose language.

I think that in explicitly statically-typed languages with mucho compiler and IDE support, case-sensitivity is a great way to communicate information (e.g., Java). With languages like Ruby, case insensitivity would probably cause even MORE unexpected results, though I'd be open to trying case-insensitive Ruby.

I think that case sensitivity with a strict system does not obfuscate code but actually makes it clearer. Consider possible Java code:

      joe blah = new hUf();

that's pretty clear, but what about:

      hUf.WTF();

In Java as-it-is, you would automatically know what this is. In case-insensitive Java, it's ambiguous, so you'd need to resort to some other mechanism to differentiate classes from instances from packages from methods. And THAT mechanism would probably make you vomit with how ugly it is :)

Answer 4

If nothing else, it simplifies parsing and allows you more combinations for variable/class names.

With case-insensitive parsing, you'd be restricted to having to use unique identifiers, since 'myClass' and 'MyClass' would be the same thing. Alternatively, you'd have to add layers of complexity to your parser to make sure you could determine which identifier is used based on context.

Consider a case like this:

XmlWriter xmlWriter = new XmlWriter();
xmlWriter.Write("blah");

Suppose the XmlWriter class also has a static method called "Write". Are you calling it on the instance or on the class, if there is no case-sensitivity applied here?

Answer 5

I don't think it was "implemented" so much as "allowed." Case sensitivity is the default state of string comparisons; it takes extra work for the compiler engineer to make a language case insensitive, since you need to add in extra code to perform case-insensitive comparisons and preserve the original token names for correct error and warning reporting.

That's almost certainly why it ended up in C; they wanted to make a simple language that was easy to implement a compiler for, at the expense of usability. As for why it's in modern langauges? Because it's in C, of course, so it must be the right way to do it! </sarcasm mode>

Answer 6

I like case sensitivity if for no other reason than it makes the code more self-documenting:

this is a CONSTANT
this is a ClassName
this is a methodName
this is a local variablename

I typically program in Python, but back in my C# days, I found it very convenient to name class instances the same as the class, but lower (or camel) case (as others have said):

Thing thing = new Thing();

Using case-insensitive languages requires some other convention for this, i.e., some sort of sigil like:

Thing oThing = new Thing()
Thing instanceOfThing = new Thing()

Which is a "bad thing".

I also find it convenient to grep (case-sensitively) to find reference to a class vs. uses of a variable. With a case-insensitive language, this would be less easy. Same for search & replace.

Lastly, as a programmer, when I see words with different cases, it jumps out to me that they are different things...I rarely have bugs where variable cases were wrong, even in dynamic, scripted languages where a compiler would have helped.

Answer 7

People pay attention to the shape of words before they actually read them. Case sensitivity keeps the shape of a symbol consistent throughout code. I also agree with those above that state that different conventions denote different types of symbols. Case sensitivity and insensitivity can both be abused. Bad programmers will always generate bad code... they will find a way.

Take language as an example. Why do we start sentences and named things with capitals... Is it also because of unix?

Answer 8

I think for statically-typed lanaguages like C# and Java, it doesn't actually add any value. Because in most cases, you've got an IDE that'll auto-correct case mismatches for you anyway, so at the end of the day, if I type in "VAriable" by accident, my IDE will auto-correct that to "Variable" for me. Add to that the MyClass myClass; style conventions and you can see that case-sensitivity is not necessarily a bad thing.

For dynamically-typed languages, there might be more of an argument, since it's harder for an IDE to guess an autocorrection, but in the case of dynamically-typed languages, you've already got so much more to worry about (in terms of typos) that using a consistent casing convention isn't going to add that much more burden.

So yes, while there's no real reason languages could not be case-insensitive, there's also no real reason why they should be either.

That article from Scott Hanselman about "SignOn" vs "Signon" was about string comparisons, and nothing to do with programming languages. I agree that strings that users type in should always compared case-insensitively, but I think that's a different ballgame to identifiers in a programming language.

Answer 9

When a language is case-sensitive, I take advantage of it to reproduce conventional case usage in mathematics and science. Here is a list (by no means exhaustive) of some case conventions:

• In probability theory, lower case f usually represents a probability density function (pdf), while upper case F represents the corresponding cumulative distribution function (cdf).
• Also in probability theory, upper case letters denote random variables X, and the corresponding lower case letters denote their realizations x, as in $Pr[X=x] \leq 0.05$.
• In linear algebra, upper case letters are generally used to refer to matrices while lower case letters generally are used to refer to numbers, e.g., $A=[a_{ij}]$.
• Unit symbols are written in lower case letters (e.g., m for meter) except for liter (L) and those units derived from the name of a person (W for Watt, Pa for Pascal, N for Newton, and so on).
• Symbols of prefixes that mean a million or more are capitalized (M for mega (millions)), and those less than a million are lower case (m for milli (thousandths)).

Answer 10

I just figured it was because of Unix and C - but that's kind of a chicken and the egg problem which only the geezers can answer properly.

I use the rationale that the Chickens in "The Easter Bunny is Coming to Town" used when asked whether they came before Eggs. Because there were chickens on Noah's Ark, chickens came first. Therefore, because GCC runs on Unix, Unix came first, therefore because Unix cares so much for case, C and all its variants and descendants, yea anything that imposes curly braces, cares for case.

There probably is a link between curly braces and case sensitivity too.

Answer 11

In addition to the excellent answers given so far, I'd like to point out that case sensitivity gives you also additional "namespaces". For example Perl has some special blocks like BEGIN and END that run at different times than normal code (BEGIN at compile time, END after the normal program has terminated), and having those as all-caps makes them stand out, and means that the lower case variants aren't reserved words.

One can go even further and reserve all-uppercase names for future use by the language, and don't do any harm to normal programmers, who usually DON'T SHOUT IN THEIR CODE.

Answer 12

"Case sensitive" is always better for technical persons to reduce ambiguity. Take filename as an example. Dealing with Windows filename is more trouble than Unix filename because filename in Windows is case-insensitive while filename in Unix is case-sensitive.

Back to programming. For class name, method name, variable name, most language do not enforce the naming style rule. Sometimes for the sake of simplicity to do "reflection", we can simply use the "Case sensitive" name to bind to other data source without conversion, or handling the problem of same name but in different case.

Answer 13

I'm surprised by this rant. Now that nobody wants you to use an underscore or an m_ in a field name in C#, I've just been using camel case, and if the field name is the same as a public property name, just that the public property name is Pascal case and the backing field is camel case, I figure, "so be it" - that's what the programming community at large seems to want. It hasn't caused any problems so far.

Answer 14

Especially some programmer come from the early days of BASIC, where a variable name can only be 2 characters long.

And so, when it can be any number of characters, they become very happy. And along with case sensitivity -- because they don't want to also care about SomeName being accidentally equal to SOMENAME and cause a bug due to things like this.