Who Needs Case-Sensitivity in Java?

David Barber asks: "I've just started learning Java, and to my exceptional disappointment it is as case-sensitive as C. I'd like to ask Slashdot readers to make the case for case-sensitivity in a programming language, because I can't see it. Although I've used C on and off since 1976, I also have a history of Fortran, COBOL, PL/I, assembler, and other legacy languages that were never case sensitive (perhaps due to the single case nature of card punches). Today I use modern languages including Visual Basic which preserves case for pleasing appearance, but is not case-sensitive itself (it will correct the case for you in the IDE, which is quite nice). In all my years of programming I have never seen the rationale for making a programming language case sensitive. It simply makes typing it in harder, and mistakes easier, yet we persevere with maintaining it in modern languages like Java. Without making this into a religious war, can someone make the argument of why case-sensitivity in a language is 'a good thing'? And don't confuse this with handling case-sensitive data, which is fine."

Comments

my reasons.......

[Anonymous Coward]

Here are some reasons I just made up (though a couple actually affected my programming).

Because it makes sense that all symbols are uniquely identified from a set of characters, rather than each symbol being identified by a huge set of names (var, vaR, vAr, vAR, etc). There may be a need for a "canonical name", which is it? All lowercase? All uppercase?

Because it makes dynamic programming and reflection even slower and/or more error-prone (I have experienced this in PHP which is case-insensitive and it bugged the hell out of me [and my program]).

Because it takes fewer CPU cycles when compiling or scanning source code.

Because some languages use case to indicate a different class of variable (Ruby for instance, issues a warning if you try and change a variable starting with uppercase).

Because many programmer's text editors are case-sensitive (I know, I know, chicken, egg, etc).

Because lowercase/uppercase could be a harder problem if you use a language which allows Unicode symbols (Perl6?). (Is this possible? I have no idea).

Because sometimes it actually is useful to have a symbol "ID" and another one "id" in the same symbol table.

Because stuff like case and english language is not part of programming, programming is about precision and computers. Introducing ambiguity (whether for the compiler or the programmer) can't be good.

Because C is case-sensitive, and C is a popular language.

You might want to try PHP5 though, it's a lot like Java but case-insensitive.

Re:my reasons.......

[smcv]

Case sensitivity is way more ambiguous by allowing
bar and Bar to be different variables whereas in English a bar and a Bar are no different.

That's not ambiguity. Ambiguity is saying one thing which could mean several things; according to your assertion, case-sensitive languages have more than one way (Bar vs bar) to say the same thing.

English isn't case-insensitive, anyway. When you encounter a capital letter, it's telling you something (that it's the beginning of a sentence, or part of a title, or a proper noun, ...).

Because lowercase/uppercase could be a harder problem if you use a language which allows Unicode symbols (Perl6?). (Is this possible? I have no idea).

There is no difference, basically. And Java supports uppercase functions for unicode in any case...

There is a huge difference. In the "basic" Roman alphabet (with no accents or anything, as implemented in ASCII) there is a 1-to-1 mapping between upper and lower case; this isn't always true in general.

For instance, in German there is the "s-set" (which looks a lot like a lower-case beta), which is more or less interchangeable with the character pair "ss". It upper-cases to "SS" (i.e. there is no capital s-set). With that in mind, in a case insensitive Unicode-based language, how many of strasse, stra(s-set)e, STRASSE should be equivalent?

Once you've finished hard-coding your case comparison rules, what other equivalences are allowed? Is a-acute ("a" with an acute accent, which Slashcode doesn't seem to want to let me post) the same as "a", bearing in mind that both are conventionally upper-cased to A in French, and is the correct answer "if and only if the programmer is French"?

Being case-sensitive also lets you compare raw byte sequences rather than canonicalising everything, which is no big deal in ASCII (just AND all letters with 0x20) but is intricate and fiddly in Unicode (hence lots of code and memory for all the esoteric rules required).

On a related note, I think filesystems should also be case-sensitive (like Unix, and unlike Windows and usually Mac OS X); if you want a helpful "ignore small differences" algorithm, it should happen at the user interface level, and it should be possible to override it, like the way you can put double quotes round a non-.txt filename in Notepad to prevent it from appending ".txt".

Being able to have "Letter.doc" and "letter.doc" in the same directory seems to me to be no more confusing than being able to have "Letter (21 Jan).doc" and "Letter [21 Jan].doc", or even "a_b", and "a__b" (for greater confusion, replace the underscores with spaces, but that wouldn't display properly in Slashcode). It's inconsistent to be sensitive to one small variation, but ignore another, particularly when the main principle of working with computers is "say exactly what you mean".

(I dislike extension hiding for the same reason; "you can't have two files with the same name, except when they're different types of file"? What sort of a silly rule is that?)

Java

[GuyWithLag]

Take a look at eclipse. Not only is it a subperb IDE that you can pick up within the hour, it has the correct-my-case-for-me feature you asked for.

Note that in Java case has by convention semantic significance, so that you can discern org.foo.Bar.bleh from org.foo.bar.Bleh.

readability

[retards]

In my opinion, case senssitivity allows for more readable code if using long variable or method names .

For instance:

MySteadfastObject.doSomeReallyBizarreParsing()

instead of

mYSTEadfasoBJEct.DOSomerEAllybizaReparsiNG()

Emphasizing readability instead of easy-writing is (mostly) a Good Thing (TM).

Java can also correct this with an editor!

[BoxedFlame]

I strongly recommend you look at IntelliJ's IDEA editor for java. It will do the case fix if you make a mistake.

Personally I prefer case sensitivity iN ALL LanGUagEs, inCludDinG jAVa bUT AlSo IN eNGlish.

Re:An argument for case-sensitivity

[Bluetrust25]

There was a great post on this subject on comp.lang.c back in 1989 by an academic named Rahul Dhesi:

Why languages should be case-sensitive:

People may use |COUNT| and |count| to mean the same thing, but mathematicians don't. In mathematical expressions it's very useful to use case distinctions for related entities. For example,

Consider a graph G(V,E)

for each vertex v in V do
find an edge e in E such that e is incident on v ...

Since programming languages are meant for use by technical people, and since computer programming and mathematics are so intimately related, it pays to let computer programmers use the same tools that mathematicians do. Not only should programming languages be case-sensitive, but they should allow the use of subscripts, superscripts, and Greek letters too, to make the notation more powerful and more intuitive. Right now we have to go through some trouble to compact mathematical notation to a verbose format just because the computer's character set is so inadequate.

Link to the original post

...And that's why you should sign up for free hosting with aloofhosting.com.

Mistakes easier?

[profet]

It simply makes typing it in harder, and mistakes easier

easier??? If anything it makes mistakes harder. Java is a very strict language syntax wise and will probably error out on compile if you have a syntax error.

Now lets think...what would happen if it didn't error out because of case sensitive erors? Wouldn't that make it "easier" to make mistakes?

SetSlower != SetsLower

[Tune]

- SetSlower is a procedure that reduces the speed
- SetsLower is a function that gets a lower bound in a set of sets

These are completely unrelated identifiers which are rendered equivalent by BASIC and other case-insensitive languages. It may look like a stupid example, but I've been annoyed on several occasions by misinterpreations of VB code that were caused by case-insensitivity. As a C/C++/Prolog/Haskell/Modula/... -coder I'm probably biased toward liking case-sensitivity, but I can't see why liking case-insensitivity should be objectively better; be more than just a bias.

--
What is wanted is not the will to believe, but the will to find out, which is the exact opposite -- Bertrand Russell, "Skeptical Essays", 1928

Therefore, lets leave this issue as it is until someone comes up with good arguments to choose either one or the other.

Conformance

[cookd]

I think the biggest reason is style enforcement. The reasoning goes something like this:

1. Case distinction is room for additional information without increasing the length of the text.
2. For the additional information to actually be useful, people have to know what the case distinctions mean.
3. For people to know what the case distinctions mean, there have to be established conventions.
4. Conventions fall apart very quickly if there is no enforcement or verification.
5. It is useful to make the compiler perform some of the verification and/or enforcement -- you're much more likely to notice problems immediately if the problem is caught by the compiler rather than an optional LINT tool.

It is a lot like case sensitivity for English. It really isn't needed, but it sure helps you understand things a lot more easily. You can scan for the start of the next sentence much more quickly if the sentence starts with an uppercase letter and the rest are lowercase. In the same way, you can get a quick sense of what a variable is for by observing its casing, assuming that you are familiar with the casing convention in use.

English teachers force us to use proper spelling, grammar, casing, and punctuation so we can communicate more clearly. Computer language syntax works the same way. The parser/compiler could do a fine job with a much simpler language, and it doesn't really need to be that strict about syntax checking. ("Error: missing semicolon." If it knows there is a missing semicolon, why can't it just pretend the semicolon is there and go on?) The idea is that stricter syntax checking is useful to the original programmer (many syntax errors are also indicative of logic errors or ambiguity) and also to the maintainer who has to make sense out of the code.

So the bottom line is that following coding conventions makes your code more readable and your intent more clear. Case sensitivity is one way the compiler helps you maintain your coding conventions.

C does not assume ASCII machine platforms

[FriendlySolipsist]

C is carefully designed so that it does not assume that the underlying platform on which it runs is natively using ASCII. A number of relatively obscure features, especially trigraphs, were put into the language specifically to make this work.

While case-folding is fairly easy in ASCII because upper and lower case letters are exactly one bit distant, it would substantially complicate compilation on other platforms. It is relatively unnatural for the computer to allow case-insensitivity, even in ASCII, and in machines that natively use something other than ASCII it can be quite tedious.

Having dealt with C implementations that are targeted for machines which are radically different from what most people are used to using, I have a lot of respect for the portability of C. For example, I once worked with a C implementation on an IBM mainframe processor that had no stack, so the C stack had to be synthesized using machine registers and memory conventions, but this worked!

C was designed to be small AND portable. Java was designed to be, well, portable. No matter how careful you try to be, dropping case-sensitivity from the language would lead to nightmares when trying to achieve portability.

More one-letter Variables!

[Ba3r]

With Case Sensitivity, I can have 52 one letter variables, not 26!

Re:History

[Mr. Slippery]

You can still capitalize your static variables if you like...If you spell a variable "thisIsImportant" in hundreds of places throughout your source code, but in one place spell it "ThisIsImportant" a case sensitive language like Java will consider those two DIFFERENT variables.

It won't be considered a different variable, it will be considered an undeclared variable. The compliler will choke on it.

As it should. If people use case convertions to convey information - static variables are capitalized - then the compiler enforcing consistent casing is good. Else in file1.c it's "ThisIsStatic", in file2.c it's "thisisstatic"; Alice, looking a file1.c, knows it's static, while Bob, looking at file2.c, doesn't get that same information. The compiler is merely making you pick a way and stick to it, for the benefit of your fellow humans.

Should the compilier also ignore misspellings? If "Variable1" appears all over the place and in one place "Variabl1" appears, should the complier auto-correct it to "Variable1"?

Re:History

[msuzio]

I couldn't disagree more. If I read DeviceEntity.java, and it says:

getDeviceName(customerId)

I for damn sure don't want to search for the same thing in DeviceServlet.java and be frustrated because it says:

GETDeviceNAME

ugh. At the most basic level, this is dumb. If I mistyped the name with incorrect capitalization, it *won't compile*! This is not a subtle error, it would be obvious! So it does not at all lead to errors.

Case sensitivity means I know a variable, method, whatever, is always going to "look" the same to me when I'm scanning the code or when I type a quick search into vi (/getDeviceName). I don't need my new intern who likes a different set of notation littering my code with GetDeviceName because the compiler lets him get away with it :-).

I'll agree with you that having both ThisIsImportant and thisisimportant in a module and relying on case-insensitivity to differentiate is probably not a good idea, though...