Why are many languages case sensitive?

Question

Is it simply a matter of inheritance? C++ was case-sensitive because C was, Java is case-sensitive because C++ is, etc? Or is there a more pragmatic reason behind it?

Answer 1

I don't think you'll get a better answer than "because the author(s) of that language thought it was better that way". Personally, I think they're right. I'd hate to find these lines anywhere in the same source file (and refer to the same object+method)...

SomeObject.SomeMethod();
...
SOMEOBJECT.SOMEMETHOD();
...
someObject.someMethod();
...
sOmEoBjEcT.sOmEmEtHoD();

I don't think anyone would be happy to see this...

Answer 2

My guess would be that case sensitivity enlarges the name space. A nice trick such as

MyClass myClass;

would be impossible with case-insensitive compiler.

Answer 3

Back when parsing and compiling was real expensive and would take all night it was advantageous to the compiler if it didn't have to worry about case.

Once indentifiers came in to existance that were only unique via there case it became very difficult to go back. Many developers liked it and there doesn't seem to be a big desire to undo it.

Answer 4

It's actually extremely practical, both for the developer and for the language syntax specification: lower/upper case distinction adds a great deal of expressiveness to identifier naming.

From the point of view of the language syntax, you can force certain identifiers to start with a lower or upper case (for instance Java class name). That makes parsing easier, and hence helps keeping the syntax clean.

From a developer point of view, this allows for a vast number of convenient coding conventions, making your code clearer and easier to understand.

Answer 5

Case sensitivity adds to language readability by the use of naming conventions. You can't write

Person person = new Person("Bill");

if your language is case insensitive, because the compiler wouldn't be able to distinguish between the Class name and the variable name.

Also, having Person, person, PersoN, PeRsOn, and PERSON, all be equivalent tokens would give me a headache. :)

Answer 6

One interesting thing to consider is that English is also case-sensitive. (I suspect this is true for most natural languages, but it may well not be true for all.)

There's a big difference (where I live, anyway, near the town of Reading) between:

I like reading.

and

I like Reading.

Similarly, while many people do capitalise incorrectly, and you can usually understand what is meant, that doesn't mean such writing is considered correct. I'm a stickler when it comes to this kind of thing, which is not to say I get everything right myself, of course. I don't know whether that's part of the inheritance of programming language case sensitivity, but I suspect it may be.

One distinct advantage of case sensitivity for programming languages is that the text becomes culturally insensitive as well. It's bad enough having to occasionally spell out to a compiler which text encoding is used for a source file - having to specify which culture it's in would be even worse :(

Answer 7

Case folding is only simple in English (and for all characters < 128). The German sz or "sharp s" (ß) doesn't have an upper case variant in the ISO 8859-1 charset. It only received one in Unicode after about a decade of discussion (and now, all fonts must be updated...). Kanji and Hiragana (Japanese alphabets) don't even know lower case.

To avoid this mess, even in this age of Unicode, it is not wise to allow case folding and unicode identifiers.

Answer 8

How do you yell if you dont HAVE CAPS! AHHH!

Have to be expressive. But in all honesty, of all the people in the world, those who work with programming logic would be the first to insist that differences are in fact differences.

Answer 9

Lots of people here have said that it would be bad for several forms of capitalization to refer to the same thing, e.g.:

person
perSoN
PERSON

What would be really bad is if these all referred to different objects in code. If you've got variables person, perSoN and PERSON all referring to different things, you've got a problem.

Answer 10

Case sensitivity doesn't really help case consistency.

Foo.Bar  
foo.Bar  
fOO.bAR

In a case insensitive language that can be fixed automatically by the editor easily. In a case sensitive language fixing it it's harder as it may be legal. The editor first has to ckeck if foo.Bar and fOO.bAR exist and also has to guess that you typed with the wrong case rather than forgetting to declare the variable (as Foo is different to fOO).

Answer 11

Because many people find employeeSocailSecurityNumber just as readable as employee_social_security_number and it is shorter.

Answer 12

Not an answer - I agree in part with Aaron Digulla and also like having consistency mandatory - but a couple of examples why this isn't to do with disambiguating values and types.

Both Java and Common Lisp have separate namespaces for variables and classes, so neither of these snippets are ambiguous. One language is case sensitive, the other isn't. The Java syntax defines where a type or a variable is expected, so it is not ambiguous to having the same identifier with different bindings in the class and value (and for that matter package) namespaces. Symbols in Common Lisp are effectively insensitive to case (being interned as uppercase by default), and doesn't use syntatic clues to differentiate types and values. Instead it uses different resolution operators to resolve the symbol 'Person in the value or class namespaces.

Java:

public class Person {
    public static void main (String...args) {
        Person Person = new Person("Bill");

        System.out.println(Person.Name.equals("Bill"));
    }

    Person (String Name) { 
        this.Name = Name;
    }

    String getName () { return Name; }
}

Common Lisp:

> (defclass person () ((name :accessor person-name :initarg :name)))
#<STANDARD-CLASS PERSON>
> (setf person (make-instance 'person :name "bob"))
#<PERSON #x00033465FC40>
> pErSon
#<PERSON #x00033465FC40>
> (equal "bob" (person-name PERSON))
T
> (find-class 'PERSON)
#<STANDARD-CLASS PERSON>

Answer 13

Because they're as dumb as a box of frogs, for precisely the reasons given for the opposite viewpoint in this thread (I'm not even gonna ask what that's about. Wood for the trees and all that).

When FOOBAR = FooBar = foobar, you get to choose your convention, and other coders can do the same whether they share your preference or not. No confusion.

They also can't get away with the stroke of genius that is having a constant, function and variable all with the same name in the same file, albeit with different caps. Again, no confusion.

You call your variable WebSite, they call theirs Website, and which system gets confused? Not an easy catch either, when you're scanning.

As for lookups, is it really that much more processing to convert the name to lowercase before looking it up? Doing your own premature optimisation is one thing, expecting it from the developer of your language of choice is a whole other level of missing the point.

...and yet, all these answers saying case-sensitivity reduces confusion. Sigh

Answer 14

Many (non-programming) languages (e.g. European using the Roman alphabet) are case-sensitive, so it's natural for native speakers of those languages to use upper- / lower-case distinctions.

The very idea that programming languages wouldn't be case-sensitive is a historical artifact arising from the limitations of early-generation hardware (including pre-computer teletype machines that used a 5-bit character code).

People who argue for case-blind languages must be unable to distinguish

IAmNowHere

from

IAmNowhere

(It's a joke! ;-)

Answer 15

UNIX.

UNIX was case sensitive and so the first programming languages were case sensitive.

Computers are not forgiving - an uppercase character is not the same thing as a lowercase character, they're entirely different. And back when processing cycles, RAM and so forth were expensive it wasn't seen as worth the effort to force compilers and computers to be "forgiving", people were just trying to get the things to work.

Notice how case insensitivity didn't really become something useful until things like VB came along - once companies started to get invested in the concept that getting the masses to program was a good thing for their bottom line (i.e., Microsoft makes more money if there's more programs on Windows) did the languages start to be friendlier and more forgiving.

Answer 16

There's also Common Lisp, which is a case-sensitive language that many people mistakenly believe is case-insensitive. When you type (car x) into the Listener, it turns into (CAR X) for processing. It is possible to define symbols with lower-case names, but they have to be quoted with something like |lower-case-symbol|. Therefore, typing in (car x) or (CAR X) or (Car X) all works the same.

(Franz Lisp was at one point introducing what they called "modern" capitalization, in which the Listener would not fold cases, and CL keywords would be in lowercase. I never followed it well enough to know what happened there.)

Answer 17

0 vote down Jim:

I'm afraid I know of no compiler that will evaluate 'Socail' to 'social'. I thought I was the only one with a transpositional propensity!

Because many people find employeeSocailSecurityNumber just as readable as employee_social_security_number and it is shorter.

Answer 18

What is the capital form of i? I (U+0049) or İ (U+0130)?

Capitalization is locale dependent.

Answer 19

Looks like people mostly agree that case sensitivity is important and I agree.

However, it can be annoying when you have to type something in the correct case so I think the IDE should let you type in the wrong case, but if you hit the auto-complete shortcut it should do case insensitive matching. This gives us the best of both worlds.

Answer 20

The upper-case of a letter isn't a universal concept. Java uses Unicode, so if you wanted case-insensitive Java, the meaning of your program could change depending on what locale it was compiled in.

Most languages don't let you put dots or commas (or apostrophes or spaces) in the middle of integer literals, probably because that's also locale-dependent.

Answer 21

From .NET Framework Developer's Guide Capitalization Conventions, Case-Sensitivity:

The capitalization guidelines exist solely to make identifiers easier to read and recognize. Casing cannot be used as a means of avoiding name collisions between library elements.

Do not assume that all programming languages are case-sensitive. They are not. Names cannot differ by case alone.

Answer 22

ExpertSexChange

I believe this is a competitor to StackOverflow where you have to pay to read answers. Hmm... with case insensitivity, the meaning of the site's name is ambiguous.

This is a good reason for languages being case-sensitive. Less ambiguity! Ambiguity to programmers is considered yucky.

Answer 23

I think having a case-sensitive language ENCOURAGES people to write poor code.

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

function shoeSize(SHOEsize) { int ShoeSIZE = 10 return ShoeSize }

Duh. You couldn't think of a better variable name than "ShoeSize" for the different purposes???? There a billion different words you could use... but you choose to just keep using ShoeSize instead?

Answer 24

MyClass myClass; would be impossible with case-insensitive compiler.

Or you could be smart and actually use 2 different words... that better show what you are actually trying to do, like:

MyClass myCarDesign;

Duh.

Answer 25

And you could also (foolishly) just use single-letters ("a" and "b" and "c") for all classes, variables, functions, and methods.

But WHY would you want to????

Use... names... that... make... sense. Not:

function a(a) { int a = a.a; return a }

Answer 26

Every example I've seen supporting case sensitivity is based on a desire to write bad, undescriptive code. e.g. the "date" vs. "myDate" argument - these are both equally undescriptive and bad practice. Good practice is to name it what it actually is: birthDate, hireDate, invoiceDate, whatever. And who in their right mind would want to write code like:

Public Class Person
    Public Shared ReadOnly PERSON As Person
End Class
Public Class Employee
    Public person As Person = person.PERSON
End Class

Amazingly this is perfectly valid case insensitive VB.Net code. The thought that case sensitivity allows you to even more flagrantly disobey good programming practice is an argument against it, not for it.