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.

Re:Mistakes easier?

[LizardKing]

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?

This set me thinking. The guy who posted the article would probably prefer Perl to Java. It is case sensitive, but will let him get away with his sloppy coding practices by simply creating a new variable every time it encounters one which only differentiates from another in case. Then once he's learnt the error of his ways, he'll either return to Java with a greater appreciation of it's reasonably strict syntax, or become a fan of "use strict;" ...

I remember reading the Jargon File entry on "discipline and bondage" programming languages, which was quite disparaging about them. I found myself in wholehearted disagreement with that attitude, as most programmers I work with need to have discipline imposed on them - coding standards, style checkers and peer review help, but the quality of C code seems to generally better than Perl or C++ simply because the language is much smaller and narrowly defined.

Chris

Easier to read

[jgoemat]

Most languages have guidelines to show you how to capitalize identifiers. It is much easier for me to read code that way than if anyone could capitalize differently than the libraries were defined.

Being case-sensitive AND following capitalization guidelines makes code much easier to read. I don't see any reason to allow the same characters with different capitalization to refer to different variables, but I definitely think any references to a variable or function should be capitalized the same way it is defined and that all keywords should be capitalized consistently.

Re:An argument for case-sensitivity

[TobascoKid]

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

I only partly agree with this statement as I think there are two distinct types of programming - the technical, mathematical type and a far less mathmatical 'data processing' (ie pretty forms for putting data in databases) type of programming.

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.

I think VB is definately in the DP category of languages and hence has no need for case sensitivity. 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).

Tk

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.

Learn another (natural) language and you'll know

[lokedhs]

In english, the concept of upper and lower case is quite simple. Every uppercase letter has a lower case version, and this rule is true the other way around.

Speakers of other languages are not quite as fortunate. I'll try to explain, but the horrible lack of Unicode slashdot coupled with the extremely stupid character filter will make this slightly more difficult than it should be.

German, for example, has a letter which is basically a "double s". This letter only has a lower case form, in upper case, this letter becomes "SS". However, "SS" in lower case becomes "ss", not "double s".

French has a character which is a lower case "e" with two dots above. The upper case form of this letter is the normal "E" in france, but in french canada this letter becomes an upper case "E" with two dots.

There are other languages which has characters that only exist in upper case or lower case forms.

Do you realise just how complex the casing rules becomes when you have to take these things into consideration? Keep in mind that Java supports all unicode characters in symbols.

The exact same argument can be used when explaining why the oeprating system kernel shouuld not have case-insignificant file names. This is a localisation issue and neither your java compiler nor the operating system kernel should have to worry about what locale you have in order to determine how a certain string of characters should be interpreted. (yes, encoding issues always creeps in, but that's on a different level).

Just think about it. Your program compiles properly if you select "french france" when you log in, but fails when you use "french canada".

Don't you think it's easier just to specify that symbols are case significant?

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

Re:History

[JGski]

This sounds too much like the old DOS complaint about the Unix filesystem being case sensitive. Being case-INsensitive would be a far greater flaw.

For heaven's sake, if you mispelled on case in a program, 99% of the time you'll pick it up in the first compile - problem solved!! Sounds like poor programming discipline and laziness more than anything else.

Re:Uniformity...

[mystran]

I am a programmer, and I can tell that case-sensitivity has other benefits too.

• You don't need to care about the LOCALE settings or other such things. Either something is the same as something else, or it is not. You don't need to care if the compiler actually accepts the source with the right character set.
• In some cases, it is very useful to be able to use the same identifier in several different cases. One example is having a class "Foobar", an instance of which you can name "foobar", and it's clear what class it belongs, but you still have a separate identifier.
• This is not directly related to Java, but sometimes you want to have a short identifier for something that's used a lot. Say, you have a global object which talks to an Xserver. If you need to use that in many places, it's nice to name it "X" which is easy to understand, but "x" is a common variable name for short-lived variables, and you don't want it to be the same identifier as "X". Without case-sensitivity, you can't really use one letter globals, because one letter variables are the ones people will be using the most. With case-sensitivy, you can use just the uppercase for globals, and there's no problem. (whether globals are a good idea at all is another subject, and depends on the language and type of program one is writing in/for)

Case-insensitivity is probably the single most annoying thing with otherwise decent languages such as Scheme. In case-sensitive languages, errors in casing are usually catched by a compiler. With case-insensitive languages it's easy to make errors that are not catched, because the different looking identifiers are actually the same.

My .02 euros. YMMV.