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?)

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).

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.

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.

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...