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."
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.
Link to the original post
...And that's why you should sign up for free hosting with aloofhosting.com.
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?
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
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
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.
It won't be considered a different variable, it will be considered an undeclared variable. The compliler will choke on it.
As it should. If people use case convertions to convey information - static variables are capitalized - then the compiler enforcing consistent casing is good. Else in file1.c it's "ThisIsStatic", in file2.c it's "thisisstatic"; Alice, looking a file1.c, knows it's static, while Bob, looking at file2.c, doesn't get that same information. The compiler is merely making you pick a way and stick to it, for the benefit of your fellow humans.
Should the compilier also ignore misspellings? If "Variable1" appears all over the place and in one place "Variabl1" appears, should the complier auto-correct it to "Variable1"?
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Case sensitivity is just a tradition, with its roots in the Old Testiment.
Um, funny maybe, but wrong. The Old Testament was written in classical Hebrew (with maybe a bit of Aramaic in some of the later parts), and that alphabet has never had a case distinction.
Upper/lower case is something that developed only around 1500 years ago, plus or minus a few centuries. It was adopted in the Roman, Greek and Cyrillic alphabets, but that's about it.
It is useful, as we all learned in grade school. Thus, many managers have aids who are very helpful. But if they have AIDS, it's a serious medical problem.
One of the reasons that the project I'm working on isn't using Macs is that OSX uses a caseless file system. When we tried porting several important software packages to OSX, they were utter disasters. The symptoms were bizarre and inexplicable, and took forever to hunt down. It turned out to be caused by executables from different packages that had names that differed only in capitalization. Each package had its own convention, so there weren't any collisions on linux and other unix-like systems. But on OSX, there were cases where a component of package X ended up calling a program from package Y, and they both went crazy. We spent so much time finding the problems and fixing them that we decided to just not use OSX except as a UI.
It's too bad, really. My 17" Powerbook is a really neat tool. I'd like to use it as a real computer. It wouldn't have been much more work for Apple to hide their case insensitivity in runtime libraries, the way it should be done. I really wish they'd done that, rather than breaking the assumptions that all other unix-like systems are built on.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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