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

[KDan]

Additional reasons:

Because it makes naming conventions much easier without all sorts of silly prefixes. You'll come to appreciate the fact that, in Java, if a term looks like MyTerm you know it's a class name, if it looks like myTerm you know it's a variable or a method name (recognisable because it's followed by brackets, even when there are no arguments - something which I'm sure you'll be griping about too, right?), if it looks like MY_TERM you know it's a constant...

Because good programmers aren't bothered by such trifling matters?

Daniel

Re:my reasons.......

[Pogue Mahone]

Many natural languages have case-sensitivity too - German, for example: fliegen (verb) and Fliegen (noun) are different words.

But why a big list of reasons FOR case-insensitivity?

IMHO the question should be turned around to "Why should anyone want case-insensitivity in a language?" (since, as you say, it has to be put there and requires more work in the part of the compiler and/or the compiler writer).

Then it is up to those who want case-insensitivity to argue their case against the simplest implementation.

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

CasESEnsivity iS gOod.

[noselasd]

When I make a class Person {..} I want the other developers to use
Person person = new Person(..); not
person person = new perSon();

It also becomes a mess when you have some people write
If(something){
}
later you see IF or if.
Case sensivity preserves sanity and helps enforce coding standard.
It's a good thing, learn to deal with it.

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

Re:An argument for case-sensitivity

[dubl-u]

With DP case sensitvity just gets in the way - the programmers may not be very technical and any maths used would probably only be complicated by use of the 'same' name for different variables. [...] As Java is often marketed as a DP language it's case-sensetivity is a serious drawback (at least as far as DP is concerned - in other areas of Java's use it may be usefull).

I think a better distinction is between scripting languages and programming languages. Scripting languages are meant for short bits of coding by non-experts. Programming languages are meant for large bases of code built by professionals.

It's a continuum, of course; no language is used for only one of those. But Java is clearly intended to be pretty far towards the professional end of the spectrum. Non-experts working on small projects should pick a language better suited to their needs; Java will seem to them to be balky and annoying.

And as an aside: non-experts should stick to small projects. I think the huge danger with scripting languages (in which category I'd include things like pre-dot-net VB) is that although they are great getting non-programmers into doing a little programming, they let people get away with a lot of stuff that is dangerous on larger scales.

It's as if a guy who successfully changed a lightswitch in his house grabbed his trusty screwdriver and tried to tackle wiring a 500-rack server facility. He might get some stuff working, but it would be flaky, dangerous, and impossible to maintain. Just like so many code bases I've seen put together by "not very technical" programmers.

Re:OMG

[lscoughlin]

You're snobbish hatred of a language that's really Not That Bad is indcative of the fact that you are not "A Real Programmer".

Some very powerful things have been done with visual basic, and the true test of a "Real Programmer" is doing those Powerful Things on time, underbudget, and in Good Working Condition regardless of the environment of choice for the application.

Notice my hideous but Meaning Laden usage of capitalization. While i don't believe that a capitalization scheme should be enforced by the compiler, i do appreciate having it as a tool to enforce coding standard schemes.

Smurfy,
-T