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."
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.
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.
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
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.
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
With Case Sensitivity, I can have 52 one letter variables, not 26!
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.
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.