Slashdot Mirror
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."
..and I agree. It is a major annoyance for me, as well.
A blog like any other.
I'm not a programmer, but I would imagine that case-sensitivity would help a great deal with the uniformity of the code.
Case sensitivity is just a tradition, with its roots in the Old Testiment.
He who knows not and knows he knows not is a wise man. He who knows not and knows not he knows not is a fool.
It's nice that VB corrects your code in its proprietary IDE, but C/++/Java is used in many different editors/IDEs. The language thus enforces clean code case-wise by being case sensitive.
Browse Slashdot at Funny+5, everything else -5. The only way to sustain it.
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.
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.
One advantage of case-sensitivity of variable names and the like is that it allows ad hoc separations of name spaces.
For example, it is a common practice in C to use ALLCAPS for macro definitions and alllowercase for variable and function names. If adhered to strictly, it means that there won't be any collisions between variable and macro names.
It can be convenient in maths heavy code too, where the use of long variable names quickly makes the code hard to read due to excessive line lengths. Being able to use short upper case names for 'big' objects (eg matrices or operators) and short lower case names for 'small' objects such as scalars matches mathematical convention and keeps equations short and readable. Case sensitivity means that there won't be any accidental collisions between the two sets of objects.
It's certainly not necessary, but it can make life a lot easier. If you don't expect your language to ignore case, then you're unlikely to make case-based errors as a programmer. Especially if you're coming from a mathematical background where 'A' and 'a' rarely refer to the same thing.
I think case sensitivity is rubbish too.
How many times have I seen some stupid error message...
upper.cpp:2391: error: `casesensitive' undeclared (first use this function)
argh! then I search for minutes on end for that one stupid not capitalized letter.
i'm all for non-case-sensitizing things.
WTPOUAWYHTTOTWPA
What's the point of using acronyms when you have to type out the whole phrase anyways?
Today I use modern languages including Visual Basic
Real programmers don't use (Visual) BASIC... at least not after puberty ! ;-)
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.
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).
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.
Link to the original post
...And that's why you should sign up for free hosting with aloofhosting.com.
Sure case sensitivy does make VariablesEasierToRead, but don't most programmers do that anyway? When was the last time you saw a stuPiDLYcapITAliZeDVariAbLe? It should be up to the programmer to choose his own naming conventions, including the capitalization, instead of assuming they doesn't know how.
Having had the pleasure of maintaining some Fortran code that was decidedly haphazard when it came to case consistency, all I can say is thank God C and Java are case-sensitive. The only reason languages like Fortran are case-insensitive is because punch cards and many early terminals only had uppercase characters. This enforced a consistency in case, but once terminals with full character sets became common I'm sure legibility of code became an issue.
Relying on an IDE to correct your sloppy coding by enforcing case consistency is a dubious idea. An IDE can have many positive features - syntax highlighting of errors, automatic indenting - but it shouldn't automatically "fix" errors. Sooner or later the IDE will make the wrong decision about how to fix a programmers syntax error, leading to potentially subtle and hard to find bugs.
Chris
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 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.
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.
Time flies like an arrow. Fruit flies like a banana.
This is actually a problem with java because Java states that thos packages must be in the correct directories:
org.foo.Bar.bleh must be in org/foo/Bar
org.foo.bar.Bleh must be in org/foo/bar
This is NOT possible (unless they are in different section of the classpath) in Windows NT because the filesystem is not case-sensitive there. Java's mapping of case-sensitive package names to an underlying filesystem assumes that the filesystem has the same naming conventions that Java uses.
As far as I know Java can also take Unicode source as input and then the filesystem must also handle that, which would work on NTFS, but not of FAT and probably not on any Unix FS AFAIK.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Well, if you prefer hacking non-case-sensitive code, just don't leave your Visual Basic and Windows playground and let adult programmers with a mathematical background work as they did since the computer was invented. If you really want a non-case-sensitive Java, just grab some free, open source Java implementation and modify it to be case insensitive. No one will stop you. But you do remember that Java source code is assumed to be Unicode, do you? And you remember that some Unicode characters are considered to be either upper or lower case, but have not exactly one corresponding lower resp. upper case character, do you? One simple example is the German sz ligature, but there are many more. In France, it is custom to leave out the accent signs on upper case letters, so toLower(toUpper(s)) is not equal to s.
Tux2000
Denken hilft.
I understand that the rules of the Java game
;-)
are no longer in Sun's hands to control...
There's some sort of community-input standards
committee or working group to which you (or
any/all of us here, even) can put the Suggestion
that Java become case-insensitive.
In fact, why don't we organise a -mass- sugges-
tion campaign here to do just that.
A bit like those spontaneous "Let's all meet
at Macca's on 5th & Spring St (or wherever)"
that turn out crowds of people, who've never
even met before... on somebody's whim...
org.foo.Bar.bleh is the static variable named blex of the class Bar in the org.foo package, contained in the org/foo/Bar.java file.
org.foo.bar.Bleh is the class Bleh in the org.foo.bar package, contained in the org/foo/bar/Bleh.java file.
As you see, these are quite different, and in different places. But still, if a coder uses Foobar and FooBar as class names, yes, he will be in trouble in case-insensitive filesystems. As for the source issue you mention, it is really two issues:
- The encoding of the source files
- The encoding of the file names
For the first I know that it uses the environments encoding IIRC on Unix by LANG or the locale.For the second, well, It seems to work just fine on a UTF-8 Linux environment with greek class names, but I don't know anything about Windows other than VFAT with long file names uses unicode.
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.
Another point: case sensitivty improves code readability by removing ambiguity. For example, the java practice of namingMethodsAndVariablesInCamelCase, starting with a lowercase letter and TheSameWithAnUppercaseStartLetter for classes allows a variable to have the same name as a class, which i often use in code like this:The case-sensitivity of java, combined with coding standards, enables me to do this. Obviously, something could also be named mySomething, but i find it much simpler and cleaner this way.
And finally, the slippery slope argument: If we allow incorrect capitalization in code, what next? A compiler with automagic spellchecking and -correction?
As Charlton Heston would put it: From my cold, case sensitive hands!
Free as in mason.
I believe that the wish for case insensitivity is a cultural thing, mainly craved for by those for whom english is the native language.
In more than a few other (human) languages (yes there are others beside english) case conveyes difference in meaning, generally reducing redundancy and often ambiguity when compared to english. Now, those are aspects that should appeal to hackers.
Also it probably is a windows centric idea to expect things to be case insensitive (or as the original poster pointed out have older roots in primitivity)
Why would you reduce your name space by 50%?
mfg lutz
if you look at the languages from whence java sprang, you'll see that while a lot of the semantics came from lisp (not case sensitive, easy to get lost in a sea of parentheses), the syntax is almost entirely based on that of C/C++/Object C (fewer parentheses, case sensitive). people coming from those languages (and there are a lot of them) are used to having case sensitivity and are likely to start bitching long and loud if you ever take it away from them.
Quick guess:
We need case sensitivity because the English language has two cases.
I mean 'R' and 'r' don't look the same do they?
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
At some point, somewhere, the entire internet will be found to be illegal.
they should allow the use of subscripts, superscripts, and Greek letters too, to make the notation more powerful and more intuitive.
I think this should be handled on the editor side rather than in the language. For example, you'd still name a variable sigma_1 but the editor would display it as a sigma character with subscript index 1. This has a great benefit: it maintains compatibility. People can work on the code even if they only have access to a regular text editor, and it'll be encoding-safe.
It'd require strict naming conventions, of course, but people should use strict naming anyway.
I also note that you realize English is case sensitive. You didn't have your all caps key on. Why are you not complaining about that?
Like many posters have already said, taking case out of the equation takes out a bit of information that can be put to very good use in the language semantics (e.g. "All class names start with a capital letter", "static final constants are all caps", etc...)
I think part of the problem with the question is that when people say "case insensitive" they're probably thinking to themselves, "all caps". Which would certainly cut down on some of the readability and consistency issues mentioned. The problem is that the two are not the same, and if you really do mean case insensitive you have to put up with things like pUblIc STatiC final INT FOo=0; That pains me just to write it.
www.HearMySoulSpeak.com
Right on! Let's get rid of case sensitivity!
:)
While we're at it, let's banish that pesky "pitch sensitivity" from the Chinese language. It would be SO much easier to speak if it didn't matter how you inflect the words. I'm tired of trying to compliment someone only to have them get all indignant because I told them their mother was a horse.
Where most Nouns are Capitalized by Everone. It is a good Thing. I always liked being able to find Nouns easily in a sentence.
Verbs at the end is confusing though. You no Idea Phrase what about is, until Pile of Verbs at the end get to. It Holistic Sentence parsing make is.
Up till now every answer I've seen is either a) Because it's a tradtion, b) Because it's english, c) Because in Mathematics, we distinguish, or, simply, d) Because it's just better.
.5 was much faster than dividing by 2? Some of these still exist...), so I would consider myself a moron to quasi copy'n'paste without thorough rewrite anyway... d) Has never been an acceptable answer. So, what we have up to this point and in my opinion, is a number of prime examples for zealotism an flame-baits...
With the possible exception of c) these are rubbish. a) Even if it were traditional (which it isn't, as some pointed out -> punch cards), since when do geeks care about old stuff??? A little nostalgia, but die-hard conservatism (in the sense of "to conserve")? b) Yeah, right, "MyObject.GetNumberOfReferences" sure is proper english capitalization... c) If I want to enter a mathematical expression directly as source, then this is a valid point. Notice the "if" however. There are usually some rather dirty hacks you can apply for speed anyway (remember back when multiplying by
OK, now for my POV: I started my programming at around 10 with M$-DOS Batch and QBasic, which I both consider very helpful tools today. Most Windows(TM) PC's I encounter still have QBasic installed and when I need to write a "script" fast on those, knowing these is saving me time I would otherwise spend installing a "real" compiler (So NO Basic-bashing please, it is very helpful and, in it's newer instances reoatively powerful. You have realized that even before "Visual" it was capable of functions, pointers, direct IRQ-addressing, including Assembler, etc.?). Later I learned C,Pascal,Java,Haskell,Prolog,C++, though some only superficially, because I needed those for university. As soon as my "Pascal"-Phase (during school, when my teacher knew nothing but that) I understood one thing: Some languages make writing them appear harder. Semicolons at every lineend, Case-sensitivity, etc. All stuff that the IDE, or even a sophisticated editor, could easily handle themselves, if the the compiler was build for that (So no "the semicolon is given instead of a CR/LF or CR, because of portability, etc."-argument. That is an argument for the _saved_ file, or, even more precise, for the one handed to the compiler...) I was willing to cope with those during C, because the raw power of it made it worth any unpleasancy during writing, but with Pascal it ended being just anoying and a PITA. Java was a final example of artifical stupidity, in my eyes. I understand that it's capitalization rules lead to better readability of the code (which could still be done via IDE-Correction. If a language has commands that only differ in one capitalization, as suggested before, but those command still have 30+ characters, then something is seriously wrong...), but the sheer length of most commands and names in Java is always an eyesore to me. Yes, I know we don't have memory limitations anymore, but I still prefer abbreviations. What's wrong with VARPTR? Is VariablePointer really better? Or is it merely more characters to write? Spoken languages are highly redundant, which is necessary to understand disturbed communication, but when writing code, that is _not_ any issue. Why should I prefer a language that makes me wish for auto-completion of its mile-long commands???
I hope that my post gives the scale a nudge in the other direction...
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 apart, 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.
But you do remember that Java source code is assumed to be Unicode, do you?
That would be the killer argument, if you could use all those Unicode characters in identifiers. But you can't, identifiers can only use characters from the ASCII subset. Since this discussion is about identifiers, this point is moot.
Source: http://java.sun.com/docs/books/jls/second_edition/ html/lexical.doc.html.
I believe posters are recognized by their sig. So I made one.
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.
int stuff;
int Stuff;
int StUfF;
(Man, it must be early for me to think that's funny.)
"I'll say it again for the logic-impaired." -- Larry Wall.
Most, if not all, of the arguments that I've seen so far against case insensitivity have relied on a lack of case preservation as well. The two aren't tied together.
Would the arguments against case sensitivity still apply if case was preserved? This would allow you to still name 'constants' in ALL_CAPS, have classnames start with a capital letter, and variable, package and method names start with a lowercase letter and have interCaps.
it will make you think twice before entering your code. It is odd having case insensetiveness rather than the opposite. Otherwise we could also be insensetive to 0 (zero) and O (upper case o) as well as l (lower case L) and 1 (one) etc.
IDE:s that correct your errors will become your addiction and soon you and up not beeing able to perform without them. Some people even think that compilers should cover your ass entering poor code by optimizing away redudant tests and dead code and turn your loops upside down. You'll be surprised when you try to port the code to a compiler lacking these 'features'.
Also learning to use correct naming conventions, indentions and language specific programming style will make everyone else so much more happy!
hardcore programmers often like to do things in the difficult way in order to separate themselves from plebe-programmers.
One way they do this is by using case sensitive languages. By showing others how proficient they are at telling apart a dozen variables based on different casing of the word 'inumfxsk', they both earn praise from other hardcore programmers and confuse the aformentioned plebes.
there is another advantage of using case sensitive programming languages. With the rise of RADs and faster CPUs, plebes are churning out programs and updating them in the same time that it takes a hardcore programmer to display their main window using assembly code. When asked by their boss is why they take 10 times as long to do anything in their language, they can point out the advantages of using their case sensitive programming language and being able to create a dozen variables based on different casing of the word 'inumfxsk'. This is definitely preferable to being forced to spend the five hours it takes to learn one of those decidedly uncool RAD languages. I mean, what if your other hardcore programmer friends find out?
i AgrEE. hElL, whY DoES eNGlIsH hAvE tO Be cASe sEnsItiVe? dOeS iT ReAlLy mAttEr?
> Without making this into a religious war, can someone make the argument
/home).)
> of why case-sensitivity in a language is 'a good thing'?
If you look up "holy war" online and skip over anything having to do with
real-world non-computer-geek religions, you'll find the following classic
examples of holy war materiel: Emacs vs vi, big-endian vs little-endian,
*nix vs non-*nix, CISC vs RISC, and case-sensitive vs case-insensitive.
In short, it's highly a matter of taste. Some people even like to have
case-sensitivity in their filesystems. (Personally, I dislike that and
think that should be optionally possible to turn it off in certain
directory trees (particularly,
Personally, I don't mind case-sensitivity in a language, generally. Perl
is very much case-sensitive, as is elisp, and neither has ever troubled me.
The only time case-sensitivity in a language has really bothered me is in
Inform -- but that was because of the incompatible _changes_ in the case
sensitivity from Inform5 to Inform6, which caused a lot of my code to break.
Now, that said, it is also possible for a language which is case-sensitive
to go far wrong in its use of case by being inconsistent in a way that will
leave you unsure which case is correct sometimes. For example, if a lot of
the ready-made modules/libraries/whatever that you use are not consistent
with one another in their use of case, that would be very bad. In elisp and
Perl, I have not generally found that to be the case. I can't speak for
Java; my attempts to learn Java have largely ended with "Ew, it's like C++".
Cut that out, or I will ship you to Norilsk in a box.
I agree that clearer names are always an advantage -- in general. What "clearer" means remains a question. First, mapping two completely unrelated identifiers to the same function doesn't always generate a compiler warning. Just think of overloading, which you would have to consider similarly dangerous.
Second, it may not occur to you that SetSlower & SetsLower are similar because they have completely unrelated meanings. With case-insensitivity you always need to be aware that you identifier might mean something different given a different morphological decomposition of that identifier.
Meaningfull identifier should be able to express as much meaning as possible. Thus, the form of an identifier should not be a goal in itself, but rather an expression of meaning. And ambiguity simply does not help.
--
Is a computer language with goto's totally Wirth-less?
1. History -- Argument: Lots of languages are case sensitive, and people seem to be capable of dealing with it, so this is a non-issue. Response: The problem is, of course, that this response completely avoids making a point relevant to the argument.
2a. Readability -- Argument: Forcing people to type "if" instead of "IF", "If" or god forbid, "iF" will enhance readability. Response: I personally feel that all-lowercase individual words are a lot easier to read than leading capitals or all-uppercase, but this is only a solution for the predefined keywords of a language, and really fails to address the question of case *sensitivity* to case in programmer-defined names.
2b. Readability -- Argument: If I define myCleverMethod, I don't want to debug code littered with MYcleVERMetHOD. Response: Somebody inevitably posts some variation on this, and I can't imagine why they bother. What kind of idiot would bother with such screwy capitalization?
3. Flexibility -- Argument: Case sensitivity allows you to use the same multi-word phrase for two unrelated things when they both happen to require the same spelling. Response: I actually had somebody use the examples CarPass and CarpAss to illustrate the flexibility of case sensitivity (on the pre-release C# mailing list at Don Box's develop.com). To date I have not seen an example of this which is even remotely defensible. Elsewhere in this /. discussion someone posted SetsLow and SetSlow, which sounds slightly more realistic, but it's still reaching. Somebody show me one where the "obvious" names are significantly better than simply choosing an alternative.
4a. Parsing -- Argument: The main reason case sensitivity exists is because uppercase and lowercase letters really are different things to a computer. Response: This mattered a lot in the old days of computing (which also yielded the terseness we see in languages like C). The machine on my desktop has a 3GHz CPU and 1GB of RAM. It can compile tens of thousands of lines of code in a matter of seconds. Although it can probably be argued that non-ASCII platforms would have a harder time performing this conversion, I'd also point out that databases and other applications in those same environments perform case conversions quite easily on those same platforms. I do not consider this a valid argument.
4b. Parsing -- Response: The standard parsing argument could be extended in equally ridiculous directions. With the considerable power of modern desktop computers, we can do all sorts of things with text. Why not treat red, blue, and boldface text as separate characters, too?
5. Mathematics -- Argument: Mathematicians regularly represent different variables and other elements which are differentiated only by notational case. Response: Due to the incredibly tiny fraction of programmers who are also mathematicians writing mathematical code, I believe this argument is irrelevant. It's probably one of the more interesting arguments, but frankly it's always annoyed me in mathematics, too. :)
6. Constants and Classes -- Argument: Traditionally, many languages define constants using names which are all-uppercase, and more recently classes are often defined using names which are captialized. Response: This one always annoys me. Usually the same person is saying that the capitalization differences assist in the readability of the code moments after they've made the argument that capitalization should be inflexible for the sake of readability! There is nothing about case-insensitivity which would prevent this practice. I do it myself when I use case-insensitive languages. What it would prevent is using the same WORD to mean two different things. If that isn't just begging to introduce readability errors, I can't imagine what is. Nothing about case-insensitivity prevents peopl
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005
And it is not just mathematics. you also have things like:
FILE* file;
It also cuts down on the collisions between constants and variables:
#DEFINE ANSWER 42
int answer = ANSWER;
And although I can't think of any examples right now it also cuts down on the collisions with keywords.
A major reason for case sensitivity is when naming classes and instances of classes.
A common convention in Java and PHP is to name classes beginning with a capital letter, but name instances of classes beginning with a lowercase letter.
For instance: FooBar is a class, but fooBar is an instance of a class. In general, conventions make code easier to read, and case sensitivity is required for this convention.
Another convention I like is stubblyCaps, although you don't strictly need case sensitivity for that one.
Of course, some conventions are just plain dumb - like that hungarian notation of Microsoft, where they prefix their variables by its type. I thought that was good for a while, but then I had to change a variable's type one day...damn.
Anyway, for my money, I like the precision of case sensitivity. And a good IDE makes it painless.
Compilers can be slightly faster if they don't have to take the time to match names with case inconsistencies.
Badass Resumes
The simplest two reasons I can think of for case sensitivity in a language is to maintain use of all available namespace (case insensitive cuts the namespace roughly in half), and it allows for more efficient compilers. IE, compilers don't have to treat two different characters the same, like "A" and "a", which have different intrinsic values.
The namespace issue would be the most important to me, though. Besides, What's the problem with typing case sensitively? You do so in "normal" communications all the time- what's so bad about continuing that habit in your coding? It makes the code easier to read, and if you stick to conventions, it makes understanding your code that much faster as a reader can differentiate an item based on it's capitalization. Personally, I hate reading code that's all caps...
The dry fish swims alone.
hAVe YOu eveR tRiED TO reAd a MIxeD cAsE DoCUMenT?
iT IS ReAL pAIN iN THe aSS.
cODE is dIFfiCUlT eNOugH tO rEAd wIThouT coMPLIcatINg tHiNGs fURthEr.
Conformity is the jailer of freedom and enemy of growth. -JFK
When implementing a language in itself (or one like it), you usually want to have classes, or datatypes, or arms in a union, named after features of that language. For instance, in Java you might have a class called 'If' that represents an if expression. Of course, you can't call it 'if' because that's a keyword. 'If', in my opinion, is a lot better than 'if_e' or whatever.
Some languages use initial capitals to distinguish lexical classes (like O'caml), and this is another reason to have case sensitivity.
I think that what you really hate is Java's difficult capitalization rules. I also find biCapitalization difficult because the rules are not as simple as they claim to be. Is it subString or substring? searchAST or searchAst?
I'm afraid you're guilty of using a (d)-style argument in your own rebuttal. Basically, you are saying that you like case insensitivity better, and that's it.
I don't like Java's mile-long member names either, but I don't think that has anything to do with case (in)sensitivity.
With Case Sensitivity, I can have 52 one letter variables, not 26!
Why is Visual BASIC trying to preserve the case-sensitivity? If you think as you said that it is only to please the eye, think again.
The BASIC language was to introduce people to programming and is a language that try to remove rules to allow faster results (faster != better all the time...).
If they preserve case it probably is because people requested it and if people requested it probably has something to do more the need to have consistency.
In english, why do we put name with a Capital in front? Or why to sentence required to be uppercase? Because case, like a letter create different pattern which may be easily recognized by the brain and treated in a different way.
I suppose there probably aren't any huge advantages to having variables be case sensitive. It does lead to mistakes. However, I would assume it does make compilation slightly faster as it wouldn't have to figure out that "var1" and "vAr2 are the same variable. I really doubt very few would ever do something like have variable aa and AA because that would just be bad programming. However, there are coding conventions (they vary from place to place) that generally take care of the problem of case sensitivity. Globals in all CAPS, variables of the form wordWordWord like tempMemPointer or whatnot. Following a convention will help because then you won't have to even think about whether or not a local variable is of the WORDWORD or wordWord.
Mea navis aericumbens anguillis abundat
there are plenty of reasons for and against case sensitivity in languages... so why not allow both?
just make up a compiler directive or something that indicates whether to de-case-ify your code.
Somewhere on this page I have hidden my signature.
... since lisp and it's relatives are often used in computer algebra systems, and lisp is case insensitive.
On the other hand, lisps allows all kinds of characters in identifiers, e.g eq? load-this-now are.we.there!yet? so we can still have fun.
xkcd is not in the sudoers file. This incident will be reported.
Write a 5 line script that will make a copy of your code in all lowercase and compile that instead. Or just type in all lowercase to begin with (ewwwww). Or get an editor that'll fix case for you (I saw at least 2 mentioned in this thread). Or just do a search-and-replace in your file to turn whatever variable errors into the case you want.
Me? I want a compiler that will make me toast on the first build of the day.
that Lisp is case sensitive. It's just that by default the reader upcases the characters in symbols when it reads them. One can either alter the readtable or quote symbols or characters in symbols as desired to avoid that.
"Well, if you prefer hacking non-case-sensitive code, just don't leave your Visual Basic and Windows playground and let adult programmers with a mathematical background work as they did since the computer was invented."
Hey wannabe oldtimer, heard of
Fortran? Lisp? Cobol? PL/1? Pascal? Prolog? Forth? Algol? Basic? Simula? Snobol? All are older than C, all are case insensitive. It was only those C punks who apparently were so impressed with their new mixed-case systems that they wanted it in their language.
(True, you may not want to program in all of these, but what has that got to do with it?)
xkcd is not in the sudoers file. This incident will be reported.
"When the literate German dives into a sentence, that is the last you will see of him until he emerges from the other side of the Atlantic with the verb in his teeth" - Oscar Wilde, I think.
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?
If I have a class or structure that defines constants, such as a set width or length for a parent object. Then I utilize this class/struct in another class which is creating a child object, also with length and width, but this time a user defined value, I can use "width" for the user value, and "WIDTH" for the constant value, without having to rewrite as much code in the new class. It also helps me, as the programmer, to help better identify my own code. "VALUE"? Oh, that is a constant, or struct. "Value"? Oh, that must be my function, or class name. "value"? Oh, that is a program defined variable.
;) ) which is case insensitive. Then I moved onto Java, C++, VB, and now C#. When I first learned Java, I initially hated the fact that it was case sensitive. However, once I learned how it made my life easier as a programmer, and my code more readable, I quickly fell in love with case sensitive languages. Now, I hate VB just for that fact (oh yeah, and it's lack of semicolon end lines, and funky for loop structures, and...oh who am I kidding, I just hate VB :) ), and I no longer code in Ada (for less personal reasons, like, no one really uses it much anymore).
I stated off with Ada '95 (ok, technically it was Logo, back in grade school in the early 80's, but I don't think that really counts
The only place I find case insensitivity worth while is in a quick and dirty script. However, even most scripting languages are case sensitive (Perl, JScript). Which leaves only vbscript and WSH (I think...I program case sensitive out of habit, now) as case insensitive scripts (of the ones I've used, anyway). But, again, in most programmers opinions (programmers that I know, anyway), they will all prefer Perl or JScript over VBScript due to their ability to be a little more robust, and ability for shorter scripts to acomplish a lot of work.
Obviously, if you are going to use ThIsAsAvArIaBlE name, you are just being stupid, and defeating the purpose. Making it less readable, less portable, more difficult to work with, and you less liked by your co-workers.
"Also it probably is a windows centric idea to expect things to be case insensitive"
Why is it that as soon as someone suggests something opposed to current "hacker" taste he is instantly derided as a windows l0ser?
ANY language I could find older than C is case insensitive. Didn't you hear the original poster talk about his __PL/I__ experience? And you deride him as a newbie? Get a grip!
xkcd is not in the sudoers file. This incident will be reported.
Case sensitivity is a relic of the long gone day when calling upper() was considered an extravagance by the designers of C. Being a low level language, many of the functions of the original AT&T version of C were as stupid as possible while still achieving the goals. Null termination of strings, (actually the entire string function set), and bare pointer arithmetic are other examples. It was considered "super assembly for OS writing".
Being such a bare bones, close to the metal language, case sensitivity made sense. However, since C was case sensitive, this sensitivity was used to partition CONSTANTS from variables and functions. Later in C++ we see Methods (initial cap) vs variableName (initial lower) became standard.
Many later languages modeled at least partially upon C, so it isn't surprising that they retained that sensitivity. However, at this point is is absurd: if we really want to differentiate object types, color, size and font and other options are available in a modern editor. However, if we really-really want case sensitive Methods, variables and CONSTANTS, why not have the editor enforce these rules? I do find the case rules make for more readable code, but I can in many languages write incorrect case and it will run, which defeats the purpose (it simply gives the obfuscated code writers one more weapon against us...)
Sig under construction since 1998.
MyTerm is a class name by convention only. You could define a class called myTerm, and create instances of it called MyTerm. The only thing that case sensitivity buys you here is the ability to have all three at the same time: myTime, MyTime, and MYTIME. There is no rule saying that MYTIME has to be a constant/static member.
If it was case sensitive, you would have to declare a class called MyTerm (or myterm, or whatever), and an instance called myTermInstance, and call the static variable MYTERM_STATIC or something like that.
Good points.. the question begging an answer, though, is "Do you have to use different cases if you don't want to?" It seems the OP has no place coding anyway, but if the case bothers them, then why use it..?
Marxist evolution is just N generations away!
Sun's coding convention says all package names should be lower case.
IMHO, Sun should have written some of these conventions into the language as well. They could have enforced at compile time the restrictions that ALL_CAPS are constants, Classes start with caps while variables and methods() don't. Sure they couldn't know the difference between SAXParser and SaxParser, but it would at least keep a most code consistent that way.
Why isn't this guy +5 yet? Mods, do your job, this is good shit!
PACKAGE COM.MYCOMPANY;
// tHIS METHOD IS CALLED BY THE SERVLET CONTAINER JUST BEFORE THIS SERVLET // IS PUT INTO SERVICE. nOTE THAT IT IS POSSIBLE THAT MORE THAN ONE // INSTANCE OF THIS SERVLET CAN BE CREATED IN THE SAME vm. // iNITIALIZATION CODE... // sEE E1035 gETTING AND sETTING iNITIALIZATION pARAMETERS FOR A sERVLET // tHIS METHOD IS CALLED BY THE SERVLET CONTAINER TO PROCESS A get REQUEST. // tHERE MAY BE MANY THREADS CALLING THIS METHOD SIMULTANEOUSLY. // tHIS METHOD IS CALLED BY THE SERVLET CONTAINER JUST AFTER THIS SERVLET // IS REMOVED FROM SERVICE. // sHUTDOWN CODE...
IMPORT JAVA.IO.*;
IMPORT JAVAX.SERVLET.*;
IMPORT JAVAX.SERVLET.HTTP.*;
PUBLIC CLASS mYsERVLET EXTENDS hTTPsERVLET {
PUBLIC VOID INIT() THROWS sERVLETeXCEPTION {
}
PUBLIC VOID DOgET(hTTPsERVLETrEQUEST REQ, hTTPsERVLETrESPONSE RESP) THROWS ioeXCEPTION {
pRINTwRITER OUT = RESP.GETwRITER();
OUT.PRINTLN("a sIMPLE sERVLET");
OUT.PRINTLN("tODAY IS "+(NEW JAVA.UTIL.dATE()));
OUT.PRINTLN("");
OUT.CLOSE();
}
PUBLIC VOID DESTROY() {
}
}
Wrong. Please read what you linked to:
It then gives examples of identifiers, including one consisting of (in all lowercase): alpha, rho, epsilon, tau, nu.
(Slashdot appears to filter out non-ASCII and doesn't support HTML entities, so it might not look exactly the same.)
(Score: +5, Troll)
The only thing that case sensitivity buys you here is the ability to have all three at the same time
What case sensitivity buys you is choice. Exactly, you can use the MyVar myVar MYVAR scheme if you like, or the MyVarClass MyVarInstance, MyVarConstant, or MVc MVi MVc, or pretty much anything you wish. But I cannot imagine a useful situation where you would want or need THISVARIABLE to be equivalent to ThisVariable.
The only thing case insensitivity buys you here is just the slightest bit of idiot proofing (but let's be honest, the kind of people who confuse MyVar with MYVAR would also get Myvariableinstantiation and myvariableinitialization backwards).
Comments should be like skirts. Short enough to keep your attention, but long enough to cover the subject
Well, duh. Nothing to add to that. Read it wrong...
That is the killer argument then, Java cannot be case insensitive since u-umlaut would be equal to U, u would be equal to U, but u-umlaut would not be equal to u. No need for the rest of the discussion.
I believe posters are recognized by their sig. So I made one.
English is case-sensitive. Letter cases have meaning. Are Democratic principles the same as democratic priciples to you? Why in the world would you want your programming language to be kluged into being case-insensitive? You lose a whole layer of meaning, in a domain where you need MORE precision than you do in spoken communications.
// define Client instance as default (constant)
Visual Basic takes the approach of PHP and some other scripting languages that aren't really intended for complex programming. It's probably okay to be case-insensitive
Java is designed to facilitate "real" programming, though, so case-sensitivity is a must.
I think this argument tends to just go away once you start a serious programming project; you need to start following standards for case-usage, which allows stuff like this to make sense:
Client client = CLIENT;
You may have seen code out there with "warts" on the beginning of variables (id_variance, xas_serverNames and so on). Those are there because some programmers want MORE information about what they're seeing, besides what they can get from letter-case. Trust me, they don't want to hear that they'll be getting LESS info than even basic ASCII offers then.
I think most of my other arguments have been explained clearly in other posts... so I'll just second those. Basically, case-insensitivity is a kind of shortcut to help quick-and-dirty scripting with small namespaces. Personally I don't even like that (because you still need to spell the damned variables right - what are you gaining?), but it makes sense in that domain... but that's it.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
I have a friend who likes to say that Java is Lisp in C clothing.
illegitimii non ingravare
The fact that the current language specification states that only ASCII character can be used for identifiers does not imply that future releases of the JLS will *not* allow Unicode identifiers. Destroying the possibility of future i18n for current convenience does not seem wise to me.
-30-
Every language has strengths and weaknesses; things we like about it, things we don't like.
Java is case sensitive. You aren't going to change it.
Grow up and deal with it.
All older than C, and all built on pre-ASCII systems originally. Punch cards don't have lowercase.
-30-
No, you are confused. Programs are data, too. At least they are data to compilers.
Consider a regular expression. Is it a program or is it data? Many filtering programs will load in a bunch of filters written as regular expressions. Which parts should be case-sensitive or case-insensitive? It turns out that it is relatively standard for lower and upper-case pattern elements to have opposite meanings, e.g., \w matching any alphanumeric character, and \W matching any non-alphanumeric character.
Interestingly though, LISP historically has been both case-insensitive and a language that allows programs to be easily treated as data. I programmed in LISP for a long time, and the case-insensitivity wasn't any big deal. You'll get used to case-sensitivity and learn to take advantage of it.
Thus, case sensitivity is a Good Thing.
The perfect sig is a lot like silence, only louder
No need for Sun to do anything. Java's compiler is completely available programatically -- you could write a "compiler" that would just convert the input stream from the file into lower-case (avoiding strings and char definitions, or course) and pass it on to the regular compiler.
No one who knows enough Java to do it has ever *wanted* it, though, which should be a pretty big hint to newbies looking for case-insensitivity in Java.
Personally, I've seen arguments against case-sensitivity, but I haven't seen any good ones yet.
--
Everything should be made as simple as possible, but not simpler. - Albert Einstein
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
This is actually a problem with java ...
...
This is NOT possible in Windows NT
Some might argue that this is a problem with Windows, not Java.
In english, the concept of upper and lower case is quite simple.
...
I think you mean:
In English, the concept
(Sorry, couldn't resist...)
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
that english is case sensitive.
GEE, LET ME THINK...WHY DO WE NEED CASE-SENSITIVITY IN A LANGUAGE? COULD IT BE BECAUSE CASE CAN ENCODE ADDITIONAL MEANING? Take the above paragraph as an example. Was I yelling? Sure seems like it. In the same way, additional meaning can be encoded within a programming language by using that little Shift button on your keyboard.
Axiom: Pointless complexity is a Bad Thing.
Conclusion: Case insensitivity is a Bad Thing.
_O_
.|< The named which can be named is not the true named
greater control over code production.
as mentioned in uniformity, developers can establish and enforce naming conventions which makes sense.
these include capitalization for variables, classes, and constants.
I can't even believe anyone would ask "why have a case sensitive programming language".
I've just started learning Spanish, and to my exceptional disappointment it is as spelling-sensitive as English. I'd like to ask Slashdot readers to make the case for spelling-sensitivity in a written language, because I can't see it. Although I've used English on and off since 1976, I also have a history of Egyptian heiroglyphics, runatic symbols, street signs, pictographs, and other legacy languages that were never spelling sensitive (perhaps due to the lack of letters in these symbolic languagues). Today I use modern languages including American Sign Language which preserves spelling for pleasing appearance, but is not spelling-sensitive itself (it will correct the case for you in the Word, which is quite nice). In all my years of speaking I have never seen the rationale for making a language spelling sensitive. It simply makes typing it in harder, and mistakes easier, yet we persevere with maintaining it in modern languages like Spanish. Without making this into a religious war, can someone make the argument of why spelling-sensitivity in a language is 'a good thing'? And don't confuse this with handling spelling-sensitive surnames, which is fine."
HIV Crosses Species Barrier... into Muppets
I think there's an ambiguity in the wording of that section. At one point it says (omitting pieces), "The Java letters include uppercase and lowercase ASCII Latin letters, and, for historical reasons, the ASCII underscore and dollar sign." When I first saw that, I reached the same conclusion you did; it was only after reading the whole thing that I saw I was wrong. They really ought to have said something more like, "The Java letters include (but are not limited to)...".
I see SO MANY comments along the lines of: "A real programming language is case sensitive" or "A real programmer uses case properly" Well you know what? Im a real programmer, and I think case sensitivity is retarded. How ambiguous is it if you use a couple of variables, MyName and MYNAME? Quite. Today's geeks seem to be more inclined to jam something into 1 line of perl instead of making their code readable and maintainable, and the ignorant comments on here prove just that. Plain and simple, it is BAD practice to have any variables named the same, even with varying case. It's a different variable, it has got a different purpose, therefore its declaration should be unique. Having to deal with common typing case mistakes is one thing that reduces productivity. If you ABSOLUTELY NEED to have variables of the same name, use namespaces. Thats what they are there for.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
As far as I know Java can also take Unicode source as input and then the filesystem must also handle that, which would work on NTFS, but not of FAT and probably not on any Unix FS AFAIK.
Well...
You know nothing then.
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.
This is a non-issue. You can bring the same argument and it would not work exactly the same way on strong typing, or you could ask that the compiler catches obvious spelling errors.
The fact of the matter is, if you had used a variable called foo somewhere, you should have no reason to call it Foo elsewhere and FOO later. No matter if the language allows case sensitivity or not, that would just be bad practice and would confuse the hell out of anybody who would try reading your code.
Not even going to mention what other posters touched upon, that casing is used to indicate the entity type (constant, variable, class, function etc).
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.
Then if "the programmers aren't too technical", they probably don't know where the shift key is anyway. Don't like case-sensitivity? Simple: write everything in lowercase.
As somebody else pointed out, there are some fields such as mathematics or physics where lower and upper case have well established distinct meanings, e.g. g for acceleration and G for the gravitational constant.
However, I think that for the vast majority of applications, case sensitivity is just a minor irritation. CamelCasing is a good thing; however the effort used to drum this into novice programmer's heads would be better spent in drumming more significant stylistic principles.
I'd say as a general rule, if we choose our language not to be case senstive, we should enforce variable declaration. If we choose to be case sensitive, then creation of things that differ only by case should generate a warning unless the compiler is told to suppress these warnings by a directive.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Java is case sensitive and I don't mind. But if it bothers your, try Eclipse; it should help you a great deal.
Eclipse is a free IDE from IBM.
LOTS OF OLDER COMPUTER LANGUAGES AND SYSTEMS DIDN'T NEED OR USE LOWER CASE LETTERS, LET ALONE LATIN-1 OR UNICODE. DOS FILE NAMES ARE NOT CASE SENSITIVE NOR ARE THE FILE NAMES IN IBM'S OS/2. USING LOWER CASE IS SILLY. THOSE OF US WHO ARE ANCIENT PROGRAMMERS DON'T NEED NO STEENKING CASE SENSITIVITY.
-- Norm Reitzel
Don't take life too seriously; it isn't permanent.
you have to deal with this rubbish, too?
i'm currently working with VS.NET. it has auto-creators, which generate some needed code. That is fine, but the name choice!? look at this real example:well, DataSet1 (character "1" at the end ) is a Class, and DataSet11 (eleven) is a variable.
the difference is one frickin character, which actually looks like a typo. it could as well be lowercase("L") or uppercase("i"):if the language was case-sensitive it would be enough to write
Fight Frist Psoting!
Browse Slashdot with 'Newest First'!
When we got the assignment (the first 2 in fact) they just wouldn't compile as-is on the unix boxes we usually worked from. Pissed a lot of us off because we had to fix the problems :(
Slashdot has utterly lost any credibility it might once have had in the serious programming community, but honestly, this must be the nadir.
I'm not even going to try and list arguments FOR case-sensitivity, rather, I'll ask for substantial arguments against. The original poster had none.
If you want case-insensitivity in your compiler, why don't you just preprocess your file to change all keywords (ie, anything that isn't a string) to lower case? Surely this can't be that hard. I'd imagine there's probably a way to integrate it into gcc even as some custom preprocessor.
Or alternately, how about just using lower case when you write your sourcefile? If you don't want case-sensitivity because it's harder, why would you bother using capitals in the first place? Just stop using the shift key.
Do that for a while and see if you get caught with a SetsLower/SetSlower case. If you don't, all good. If you do, now you know why people bother.
The reason for case-sensitivity is rather simple when you consider how a compiler works. Each variable/constant name is converted to a token based on its ascii representation. As the letters 'a' and 'A' both have different ascii values, the amount of work required on the part of the compiler or at run-time to convert the cases would far exceed the inconvenience of not being allowed to munge the readibility of the code. Essentially, the compiler would have to shift the case of each letter of each variable (either to all lower or all upper) every time the code was compiled. Given that a program can contain hundreds of thousands of lines of code (if not millions), this can have a very significant impact on compilation time.
Ryosen
One man's "Troll, +1" is another man's "Insightful, +1".
Search for consistency in the entire thread.
Related keywords: naming conventions, coding style.
Just because you can refute a set of incorrect arguments does not imply that what they defend was wrong.
Brief: if you respect a language's coding style, you will never encounter problems with casing. You SHOULD respect a language's coding style so your code is easily read and understood by other programmers in the same language.
If you program for yourself and really want to use your own conventions then you are on your own, don't ask the entire world to forget their standards so you can write unparsable code.
If you name two classes with different case only, I think that can be considered bad enough practice that it is ok that you can't store both of them.
However case dependece is vital so you can name a variable and a Class with different case. It would be incredibly annoying if I wanted one instance of the Class "Rectangle" and I was unable to call it "rectangle". The only alternative to case dependence is to change the syntax of the language so that at any point in parsing it can know if a type or id is expected, that would greatly restrict the expressiveness of the language and add annoying extra required keywords.
Storing anything other than UTF-8 in filenames is an incredible mistake, and whoever at Microsoft did that should burn in hell. All Unix systems such as Linux fortunately use UTF-8.
As far as I know Java can also take Unicode source as input and then the filesystem must also handle that, which would work on NTFS, but not of FAT and probably not on any Unix FS AFAIK.
HFS+ should be able to handle it.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Consider this snippet of java code:
And yet you see TransactionRolledBackException propagating to a higher level. You have looked at the code and swear you are catching it. Oops, missed that upper case B.Arguments that you can do something like this:
are irrelevant. This is also perfectly legal in java:Case sensitivity does nothing to enforce preferred conventions, and actually enforces unreadable code.Would I like to read code that says System.arrayCopy(...), or Color.BLACK ? Sure I would, but that wouldn't compile. Case sensitivity enforces the wrong thing (literal consistency) rather than convention (conceptual consistency).
Would I like to rename that class which someone called subProductPanel to SubProductPanel? Sure I would, but that would involve changing the 15 classes that reference it, not to mention the file name, which would confuse CVS on windows clients terribly.
So I am stuck with my subProductPanel class name without more effort that it is worth to fix, because of case sensitivity. If everything was case insensitive, then I would be able to change it easily.
As for portability, case sensitive and case insensitive are incompatible and equally create portability problems. Windows having a case insensitive file system causes limitations in Java's portability because Java considers MyClass and myClass to be two separate names needing two separate files. Windows will not support that. So Java code that runs on Linux will not work on Windows, and vice-versa (think about code which reads from the file system).
Bottom line:
Case sensitivity creates an environment condusive to hard-to-find bugs because people aren't case sensitive. They may notice case when it is out of place, but not normally.(sOMEtHINgouToFplACE vs. somethingOutOfPlace will be noticed. Not, however someThingOutOfPlace or SomethingOutOfPlace and only programmers consider SOMETHINGOUTOFPLACE different).
A case sensitive environment enforces only the non-use of conventions. A case insensitive environment lets you use the convention even if the author of the API forgot to.
As for BasicSend vs. BasicsEnd, that is an argument to use something other than case to differentiate words, not just hoping that people notice the difference. Wouldn't Basic_Send and Basics_End be much better?
As for differences in how languages handle case insensitivity, String.toLowerCase() figures it out, so would the computer language. You establish rules and stick to them. Will a language which targets the English speaking get all other languages right (the way most speakers of that language would intuit)? Probably not. That doesn't mean that the target audience has to spend thousands of hours chasing down unnecessarily hard to find bugs.
VB's case insensitivity is OK. My problem with it is that it corrects the case of stuff that you type in.
so if you type "abc", it will search around looking for an "abc" and change your typed in word to match one of the ones it finds. It's unclear to me how it chooses it's model.
2 problems with this:
- what if you don't like the model it chooses? you have to go through the entire project changing them one after the other until you find the "master model" and then they all change
- it's possible to load up the project with one of the files writable, change a line of (unrelated) code, check the differences before you check the file back in and VB has picked a frikkin variable name and changed the case on every instance of it, generating a load of spurious diffs
stay frosty and alert
The first principle of programming is accuracy. Case sensitivity probably wasn't a deliberate conscious decision, but merely a side effect of this principle. That the language designers should incorporate a mechanism to aid in inaccuracy never occurred to them.
My advice: get over it. If you can't even handle the minimal accuracy that case sensitivity demands, then perhaps programming is not for you.
Don't blame me, I didn't vote for either of them!
An illustrative (if nonsense) piece of code typical of the style I may write: (this is C++ - but the argument is the same)
Now imagine, having to think up more illogical and less descriptive names because Apple, and Apples, and Fruit are already taken! I'd hate if my constructor arg couldn't be called apples too - that what it is. Java forces me to write this.apples = apples. I hate having to prefix with '_' or worse 'm_', as it just makes more work during reorganization/refactoring etc.
It already disturbs me that I can't use the same name for a method and a field. I'd like to be able to write code like:
Unfortunately, C++ can't tell 'Any value' from 'Any value()'. At least in C# I can use a property - but I still can't utilize the same name :(
/..sig file not found - permission denied.
Well I guess what I really mean is why have different shapes for uppercase and lowercase of the SAME letter?
I can see how a large letter at the start of a sentence makes it easier to scan text.
But why isn't A just a large version of a? Why does H have more ascenders that h? Why does D face in the opposite direction to d? And what has G got to do with g?
> If you name two classes with different case only, I think that can be considered bad enough practice that it is ok that you can't store both of them.
:)
:
Fair enough, but I was pointing out that Java's habit of forcing a directory structure for packages has the effect of having to force the language to use similar naming conventions as whatever filesystem lies underneath.
> However case dependece is vital so you can name a variable and a Class with different case.
This is a valid point, and a good argument fo case sensitivity, btw. Prolog does somthing like tis, varibles are force to use uppercase, symbols forced to use lowercase. Some people hate it, but some people also hate Python's indented code as delimiters thing. A matter of taste, I suppose. Since Java uses naming conventions to indicate semantics in lots of places (Java beans awith getters and setters being the prime example) such a convention might be in place here, as a previous poster indicated.
> Storing anything other than UTF-8 in filenames is an incredible mistake, and whoever at Microsoft did that should burn in hell.
NTFS uses Unicode for pathnams and was AFAIK the first filesystem to do so. FAT was invented before UTF8 so it has an excuse
> All Unix systems such as Linux fortunately use UTF-8.
So I live and learn
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
You are actually making an argument for case sensitivity. For one, the snippet you mentioned wouldn't even compile in Java unless someone defined both exception spellings as different classes, and if someone did that he doesn't deserve to call himself a programmer. Other than that, case sensitivity makes it easier to find bugs, and take it any way you wish, but if you actually programmed in any serious language you would have already known that.
Were naming conventions properly followed, case sensitivity should never be an issue. I noticed that most "programmers" who take an issue with case sensitivity do so because they prefer to force the coding style of a language they know to one they are learning, and is mostly because they are used to "carefree" naming. Your example's point is that if you mistype (which arguably could also be misspell) a variable name, it should still work. I doubt that many people who actually make a living off writing code feel the same.
And one final note regarding the part with renaming the class. When you make modifications to someone else's code it is good practice (and common sense, I might add) to follow that person's conventions whether you like them or not. So you shouldn't start renaming things in the entire source just because you didn't like their casing.
So you are saying you would rather prefer the code to use subProductPanel in some places and SubProductPanel in others for the same variable ? And if some other guy comes after you and decides he will use SUBPRODUCTPANEL that is ok too ? The reasoning for this being what, exactly ? That you don't like the person's coding style therefore you'd like your additions to stand out in their own way ?!
It's simple: I demand prosecution for torture.
Most programmers are male, Many are ADD, some are dsylexic. Most can type almsot as fast as they think. MY pinkie raNdomly pushes shift without being asked TO. ANd sometimes doesn't release it when asked to. I Alsso sometimese accidentally double letters. Case insensitivity with a case aware IDE allows me to focus on What the Foo I am doing with BAR without worring about which foo I baR. I tend to Trust my IDE to let me know during code review... before I complie that I didn't put those letters in the write order. I use a modified version of MS's Hugarian notation for variables so that clsFOO is different from szfoo and clsszfoo is something else entirely...
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
Most packages are bundled in jar files so the case sensitivity problem is a non-issue at runtime. The programmer can always fix those kind of problems for compiling the package during development (if he/she is working on Windows). Java identifiers are limited to ASCII 7bit so it doesn't make a difference if the filesystem supports unicode or not. The contents of the source files themselves (string literals, comments etc) can be in unicode but they don't have anything to do with the filesystem.
HFS+ is not a UNIX filesystem.
Nathan's blog
I doubt it. Although I can't find any evidence, I'm willing to bet that HPFS supported Unicode. And HPFS was around before NTFS. NTFS is supposedly derived from HPFS.
Nathan's blog
There are only 26 letters in the alphabet. Some platforms (like old Mac OS) have a file length limit (31 characters, for example). Since Java stores class files in a file by the same name, this means that class names can only be 26 characters long (minus the ".java")
So, for a programmer like me, I must have case sensitivity. Otherwise I am limited to somewhat more (because of use of non-alphabetic characters) than 6.156119580207158e+36 class names. Clearly inadequate.
Regardless or your view of case (in)sensitivity, one should not rely on case sensitivity when programming.
More specifically, IMHO, one should not have two variables or methods/functions which differ only in their capitalization, with very few exceptions. It's too bloody error prone and too hard to catch.
Some would argue that this is an example of why case insensitivity is a good thing. I disagree -- case sensitivity forces you to think about how you name your identifiers and can, in principle, lead to more readable code, due to the consistency thereby enforced.
ASCII has a relatively simple, consistent mapping from lower- to uppercase and vice versa. Letters all have a single upper-lower 1:1 pair, while all others are caseless and upper and lower are the same. It's a simple map.
But ASCII is obsolete. Java doesn't use it, even for variable names. When you go beyond ASCII, you have many different case maps to choose from. Different cultures have different case equivalency rules, some of which are rather complicated. And then, as others have mentioned, there are the coding conventions that make use of casing to make distinctions, but these conventions ride on top of the cultural conventions regarding which distinctions matter. (I don't want to get into the details, but what one man considers a single letter another might consider to be two, for example.)
You can avoid all of these thorny cultural disagreements by either limiting all identifiers to ASCII with its single equivalency map, or by just making the rule that identifiers are the same if and only if they are composed of the same sequence of characters and avoiding the issues of equivalency maps altogether. (Until you get to normalization, which is another can of worms....)
Since Java allows a much wider range of characters in its identifiers than the puny ASCII character set, it chose the second option: ignore equivalency maps and declare that "if it's not the same, it's different".
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Yes, if you have the job of maintaining code that uses different cases.
I'd rather be lucky than good.
...you need to learn how to type!
HFS+ is not a UNIX filesystem.
Funny, Apple's Unix runs on it. Linux can use it (probably no Grub support yet).
Unless you mean to differentiate UNIX (tm) from Unix (philosophy)?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
CASE SENSITIVITY IS IMPORTANT BECAUSE IT LOOKS LIKE YOU ARE YELLING WHEN YOU TYPE IN ALL CAPS
(It's also important because if you don't type with lower-case letters mixed in to your Slashdot post, you'll never get past the lameness filter)
It is easier to build strong children than to repair broken men. -Frederick Douglass
"It seems the OP has no place coding anyway, -- "
Unless, of course, he maintains code like this:
int main(int argc, char * argv[])
{
sOmE_TYpeOfMiNE VaRiAbLe_SoMeTYPEofMiNe;
return 0;
}
Marxist evolution is just N generations away!
As you probably know there are a ton of languages that will compile down to Java bytecode and run on any JVM (e.g. jpython).
So why don't you just grab an OpenSource Java compiler and add a --case-insensitive compile switch?
You could then code merrily in whatever case your caps lock key happened to be set in, and it would run on anybody's JVM.
Or just suck it up and get used to case sensitive programming like the rest of 3 million Java developers
---
JaVA hOSTing on a lINUX vps
Haven't named any Java packages in Unicode though, so don't know about that.
More than mere navel gazing.
Yes... by default. UFS is also somewhat supported and case sensitive. Also, (as of Panther) we see this in newfs_hfs's man page:
Of course, this won't help you if you're trying to deploy a product to the masses (users don't like developers formatting their disks for some reason), but for in house/personal use it WorksForMe(tm).I suspect the answer is very technical and involves the Unicode standard.
Also, I remember reading that java was designed as a "language focused" language - meaning that Best Practices of programming language design was their first priority. There have undoubtedly been studies demonstrating that consistent text case improves code comprehension and increases efficiency (ok, I don't have a link to such a study, but after reading Code Complete, I have to believe it exists).
Finally, case-sensitivity makes for some really tricky (and annoying) questions on the Java Programmer Certification exam.
By Apple's UNIX, do you refer to the old A/UX (which carries the UNIX(R) mark) or to Mac OS X (which does not carry the UNIX(R) mark)?
IMHO it helps enforce coding consistency. Very helpful when writing and debugging code. If you wrote a program using hungarian notation and say use: //my java is rusty
String arrMyArray[5];
It is easier if case sensitivity won't let the lazy type arrmyarray[x]. It almost disappears in the text. When debugging and examining code, consistent variable names help you pick stuff out of the fray, visually, easier.
I am a huge fan of languages such as C and java which are fast, strongly typed, and rigidly enforce consistency in referencing variables.
Slop=hard to maintain.
Imagine reading a book where the case is all whacked. It wouldn't be as easy.
neilio
As someone with history of Java, who does C now, I instinctively want case sensitivity. If I did not have to use case, I still would. Ie, all my variables would be myStruct even if I could reffer to it as mySTRUCT and MYstrucT and whatever. So lack of compiler enforced case checking wouldn't make code less readable.
One benefit I would get out of C being case INsensitive is this:
I often link fortran and C objects together. For those of you who don't know, fortran is case insensitive, but when it is compiled, all function symbols are compiled as lower case with an _ attached to the end. So if in my fortran file I have a subroutine called MYstupidFORTRANroutine, and I wanted to call it from C, I would need to extern mystupidfortransubroutine_ (lowercase with the attached ampersand)
Which is fine.
Now here's the problem. When I do a function call from Fortran (something like CaLL MyStuPiDcSUBrouTINE) the compiled code actually calls a function mystupidcsubroutine_ . That means that in C, I must name my function mystupidcsubroutine_ (all lower case with the ampersand) in order to have it callable from fortran.
Now, life would be simpler if all the compiled symbols became standard and case insensitive accross all languages. That would allow us to link objects together and have functions callable from one language to another. Since this one case insensitive name would have to be standardized (eg: always make it lowercase with _) then the language would have to be case insensitive as well, because otherwise myFunction and MYFUNCTION would be different symbols but must share a common name - impossible.
This isn't really a super-strong argument for case insensitivity, but it's a possible one. Personally, I would still keep my code consistent whether I had to or not (when I write fortran code I do it even though I don't have to. it bothers me to see fortran code SHOUTING AT ME) And I would not agree that having variables called FOO Foo and foo in your code refering to different things isn't too good. Though I guess a function taking a string argument "file" and opening the global file pointer FILE to that "file" is kinda reasonable.
Ecce Europa - Web Design for Business
>>It won't be considered a different variable, it >>will be considered an undeclared variable. The >>compliler will choke on it. with certain settings, languages like php will automatically register a mistypes variable (instead of Foobar popping an error when you mean to type FooBar, php will automaticaly create a new variable Foobar). This has caused me alot of debugging time as a a result of typos because of this... of course a properly-secured php setup won't allow this, but by default php will allow this - and cause you problems either way. i am personally FOR case-sensitivity, you can tell a lot from a proper naming convention using case-sensitivity. plus 'most' operating systems (with one major difference) will properly enforce case-sensitivity for files your program may be accessing (or compiling), so this should carry across to the programming language for the most part.
Gekido's Lair
That's a Unicode Problem.
Then how would you solve it? Remember that identifier names in some languages may have diacritics as well as case. Would you consider two vowels with different diacritics equivalent, just as you consider two vowels with different case equivalent? In fact, some pairs of distinct lowercase strings may upcase to the same string. For instance, both German ss (two letters) and s-set (a ligature that rather resembles a Greek lowercase beta) upcase to SS (two letters), and both English fl (two letters) and f-l (a ligature) upcase to FL.
As for the red and blue argument, last I checked we were working with plain text files.
Plain text files in UTF-8 encoding can contain characters in all sorts of scripts. Many scripts do not have an upper and lower case. Some other scripts do have upper and lower cases, but the rules for converting a string to upper and lower case vary from language to language within the script and can prove much more complicated than those of English. Would you want to have to use some sort of markup around the names of identifiers to specify the language whose rules for case-normalization the compiler should use for that identifier?
[In the Java programming language,] is MyThing.init() calling a static method on the MyThing class, or are we calling an instance method on an instance?
That's Java. C++ distinguishes static method calls (with ::) from instance method calls (with .). This type of operator might more readily lead to a similarly-syntaxed language without case sensitivity among ASCII characters.
if somebody tells you, "I can take a plain text file"
Written in what human language? If the file is source code, with identifiers written in what human language?
you don't pause to ask for a laundry list of capitalization rules, do you?
Yes one does. Please read the Unicode standards. Not all languages have encodings where upcasing a character is as simple as & 0xe0.
No, I meant & 0xdf. I just went and checked on my calculator. Sorry for the confusion.
I am opposed to the base language forcing case-based standards.
Virtually all human programmers write identifier names in some sort of human language. Not all human languages share the same script, and even within one script, they do not share the same case folding rules. The Java language permits identifier names in any of several scripts of Unicode. In what language does a Java programmer whose first language is not English write identifier names? Can you cite all the case folding rules for those languages, including changes in diacritics and even breaking of ligatures?
With DP case sensitvity just gets in the way
How do you expect to solve it and maintain internationalization? Programmers use human languages for identifier names, and not all human languages upcase trivially.
Scheme is specified to be case insensitive. However, everybody sticks to a convention of all lower case, with dashes separating words. I've been using a case-sensitive (thus non-conforming) implementation of Scheme for years and only noticed its non-conformity recently.
I'm neutral as to whether case-sensitive or case-insensitive is better, but I think you should retract your SetSlower vs SetsLower argument.
Holy Crap! Are you seriously arguing for programs that use both E and e as variables??? Jebus, I hope I never have to maintain your code.
The case sensitivity is just natural. It is not really something that was implemented. In fact, case insensitivity is what would have to be implemented.
Does anyone still have one of those old Hewlett-Packard keyboards that had a key marked AIDS?
You can date them quite accurately, from the time they had to start calling that key something else.
I recall that there is only one word (well, pair of words) in English that changes not only its meaning but also its pronunciation when it changes case: "polish" vs. "Polish"
Of course, the fact that this merits mention in a trivia book (where I found this tidbit) indicates how in general English is case insensitive.
"Prepare for the worst - hope for the best."
I would suggest obtaining a little book called :
Java Style Guide. A little green pocketbook that
covers the how and the why of code style.
It explains Java's reason for case-sensitivity
quite thoroughly.
No, I can't see the point either.
There is no universal algorithm for case-matching or case conversion.
In most languages, the capital version of i-with-a-dot is I-without-a dot and the lowercase version of I-without-a-dot is i-with-a-dot.
In Turkish, the capital version of i-with-a-dot is I-with-a dot and the lowercase version of I-without-a-dot is i-without-a-dot. More logical.
So any program that enforces case matching and case conversion will not work the same on all computers.
Makes you wish the Turks had stuck to Arabic script and not changed to Latin in 1922. Except that Arabic was even more useless for the Turkish language than Latin is...
Case-sensitivity is often used to distinguish the kind of thing a symbol refers to.
Person is the name of a class.
perSon is the name of a function, which performs an operation once for each male child of a certain parent.
pErson is a pointer to an Erson object, if your language has pointers. (Okay, I'm reaching here, but assume "Erson" means something to the programmer.)
i) ...is worth two in the bush. ...is worth two in the Bush.
I)
Which do you prefer?
Funny, Apple's "UNIX" resembles UNIX about as closely as it resembles Mach and microkernels or MacOS9. And just because Linux can use it doesn't mean it's a UNIX filesystem. Linux can use FAT.
Unless you mean to differentiate UNIX (tm) from Unix (philosophy)?
That is also a valid point, in that HFS+ definitely does not follow the UNIX philosophy.
Nathan's blog
If this is your only gripe then stick to stupid web tricks with Javascript.
public final transient String president = DUBYA;
org.foo.Bar.bleh must be in org/foo/Bar
this is perfectly possible. The class Bar has a member bleh, it resides in package org/foo
org.foo.bar.Bleh must be in org/foo/bar
this also is fine. The class Bleh resides in package org/foo/bar
public final transient String president = DUBYA;
In any given day I may code in half a dozen different languages (PHP,ASP-VBSCRIPT,Python,Javascript,SQL-MySQL :: SQL-Oracle) maybe a few more, it has gotten to the point that I often don't have a clue which ones are case sensitive and which are not, I just always treat everything as if it was case sensitive, and only in parsing text do I bother to check.
Heck I just got back into programming PHP for the last two weeks. I and thought it was case sensitive. Good Coding Practice almost makes the Case thing a non issue.
When I learned python it took about a month before I had my first bug due to case, I always thought it was just case in-sensitive.
Longer story short, just make a good habit of keeping Case the same and this whole issue kind of disappears.
And just because Linux can use it doesn't mean it's a UNIX filesystem. Linux can use FAT.
FAT can't preserve Unix semantics, HFS+ can. How else do you define a Unix filesystem?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
i gave up learning to programm
...
in java because my first "hello world"
didn't want to compile. just because
of the "case sensitivity".
i would rather have good names for variables, etc.
then having them be case sensitive.
but that's just the reason of a lame
pascal programmer
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.
You need more than case-sensitivity to achieve that without concern for character sets. For example, Spanish has a double-ell character ("ll"), which shouldn't be mistaken for the two ells in the classic English "Hello, world". And in just the opposite situation, in German "sz" and the sharp-ess (it looks like a Greek beta) are interchangable, and several other ligatures have equivalent accented characters.
So the short answer is: that does not compute.
After changing a student's program recently (German) that had umlauts in his identifiers which are not 7 bit ASCII I can ensure you that Java compilers do not enforce that rule. However, its interesting that it exists. The program did not compile on my machine, it did on his.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
An identifier is an unlimited-length sequence of Java letters and Java digits, the first of which must be a Java letter.
Letters and digits may be drawn from the entire Unicode character set, which supports most writing scripts in use in the world today, including the large sets for Chinese, Japanese, and Korean. This allows programmers to use identifiers in their programs that are written in their native languages.