Who Needs Case-Sensitivity in Java? 434
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."
Uniformity... (Score:3, Funny)
Re:Uniformity... (Score:4, Insightful)
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.
Re:Uniformity... (Score:3, Interesting)
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 t
Re:Uniformity... (Score:3, Insightful)
History (Score:4, Funny)
Re:History (Score:2, Interesting)
The idea of eliminating case sensitivity seems appealing until you need it.
Re:History (Score:5, Interesting)
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"?
Re:History (Score:5, Insightful)
getDeviceName(customerId)
I for damn sure don't want to search for the same thing in DeviceServlet.java and be frustrated because it says:
GETDeviceNAME
ugh. At the most basic level, this is dumb. If I mistyped the name with incorrect capitalization, it *won't compile*! This is not a subtle error, it would be obvious! So it does not at all lead to errors.
Case sensitivity means I know a variable, method, whatever, is always going to "look" the same to me when I'm scanning the code or when I type a quick search into vi (/getDeviceName). I don't need my new intern who likes a different set of notation littering my code with GetDeviceName because the compiler lets him get away with it
I'll agree with you that having both ThisIsImportant and thisisimportant in a module and relying on case-insensitivity to differentiate is probably not a good idea, though...
Re:History (Score:5, Informative)
grep -i is your god.
Re:History (Score:4, Insightful)
For heaven's sake, if you mispelled on case in a program, 99% of the time you'll pick it up in the first compile - problem solved!! Sounds like poor programming discipline and laziness more than anything else.
Re:History (Score:5, Interesting)
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.
It enforces clean code (Score:4, Informative)
Re:It enforces clean code (Score:2, Insightful)
Re:It enforces clean code (Score:5, Funny)
Python strongly encourages it. :-)
Perhaps syntax errors should cause your monitor to explode. I think using deprecated modules already does.
Let me check....
Python 2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit (Intel)] on Your Mom
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> import fcntl B`LAST!!!!
AAAIIIGH! Mine EYES!
Aye.
Re:It enforces clean code (Score:2, Insightful)
Conventions matter as far as clean code, even at the level of case choices. Language choice doesn't help here, does it?
my reasons....... (Score:5, Insightful)
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.
Re:my reasons....... (Score:5, Insightful)
Because it makes naming conventions much easier without all sorts of silly prefixes. You'll come to appreciate the fact that, in Java, if a term looks like MyTerm you know it's a class name, if it looks like myTerm you know it's a variable or a method name (recognisable because it's followed by brackets, even when there are no arguments - something which I'm sure you'll be griping about too, right?), if it looks like MY_TERM you know it's a constant...
Because good programmers aren't bothered by such trifling matters?
Daniel
Because Java uses Unicode (Score:3, Insightful)
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
Re:my reasons....... (Score:5, Insightful)
But why a big list of reasons FOR case-insensitivity?
IMHO the question should be turned around to "Why should anyone want case-insensitivity in a language?" (since, as you say, it has to be put there and requires more work in the part of the compiler and/or the compiler writer).
Then it is up to those who want case-insensitivity to argue their case against the simplest implementation.
Re:my reasons....... (Score:2, Interesting)
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. E
Funny you should mention that ... (Score:2)
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.
Re:my reasons....... (Score:2)
So case sensitivity enforces your convention. (Though usually programmers have more sophisticated conventions). Otherwise, THISISAVARIABLE compiles. Since reading /debugging code is harder than writing it, it makes sense for the programming language to strictly require readable code.
Slower? There's just one more pass involved (an OR in the letters) which you parse anyways. I wo
Re:my reasons....... (Score:5, Insightful)
That's not ambiguity. Ambiguity is saying one thing which could mean several things; according to your assertion, case-sensitive languages have more than one way (Bar vs bar) to say the same thing.
English isn't case-insensitive, anyway. When you encounter a capital letter, it's telling you something (that it's the beginning of a sentence, or part of a title, or a proper noun,
There is a huge difference. In the "basic" Roman alphabet (with no accents or anything, as implemented in ASCII) there is a 1-to-1 mapping between upper and lower case; this isn't always true in general.
For instance, in German there is the "s-set" (which looks a lot like a lower-case beta), which is more or less interchangeable with the character pair "ss". It upper-cases to "SS" (i.e. there is no capital s-set). With that in mind, in a case insensitive Unicode-based language, how many of strasse, stra(s-set)e, STRASSE should be equivalent?
Once you've finished hard-coding your case comparison rules, what other equivalences are allowed? Is a-acute ("a" with an acute accent, which Slashcode doesn't seem to want to let me post) the same as "a", bearing in mind that both are conventionally upper-cased to A in French, and is the correct answer "if and only if the programmer is French"?
Being case-sensitive also lets you compare raw byte sequences rather than canonicalising everything, which is no big deal in ASCII (just AND all letters with 0x20) but is intricate and fiddly in Unicode (hence lots of code and memory for all the esoteric rules required).
On a related note, I think filesystems should also be case-sensitive (like Unix, and unlike Windows and usually Mac OS X); if you want a helpful "ignore small differences" algorithm, it should happen at the user interface level, and it should be possible to override it, like the way you can put double quotes round a non-.txt filename in Notepad to prevent it from appending ".txt".
Being able to have "Letter.doc" and "letter.doc" in the same directory seems to me to be no more confusing than being able to have "Letter (21 Jan).doc" and "Letter [21 Jan].doc", or even "a_b", and "a__b" (for greater confusion, replace the underscores with spaces, but that wouldn't display properly in Slashcode). It's inconsistent to be sensitive to one small variation, but ignore another, particularly when the main principle of working with computers is "say exactly what you mean".
(I dislike extension hiding for the same reason; "you can't have two files with the same name, except when they're different types of file"? What sort of a silly rule is that?)
Java (Score:5, Interesting)
Note that in Java case has by convention semantic significance, so that you can discern org.foo.Bar.bleh from org.foo.bar.Bleh.
Re:in Holland (Score:5, Interesting)
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.
Namespaces (Score:5, Informative)
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.
Re:Namespaces (Score:2, Funny)
Re:Namespaces (Score:2)
Daniel
Re:Namespaces (Score:2)
Daniel
OMG (Score:5, Funny)
Today I use modern languages including Visual Basic
Real programmers don't use (Visual) BASIC... at least not after puberty ! ;-)
Re:OMG (Score:2)
Re:OMG (Score:2)
I'd have to object, VB has it's uses.
If all you want to do is build a GUI for a database backend it's a heck of a lot faster and simpler to build it in VB.net than with Java or C.
Yes, I know it's used for "dumb" UI's and prototypes since you get something that you can see and "grab" very quickly, but doing big (> 10.000 lines of source) programs with VB would be insane, IMHO. After all, the "Visual" is followed by "BASIC" which still after all those years means "Beginners' All-purpose Symbolic
Re:OMG (Score:5, Insightful)
Some very powerful things have been done with visual basic, and the true test of a "Real Programmer" is doing those Powerful Things on time, underbudget, and in Good Working Condition regardless of the environment of choice for the application.
Notice my hideous but Meaning Laden usage of capitalization. While i don't believe that a capitalization scheme should be enforced by the compiler, i do appreciate having it as a tool to enforce coding standard schemes.
Smurfy,
-T
CasESEnsivity iS gOod. (Score:5, Insightful)
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.
Re:CasESEnsivity iS gOod. (Score:2)
local Actor actor;
However, it's case-insensitive and recognises from context whether you mean a class or a variable (classes and variables effectively have separate namespaces), so you can actually do
local Actor Actor;
and that'll still work.
It can be annoying when trying to write Unreal Tournament mods in x86 Linux (compiling under Wine, testing in the native version of UT), since a lot of the source files
readability (Score:5, Insightful)
For instance:
MySteadfastObject.doSomeReallyBizarreParsing()
instead of
mYSTEadfasoBJEct.DOSomerEAllybizaReparsiNG()
Emphasizing readability instead of easy-writing is (mostly) a Good Thing (TM).
Re:readability (Score:2)
In a case sensitive environment this:
MySteadFastObject.doSomeReallyBizarreParsing()
Would produce an error because you actually meant to type this:
MySteadfastObject.doSomeReallyBizarreParsing()
But your head got in the way and parsed "fast" as a separate word that should have it's own uppercase letter. The only proper reason for case sensitivity i
Re:readability (Score:2)
That's nice, but doesn't really have anything to do with the issue. You can do the second thing in a case sensitive language (but you have to be consistent with it), and you can do the first thing in a non-case sensitivie language.
I think the only plus for case sensitivity in Java is the Object object = new Object() meme - difference between the class and an instance. I doubt whether that is worth it.
On a related note, I also think case sensitivity in the Unix file system sucks.
Re:readability (Score:2)
Now you're mixing things. 8.3 has nothing to do with this.
Name me ONE instance where it was nice in Linux that the file system was case sensitive.
Re:readability (Score:2)
When given an open call for, say, "my document.txt", you have to match for all possible case permutations of that string. That's 2 ^ length of the string possibilities.
There are tricks you can pull to keep this faster (linear but five times slower than a straight comparison, or precompute some data for inconstant calculation loads), but the point remains that you end up with a bunch of weird and buggy macr
Re:readability (Score:2)
Java can also correct this with an editor! (Score:5, Informative)
Personally I prefer case sensitivity iN ALL LanGUagEs, inCludDinG jAVa bUT AlSo IN eNGlish.
Re:Java can also correct this with an editor! (Score:2)
I propose that Java also be made l33t-insensitive, so that, for example, foo = f00 = fo0 = phO0 = F0o and bar = b4R = B/\r = b@|2.
f()O F0o = new ph0O(b@|2)
Case-insensitive programming languages? Yuck. (Score:5, Informative)
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
Re:Case-insensitive programming languages? Yuck. (Score:2)
I program in both VB and PHP. One of each style. I also use Option Explicit in all my VB modules, which removes the default loose-casting variable types. (I am not aware that PHP has any such feature) This means I explicitly declare each variable with the case I want for readability. I then type
Re:Case-insensitive programming languages? Yuck. (Score:2)
Comparing PHP to VB is interesting since VB has a pretty IDE and you're doing PHP in Notepad! Write your VB in Notepad for a month and then call me.
Ironically, you just made an argument for me anyways. Your proble
Mistakes easier? (Score:5, Interesting)
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?
Re:Mistakes easier? (Score:4, Insightful)
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 set me thinking. The guy who posted the article would probably prefer Perl to Java. It is case sensitive, but will let him get away with his sloppy coding practices by simply creating a new variable every time it encounters one which only differentiates from another in case. Then once he's learnt the error of his ways, he'll either return to Java with a greater appreciation of it's reasonably strict syntax, or become a fan of "use strict;" ...
I remember reading the Jargon File entry on "discipline and bondage" programming languages, which was quite disparaging about them. I found myself in wholehearted disagreement with that attitude, as most programmers I work with need to have discipline imposed on them - coding standards, style checkers and peer review help, but the quality of C code seems to generally better than Perl or C++ simply because the language is much smaller and narrowly defined.
Chris
Re:Mistakes easier? (Score:2)
The sad thing is that the vast majority of coders seem to be sloppy, at least in a corporate environment. Staff turnover has been so high in the IT industry, that many people don't take pride in their work - it's the "I wont be around when it needs fixing or extending" mentality. While I'm not the most sophisticated programmer in the world, I put in the extra effort to ensure that my code is as clear and concise as possible. I don't comment my code extensively, just a brief description of a function or meth
SetSlower != SetsLower (Score:5, Insightful)
- 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.
Re:SetSlower != SetsLower (Score:2)
- SetSlower is a procedure that reduces the speed
- SetsLower is a function that gets a lower bound in a set of sets
I could argue that this is actually a disadvantage of case sensitivity, since it makes this sort of error-prone situation possible. Especially if they're in the same module so that this could be a problem, then a compiler error is just the clue you need that you should give them clearer names (like getLowerBoundInSets).
That is: Relying on case sensitivity for differentiating between funct
Conformance (Score:5, Informative)
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.
Re:Conformance (Score:2, Interesting)
So, request them to change it... (Score:3, Interesting)
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...
Easier to read (Score:3, Insightful)
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.
a cultural thing? (Score:2, Interesting)
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 o
Re:a cultural thing? (Score:2)
Re:a cultural thing? -- like in German (Score:2)
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.
Re:a cultural thing? -- like in German (Score:2)
Why is it ... (Score:2)
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!
intellectual inertia (Score:2)
Except (Score:2)
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.
Uhm.. (Score:2)
We need case sensitivity because the English language has two cases.
I mean 'R' and 'r' don't look the same do they?
Because.... (Score:2)
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 t
Case-sensitivity is useful (Score:2)
I hope someone will give a real reason later... (Score:2, Interesting)
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 en
Re:I hope someone will give a real reason later... (Score:3, Insightful)
Meaningful names are long to reduce ambiguity. It shouldn't be necessary to read the code to understand the intent of a variable or function.
Re:I hope someone will give a real reason later... (Score:2)
1. That's a Unicode Problem. As I said, that may be interesting for the data handed to the compiler, but not for the IDE.
If you're comfortable doing everything through your IDE, then fine. Me, I prefer to make quick and dirty hacks via a simple text editor. No fancy case-correction there.
2. VARPTR is a Variable Pointer. Why shouldn't it be necessary to look something up in the documentary if you don't know your language well?
I'm very thankful I'll never have to maintain any of your code that you mi
(d) counters (d) (Score:2)
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.
Re:I hope someone will give a real reason later... (Score:2, Informative)
Re:I hope someone will give a real reason later... (Score:2)
What's wrong with VARPTR? Is VariablePointer really better?
Yes. Obvously, it is clearer.
A post up top stated what I think is the best reason, which is to distiguish between class and object (their example):
Person person = new Person();
This is pretty common code for me. Without case sensitivity I would have to get quite awkward. Java strives for legibility and organization. Other languages strive for other things. Don't fault it for trying to meet its goals.
C does not assume ASCII machine platforms (Score:5, Insightful)
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.
Diversity (Score:2)
int stuff;
int Stuff;
int StUfF;
(Man, it must be early for me to think that's funny.)
eNGliSh (Score:2)
Re:eNGliSh (Score:2)
Silly Troll... (Score:2, Informative)
> 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-sensiti
All of the arguments in one post (Score:5, Interesting)
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
Uhh... readability? (Score:2)
iT IS ReAL pAIN iN THe aSS.
cODE is dIFfiCUlT eNOugH tO rEAd wIThouT coMPLIcatINg tHiNGs fURthEr.
One key example (Score:2)
Some languages use initial capitals to distinguish lexical classes (like O'caml), and this is another reason to have case sensitivity.
More one-letter Variables! (Score:5, Funny)
The answer is in the question... (Score:3, Interesting)
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 Insensitivity (Score:2)
why not have it both ways? (Score:2)
just make up a compiler directive or something that indicates whether to de-case-ify your code.
Learn another (natural) language and you'll know (Score:4, Insightful)
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?
English rules (Score:5, Funny)
I think you mean:
In English, the concept
(Sorry, couldn't resist...)
Relic (Score:2)
Being such a bare bones, close to the metal language, case sensitivit
Programs are data (Score:3, Interesting)
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.
CAPS-LOCK ON, FULL SPEED AHEAD (Score:3, Funny)
Who needs correct spelling in Spanish? (Score:3, Funny)
One Artgument for Case INsensitivity (Score:4, Interesting)
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.
Re:An argument for case-sensitivity (Score:5, Interesting)
Link to the original post [google.com]
...And that's why you should sign up for free hosting with aloofhosting.com [aloofhosting.com].
Re:An argument for case-sensitivity (Score:4, Insightful)
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
Re:An argument for case-sensitivity (Score:5, Insightful)
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.
Re:An argument for case-sensitivity (Score:3, Insightful)
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 re
Re:I was thinking the same thing... (Score:2, Informative)
Program with the capslock key on. Occasionally run your code through "tr 'a-z' 'A-Z' and diff that against your existing file, to resolve conflicts. Fix the translated file and work from that, and quit complaining about the fact that a language has features you don't use. There're plenty of languages that were developed on baudot tel
Re:We're not all idiots (Score:2)
Daniel
Re: Who Needs Case-Sensitivity in Java? (Score:2)
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 [sun.com].
Re: Who Needs Case-Sensitivity in Java? (Score:2)
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.
(
Re:a few things (Score:2)
I guess the real answer is that, for a user, it simply does not matter much whether a language is case sensitive or not. The differences are neglible. For an implementor case insensitivity probably makes things slightly harder, but not in a way that should require more work than putting a normalizeCase(identifier) he
Re:a few things (Score:2)