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."
I'm not a programmer, but I would imagine that case-sensitivity would help a great deal with the uniformity of the code.
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
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...
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.
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
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.
they should allow the use of subscripts, superscripts, and Greek letters too, to make the notation more powerful and more intuitive.
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 require strict naming conventions, of course, but people should use strict naming anyway.
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...
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.
> Without making this into a religious war, can someone make the argument
/home).)
> 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-sensitivity in their filesystems. (Personally, I dislike that and
think that should be optionally possible to turn it off in certain
directory trees (particularly,
Personally, I don't mind case-sensitivity in a language, generally. Perl
is very much case-sensitive, as is elisp, and neither has ever troubled me.
The only time case-sensitivity in a language has really bothered me is in
Inform -- but that was because of the incompatible _changes_ in the case
sensitivity from Inform5 to Inform6, which caused a lot of my code to break.
Now, that said, it is also possible for a language which is case-sensitive
to go far wrong in its use of case by being inconsistent in a way that will
leave you unsure which case is correct sometimes. For example, if a lot of
the ready-made modules/libraries/whatever that you use are not consistent
with one another in their use of case, that would be very bad. In elisp and
Perl, I have not generally found that to be the case. I can't speak for
Java; my attempts to learn Java have largely ended with "Ew, it's like C++".
Cut that out, or I will ship you to Norilsk in a box.
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
Ok, here's the solution for all the case-challenged intellects out there, who can't seem to grasp that the ability to use both cases does not imply the requirement to do so:
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 teletypes, so use one of them, if it's such a hardship.
We're using numbers to represent letters, and the only thing relating an uppercase character to its lowercase counterpart is the ascii translation table. If someone is using a DBCS input method for variable names, do you really think the compiler should anglicize the bytes? Or, perhaps you'd like the extra complexity of having to specify localization? Sure, it can be done, but why write around the preferences of fools?
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?
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.
Thus, case sensitivity is a Good Thing.
The perfect sig is a lot like silence, only louder
This is actually a problem with java ...
...
This is NOT possible in Windows NT
Some might argue that this is a problem with Windows, not Java.
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
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
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.
Consider this snippet of java code:
And yet you see TransactionRolledBackException propagating to a higher level. You have looked at the code and swear you are catching it. Oops, missed that upper case B.Arguments that you can do something like this:
are irrelevant. This is also perfectly legal in java:Case sensitivity does nothing to enforce preferred conventions, and actually enforces unreadable code.Would I like to read code that says System.arrayCopy(...), or Color.BLACK ? Sure I would, but that wouldn't compile. Case sensitivity enforces the wrong thing (literal consistency) rather than convention (conceptual consistency).
Would I like to rename that class which someone called subProductPanel to SubProductPanel? Sure I would, but that would involve changing the 15 classes that reference it, not to mention the file name, which would confuse CVS on windows clients terribly.
So I am stuck with my subProductPanel class name without more effort that it is worth to fix, because of case sensitivity. If everything was case insensitive, then I would be able to change it easily.
As for portability, case sensitive and case insensitive are incompatible and equally create portability problems. Windows having a case insensitive file system causes limitations in Java's portability because Java considers MyClass and myClass to be two separate names needing two separate files. Windows will not support that. So Java code that runs on Linux will not work on Windows, and vice-versa (think about code which reads from the file system).
Bottom line:
Case sensitivity creates an environment condusive to hard-to-find bugs because people aren't case sensitive. They may notice case when it is out of place, but not normally.(sOMEtHINgouToFplACE vs. somethingOutOfPlace will be noticed. Not, however someThingOutOfPlace or SomethingOutOfPlace and only programmers consider SOMETHINGOUTOFPLACE different).
A case sensitive environment enforces only the non-use of conventions. A case insensitive environment lets you use the convention even if the author of the API forgot to.
As for BasicSend vs. BasicsEnd, that is an argument to use something other than case to differentiate words, not just hoping that people notice the difference. Wouldn't Basic_Send and Basics_End be much better?
As for differences in how languages handle case insensitivity, String.toLowerCase() figures it out, so would the computer language. You establish rules and stick to them. Will a language which targets the English speaking get all other languages right (the way most speakers of that language would intuit)? Probably not. That doesn't mean that the target audience has to spend thousands of hours chasing down unnecessarily hard to find bugs.
Most programmers are male, Many are ADD, some are dsylexic. Most can type almsot as fast as they think. MY pinkie raNdomly pushes shift without being asked TO. ANd sometimes doesn't release it when asked to. I Alsso sometimese accidentally double letters. Case insensitivity with a case aware IDE allows me to focus on What the Foo I am doing with BAR without worring about which foo I baR. I tend to Trust my IDE to let me know during code review... before I complie that I didn't put those letters in the write order. I use a modified version of MS's Hugarian notation for variables so that clsFOO is different from szfoo and clsszfoo is something else entirely...
Food not Bombs is a nice platitude but it breaks down when you notice that the Bombees are usually well fed
ASCII has a relatively simple, consistent mapping from lower- to uppercase and vice versa. Letters all have a single upper-lower 1:1 pair, while all others are caseless and upper and lower are the same. It's a simple map.
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 coding conventions that make use of casing to make distinctions, but these conventions ride on top of the cultural conventions regarding which distinctions matter. (I don't want to get into the details, but what one man considers a single letter another might consider to be two, for example.)
You can avoid all of these thorny cultural disagreements by either limiting all identifiers to ASCII with its single equivalency map, or by just making the rule that identifiers are the same if and only if they are composed of the same sequence of characters and avoiding the issues of equivalency maps altogether. (Until you get to normalization, which is another can of worms....)
Since Java allows a much wider range of characters in its identifiers than the puny ASCII character set, it chose the second option: ignore equivalency maps and declare that "if it's not the same, it's different".
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
No you don't. The coding standards say that initial letters are capitalized for all words except the first. If you know that rule, there is nothing to remember for each function name. Unless of course, you're not following the coding standard, but I imagine that you are since your gripe is with that standard.
I'd rather be lucky than good.
IMHO it helps enforce coding consistency. Very helpful when writing and debugging code. If you wrote a program using hungarian notation and say use: //my java is rusty
String arrMyArray[5];
It is easier if case sensitivity won't let the lazy type arrmyarray[x]. It almost disappears in the text. When debugging and examining code, consistent variable names help you pick stuff out of the fray, visually, easier.
I am a huge fan of languages such as C and java which are fast, strongly typed, and rigidly enforce consistency in referencing variables.
Slop=hard to maintain.
Imagine reading a book where the case is all whacked. It wouldn't be as easy.
neilio
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