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
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...
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
I wholeheartedly agree with this point. Speed reading wouldn't be possible without case distinction. It's even easier in german, where every noun has to be captalized, so it's even easier to find the (possible) subject of a sentence. Or when you're trying to find names of persons in text, the fact that they start with capitals is damn useful. I find this the same with Java and C++. It just makes it easier to read.
Trainee BOFH -- Just give me your username & password
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...
This kind of made me think of my calculus homework which I should be doing right now. Especially for integration, and such. We've variabled "m" and "M". Sure, in a program, it wouldn't be hard to change them to something else like "bigM" and "littleM", but it would sure make the code a lot simpler to read to just have "m" and "M". This is in a case where you're writing a calculus-related program. Eg. a graphing calculator.
Just a thought.
- shazow
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.
Case sensitivity helps with naming convention. Static variables are always capitalized. Plus it doesn't hurt having them so why not?
The idea of eliminating case sensitivity seems appealing until you need it.
-----
One is born into aristocracy, but mediocrity can only be achieved through hard work.
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
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.
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
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.
Your first point is by far the most important point that you made. Character sets are not uniform (at least in the world of 8 bits per character), even among nations that share most of them, and the upper/lower case equivalents are not always the same between them.
I also agree with your final point - case sensitivity can be useful in helping to pick up typing errors at compile time.
But as for the two other points you made...
The second point is not *quite* as strong. You're right that it does enable you to use similar names in the way you describe, but I have to dispute the need to do that - I hope you comment your code well, because you're certainly not making it any easier to read with that sort of naming scheme.
And as for the third point... Hmph. If I ever catch anyone using a single-character variable name...! Grrrr. Don't do it. There's absolutely never ever any possible excuse for it (unless you are deliberately obfuscating your code). At least call it "counter" or something similar if you can't come up with anything better.
Another good point (that has been made elsewhere, I think) is that case sensitivity is a way of trying to enforce consistency in your naming schemes, to benefit programmers reading each others' code - they will know, for example, that all upper case names are declared in the code as static, whereas if it case sensitivity isn't enforced you may type a name in a different case in different places, leaving it unclear to the reader how it's declared without checking back to the header.
(Spudley Strikes Again!)
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