- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Oh hi there frist! Err...yeah...TRWTF is calling someone a moron, pretending to be "smart" by using primary, secondary & tertiary as prefixes on your e-mail variables and then giving up and using numeral suffixes because you're too fucking stupid to know the words "quaternary", "quinary" and "senary".
And all this in a comment on a WTF which boils down to stupidity and inconsistency in variable naming! Isn't it ironic? Don't ya think? You lovable little troll you! :x
Captcha: ingenium (The irony of the troll was so ingenium I nearly plotzed).
Admin
Actually there's a wonderful technical reason why case insensitivity just won't work in lots of modern languages.
Unicode.
Well that and the fact that there are valid programs out there that'd break, but back to the more interesting part. As soon as you allow unicode for variable characters (well I could live without it, so that would be an alternative) the conversion between lowercase and uppercase isn't unique any longer. In german for example the uppercase for ß is SS, so SS should be equivalent to ss as well as ß. Considering that unicode contains lots of languages, who all have their little quirks I'm pretty sure the whole undertaking will get quite fun to implement and confuse absolutely everyone.
Admin
Go on buddy, take a chance.....
visit 'Pen Island' www.penisland.com
How much does a blue pen cost? Waht about a red one?
While for words case may not be overly sensitive in language, something like variables that (admittedly by convention) can be many words run together can be very sensitive!!
Admin
Consider: 1,3,3,3,3,3,3,3,3,5 Median = 3 Mean = 3 Number of elements below median = 1 Number of elements above median element =1 50% # of elements = 5 (Number of elements)/2 > number of elements below median.
</Digression>Admin
Admin
Admin
Are VB fans pedantic about calling it VB or is vb (Vb, vB etc) ok (or is that OK) too....?
Hmmm, but case isn't important.....
Admin
Admin
Here, I'll show you how the web server could provide enough emulation of a case-sensitive file system to make it indistinguishable from the outside:
The 'canonical_case' function is pretty realistic; basically all case-insensitive file systems in current use are case-preserving and store the capitalization that the user originally gave a file.
If you'd like, I'm pretty sure I could write you one for Windows.
Not saying it's the most elegant solution, but it would work.
Actually I've thought for a while that it'd be an interesting idea to see an interactive compiler: one that, if it encounters an error, makes a guess as to what you meant and asks you. Think of what happens if you run a/ispell on a file, except that it does it during compilation for errors.IDEs have some of this, but I don't think I've one that gives you suggestions in the same way that, say, word processors do. (I believe Eclipse underlines spelling errors for you even in identifiers, which is pretty awesome.)
(Of course, I'm in no way saying that compilers should force you to use that mode.)
IMO, that's only a good reason to avoid case-insensitivity, not a debate ending one. Unicode defines (slightly locale-dependent) case-folding operations, so there's not as much ambiguity as it might initially appear. The main problems are that it makes whether some code compiles or not locale-dependent and that if the locale doesn't match the programmer, he may be confused.
Combined with the other reasons for case-sensitive names in programming languages, I think case-sensitivity is perfectly reasonable in that arena. However, I don't think the Unicode issues are enough to outweigh the arguments for my case-sensitive file system peeve.
(And the examples get even more fun than what you say: is é made with U+00E9 ('latin small letter E with acute') the same as an é made with U+0301 ('combining acute accent') followed by U+0065 ('latin small letter E')?)
Admin
Well, letters aren't really letters to a machine, they end up being compiled into binary. So perhaps we should just write in that? Oh wait, the code is meant for the programmer? Who'da thunk it?
Programming languages are made to be clearly understood and a way for a human to communicate to a machine what it wants done. So, with the rare exception of "I helped my Uncle Jack off a horse" and "I helped my Uncle jack off a horse" capitalisation means very little to a human. Also, to counter it with the clarity argument, "Talk" "talk" "TALK" "TaLk" TAlk" "taLK" while looking stupid, all mean the same thing to a human.
Admin
By convention? Ohhh so you are writing in FORTRAN.
Admin
Ahh yes, because obviously in a URL there is only one way to specify the character "i" So it is impossible to have two different URLs that reference the same file even for case sensitive OSs
Admin
If you've been brought up on the idea that programming languages should resemble natural language (one of the worst ideas in programming ever, IMO), I guess case-insensitivity makes more sense.
Admin
Admin
So it's not like MS came along and decided to "change" things after Unix was well-established or anything like that.
Addendum (2010-11-03 20:01):
Well, of course, we programmers actually tend to spell out our variable names fortunately, instead of using single-character glyphs for everything. One reason that "X is a set, x a point" is so prevalent in mathematics is because they resist notions like saying "p \in points" or stuff like that.If you open your world to multi-character identifiers, that both increases the number of available identifiers and makes it possible to show relations between them with more than just "this is lowercase and this is capital."
Finally, I think the example you choose is actually particularly bad, because there are plenty of situations (many people's handwriting) where the 'x/X' distinction can actually be very difficult to make out and you have to guess by context. Of course, that doesn't really apply in the world of computer text, but I do find it a little amusing.
Admin
Admin
A) I'm not sure you appreciate how complicated error handling in the compiler already is without spell-check type functionality (although allowing code to be corrected as the compiler encounters it does sound nice, sometimes the point where the problem is identified is well after where the problem occured - what if you mis-spelt the declaration?) B) Many IDE's highlight variables they don't know (and this is a good thing), but it doesn't (to me anyways) suggest case insensitivity is a good thing....
I'm quite happy for a compiler to assume that the person using it has some idea of what they are doing. Time and time again we seem to find issues when people try to cater for stupid users. The solution is educating users, not dumbing down applications - and I think the same applies here.
We see spectacular examples of how inefficient auto-generated code appears to be (because we work off simplified rules to do sometimes quite complex tasks), andf I would suggest that trying to guess what programmer's meant would be somewhat more complex again.
Already, given the articles (and, dare I say, comments) we see here programmers are lazy and lacking in knowledge. Trying to simplify the the task is the wrong approach - Educating the Programmer is the right approach.
Or we could just use robots to write our programs...you choose!
Admin
I woudl say Programming languages are made to find a blance between clear comprehensin by programmer's, and minimised risk of compiler's getting it wrong.
Perhaps we should ban capital letters in programs?
Admin
But if I call it vB they should still understand, right? Because how it was declared is not important...
Admin
Speaking of Unicode: any thoughts on whether
redWagon
and
redWagon
should be considered the same identifier?
Admin
Let me get this straight, so we increase the number of available identifiers by increasing the allowed length while decreasing the number available by insisting that case is irrelevant?
Programming is a science (branching from Math, I guess). As such consistency and precision (though not necessarily accuracy) is important. Scientists don't write "Thingammybob was red" and later "Thingummyjig didn't...." - and neither should programmers.
A previous poster alludes to the fact that Programming Languages developed in an attempt at readability. This may well be true, however to reduce the possibility of unexpected behaviour, a certain rigidness must be maintained. Thus, programming languages should sufficiently reduce machine code into something understandable by humans, while minimising any adverse affect (which is inherent once you start to guess at what the programmer meant - which is essentially what ignoring case is). Once you accept that 'red' and 'Red' are the same thing, do we then try phonetics as well? Does 'Read' fit in here? Should l33tspeak be translated too (those who argue the mind can work case out - the mind (for most people) can work out l33tspeak too).
Before reading this debate, I thought 'case sensitive is right, but if people want to do it differently who cares', but I've actually been convinced that people who advocate case insensitivity are, on the whole, nut-jobs!!
I like that my compiler trusts me! I like that it doesn't want to assume. I like that when it's unsure, it would rather fail so that I give it clear instructions.
People here often say that VB breeds bad programmers, I'm really starting to wonder whether bad programmers bred VB...
Admin
Regardless, the only real-life circumstances I can imagine where they would not understand you if you used mixed-case are situations so lacking in context that using the correct casing would produce similar results. Whether they may think you are lazy, an idiot, or a moron is a different question that I cannot answer.
Admin
sO YoU thINk hUManS haVE NO pRObLEm rEAding RanD0m CASe?
Would you want to read a long WTF if Alex wrote it using random casing like that? Doesn't it make it harder to read? Sure, you can read it...but it takes more effort, no?
Code needs to be readable not only by the compiler, but also by humans. When you use a consistent naming and capitalization convention you increase the human readability factor of your code. Using the example posted above: HWND hwnd; Not only does context tell you that HWND and hwnd are different, but Microsoft is fairly good at using consistent naming conventions, so once you get the feel for them, they become part of your reading skills.
If I saw some MFC code like this: PostMessage(hwnd,...) I know exactly what hwnd had better be. It's a variable of type HWND. I don't need to go look at the definition. But if I see this: PostMessage(HWND,..) By brain says WTF? Now I have to go look at the definition of HWND And if I see this: PostMessage(HwNd,...) I would run away, very, Very, VeRy, VERY fast.
Admin
And to reiterate, I'm not really advocating that programming languages should be case-insensitive. I'm just advocating that it's not at all unreasonable, as a language designer, to make that decision. One of my top couple favorite languages, Lisp, is more-or-less case-insensitive in almost all its dialects.
I do realize that making compilers produce readable error messages is very difficult; I have from time to time compiled a program with a different compiler to see if it produced a more helpful diagnostic. (I've also taught a compiler class, though admittedly I don't really know much about that particular aspect of it.) A general "did you mean this?" suggestion mechanism would probably be extraordinarily difficult. (Though Eclipse does suggest some things for some kinds of errors/warnings.)That said, I'm struggling to see how spell-checking would add much complexity to a compiler. There's probably limited places where the complier can emit a "I haven't seen this identifier before" error, and you'd just have to patch into each of them a mechanism to traverse the current symbol table and look for things that are close. Then just replace the current value with what the user said.
Oh, sure, I'll agree there. I just don't think that "the complier shouldn't look for spelling errors" isn't a very good argument for case-sensitivity.
I'm not a fan of this suggestion, but it is a little related to what Haskell does. You know all those coding standards like "variables start with a lowercase letter, types start with an uppercase letter", etc.? Haskell enforces some of them. An identifier starting with a lowercase letter is a function, variable, etc., and lexically speaking, cannot be a type.
Another potential compromise is this: the language is case-insensitive in the sense that you can't have a variable called "foo" and another called "Foo", but case-sensitive in the sense that you must use the same capitalization that you used in the declaration.
Again, I'm not particularly advocating any of these (though I do like a combination of those), just tossing ideas out there.
To some extent yes; I would argue that's exactly what is happening in languages that decide to go the case-insensitive route. Though I do think that the "there are other ways of indicating relations between objects" is more important than just the number of available identifiers.
No, of course they shouldn't. But that's rather a strawman, don't you think? Physicists don't exactly go around saying that the sentences "there are several types of quarks" and "there are several types of Quarks" mean entirely different things.
Does that include John McCarthy? Or is he an exception to your "on the whole"?
(Okay, that may not be quite fair... I can't say for sure that the original LISP was case-insensitive. In fact, I can't say for sure that it was even written on a machine that could produce lowercase letters. :-) But still, basically every Lisp dialect out there I know of except for one is mostly case-insensitive; are all those people nut-jobs?)
Admin
Early computers didn't do typesetting. This was primarily a limitation of the IO systems: for example, standard programming cards and teletypes did not have uppercase/lower case representations.
When computer systems (in particular, IO systems) did come out that could do upper case/lower case, their programmmers were so impressed with the damm cleverness of it all, they uSed UPPER case and lower CASE everywhere.
The character representation was designed so that a simple bit mask could make everything case-insensitive, but where's the fun in that?
TO BE FAIR, EVERYONE WAS SICK OF CASELESS PROGRAMMING, SO IT REALLY DID LOOK CLEVER AT FIRST.
Admin
Admin
Fourtunately, the Unicode people have already done it for you. Case mappings are provided in the Unicode database, at unicode.org
Admin
As we have seen some solutions for Perl, here's how to do in PHP:
Admin
Obviously it should be:
but for the purpose of this site it's rather:
Admin
Nice! That's an ingenious combination of memes.
Admin
I read the OP to be saying that people who promote the idea (of case insensitivity) as a good one are largely mad, rather than people who happen to use a language that is case insensitive are mad...({as you point out} there is little to suggest that LISP was ever meant to be case insensitive - or that the creator intended it that way - and frankly if he did so believing it was a good thing, then yes, he either didn't think it through or was mad {which most of us {?} mathematical types could be accused of being)
could be worng, but that's what it sounded like to me....
Admin
But there have been many dialects of Lisp created since then, and basically all are case-insensitive. That just means that there are even more people who have acted as language designers on the different dialects: are all of them mad? E.g. Guy Steele and Gary Sussman? (Actually, it's funny... I just remembered when I was writing this up that R6RS was changed to a case-sensitive reader.)
Admin
Dork man
Admin
Admin
And that's precisely why the unicode consortium developed normal forms: http://unicode.org/reports/tr15/
Admin
TRWTF is... how everybody confuses the email with the email address...
Admin
That, my friends, is TRWTF. You seem to understand the fact that a variable name is a unique identifier yet you don't seem to think it has to be unique. I fail to comprehend how any intelligent person could come to this conclusion.
Admin
Conclusion: if you can't get used to i as an indexer variable I don't see you'll ever get used to software development as a profession.
Admin
Admin
The poster was entirely aware of the contradiction you stated - the poster themself stated it very clearly: "with the rare exception of" You yourself never addressed this crucial argument of theirs (rarity), but just merrily moved on to argue the exact same point they already presented an argument against. Fail.
Of course we understand it. but no, iT reaLLy ISn't very relEVaNT in mOST caSes. In basic use, it's role is to provide visual structure to text (whether it does as good job at that is an entirely different issue - at least lojbanists would argue against). In some cases it's used as a simple way to provide EMPHASIS, and in some cases it's used to highLITE specific parts of words - which is in fact pretty similar use to general emphasis. Only in very rare cases, such as the one stated, does it actually affect the semantics - the meaning.The most common of these rare cases is capitalization as indication of a name ("I'm going to the Hills" vs. "I'm going to the hills"), another one would be "elevation" of an instance to more importance or higher stature - which is again sort of similar to emphasis but this time it's more of a semantic emphasis ("That's not just a dog, that, my friend, is a Dog!") The thing is, these are very rare cases, and I can't think of a single example where such as case would be at all relevant in a programming context.
However, I actually sort-of agree with the case-sensitive side of this argument (although I'd like the sort of case-sensitivity that still throws an error from trying to have any case-insensitively conflicting cases at the same time).
But please never do such an ugly, ugly misquotation of someone ever again. Geez.
Admin
...and the number one argument for case-sensitive names is (drum roll) VB uses case-insensitive names.
Admin
Admin
Recent studies have shown that humans can understand written English without many of the letters. For instance.
I wnt to te sprmket n stday nd bht a cbge.
which is missing over a third of its letters.
So by the logic that case sensitivity doesn't affect humans much, why not just abbreviate all variable names? I mean you can work it out from context can't you?
Regardless of our ability to cope without capitalisation, we're used to it. Say you're scanning over a document for the word Saturday, you're mostly looking for word shape (that's how I do it anyway) rather than the letters, and you'll probably miss saturday on first reading. It makes it easier to read even if it's not essential for comprehension. It also allows things like HWND hwnd. Nowadays the abbreviation HWND is a bit rubbish, but if you're a Windows coder it makes perfect sense. hwnd is, and always will be, an HWND. If you don't understand why that's clear and obvious (especially if you're using lots of methods that Intellisense pops up the parameter HWND hwnd for) then you really shouldn't be coding.
Admin
Although I'd try to avoid ever needing a piece of code that will loop through a bunch of variables to pick one of them, PHP can do the same as your perl script. Fun exercise though.
CAPTCHA: damnum
Admin
Admin
Admin
Admin
Fixed:
global $Email, $Email_Address, $email_address, $EmailAddress, $emailaddress, $EMailAddress $email = $Email or $Email_Address or $email_address or $EmailAddress or $emailaddress or $EMailAddress
Admin
Please make this a featured comment.
Admin
FEATURED COMMENT!