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
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.
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.
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!
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.
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?
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.
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.
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
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.
Case-insensitivity is probably the single most annoying thing with otherwise decent languages such as Scheme. In case-sensitive languages, errors in casing are usually catched by a compiler. With case-insensitive languages it's easy to make errors that are not catched, because the different looking identifiers are actually the same.
My .02 euros. YMMV.
Software should be free as in speech, but if we also get some free beer, all the better.
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