The Daily WTF: Curious Perversions in Information Technology

2010-11-04 Reply Admin

MOASUT:
Earp:
This would never have happened in VB...

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.....

I don't think you're allowed to be pedantic about anything computer related if you're a VB fan.

2010-11-04 Reply Admin

EvanED:
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.

That one was hard to figure out. Normally, what you write makes sense, and I couldn't make heads nor tails of this. Then it dawned on me, you took it for something it wasn't meant to be. And given the context of the thread, I can't even ridicule you for misunderstanding me, I can only blame myself for not being clear. Those were just examples of the common practice to indicate the domain an entity belongs to by case, they were not meant to illustrate the superiority of case-sensitive languages. In fact, I wasn't even arguing that case-sensitivity is objectively better, just mentioning that viewed from my background, it's the natural thing. (Of course, case-sensitive languages conform to my mode of thinking, which makes them objectively superior ;)

EvanED:
Addendum (2010-11-03 20:01):
Ouch!:
Depends on where you come from, I suppose. First, capitalisation has meaning in some natural languages. More importantly, with a mathematical background the idea that capitalisation shouldn't matter in formal languages seems bizarre. It's a centuries-old convention that X and x, F and f refer to different entities. Often capitalisation is used to indicate the domain an entity belongs to (x is a set, X a class; X is a set, x a point). If you've grown up with these conventions, case-sensitivity is so natural to you that the idea of case-insensitive programming languages seems fundamentally wrong.
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.
Well, of course, we programmers actually tend to spell out our variable names fortunately, instead of using single-character glyphs for everything.

When there are meaningful names. If you're writing generic combinators like

zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
zipWith f (x:xs) (y:ys) = f x y : zipWith f xs ys
zipWith _ _      _      = []

using long names only obfuscates because there are no meaningful names for entirely arbitrary parameters. Even if you're writing something less general, say

int gcd(int a, int b)

you call the parameters a and b (or i,k; x,y; ...) and be done with it.

EvanED:
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.

Yes. But why do mathematicians resist such notions? Maybe because making case carry meaning leads to concise and clear formulae and works extremely well, despite people's poor handwriting?

EvanED:
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."

Yup. Nevertheless, using case to indicate the "kind" of an identifier greatly facilitates following the relations.

Jaime · 2010-11-04 Reply Admin

TRWTF:
Mason Wheeler:
wtf:
Mason Wheeler:

Case sensitivity was allowed on C, like so many of its other misfeatures, simply because it's easier to implement. Case sensitivity makes for simpler string comparisons and you don't have to store both original and allcaps versions of all the identifiers in your symbol table for proper error/warning reporting. And it remains in other languages mostly because of cargo-cult language design. (That's the way it is in C, so it must be good, right?)

The trouble with this post is I can't tell whether the guy is serious, in which case it's hilarious, or whether he's trying to make a joke, in which case it's not.

I'm absolutely serious, TYVM. Case sensitivity is a huge mess that allows for all sorts of ugly abuses. Whenever I see someone writing something in C like "HWND hwnd;" I wanna throttle them. With the exception of a few proper nouns that are also normal concepts, a word means the same thing no matter how we capitalize it, so why shouldn't an identifier written as a word?
An identifier, by its very nature, must uniquely identify something. "MYID" and "myid" are two completely different words composed of completely different char codes, yet you want these completely different identifiers to resolves to the SAME variable?

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.

It's interesting that you used that exact wording. {C758AC4D-E654-410a-9B03-85FC82F493C2} and {c758ac4d-e654-410a-9b03-85fc82f493c2} are both the same unique identifier (literally), yet they can be represented in different cases without ambiguity.

So..... If a library is written on an IBM mainframe and the source code is encoded in EBCDIC, then the source is compiled to a Java class, then the class file is copied to a Linux computer, do you have to save your Linux source code encoded in EBCDIC to properly call the functions?

DaveK · 2010-11-04 Reply Admin

Jaime:
TRWTF:
...unique identifier...
It's interesting that you used that exact wording. {C758AC4D-E654-410a-9B03-85FC82F493C2} and {c758ac4d-e654-410a-9b03-85fc82f493c2} are both the same unique identifier (literally), yet they can be represented in different cases without ambiguity.

Well, if you want to be *really* pedantic, neither of those are actually (g/u)UIDs at all. They are ascii text encodings of a UID, which is in fact a 128-bit binary integer (or a struct containing a word, two shorts, and a long long, or perhaps a struct containing a word, three shorts and a 12-byte array, depending on your POV). There are multiple encodings of the same UID, but the actual UIDs themselves are entirely unique.

Satanicpuppy · 2010-11-04 Reply Admin

no name:
Kempeth:
Now if we could only specify the variable name in RegEx that would solve our problems...

That would be an awesome language feature - just imagine the potential for abuse...

You can kinda do that in perl using groups. It'll automatically put the parts of the search string that are within () into variables named $1, $2, $3, etc. Couple that with the magic variable ($_) and people start bleeding from the ears.

2010-11-04 Reply Admin

Can I use these characters in .NET?

ℂℍℕℙℚℝℤ

They are awesome!

EvanED · 2010-11-04 Reply Admin

TRWTF:
An identifier, by its very nature, must uniquely identify something. "MYID" and "myid" are two completely different words composed of completely different char codes, yet you want these completely different identifiers to resolves to the SAME variable?

It's obvious that they are completely different character codes, but why are they completely different words

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.

No, TRWTF is your doublespeak: As you say, "An identifier must uniquely identify something." But only in one direction: if I say foo it must be clear what object I'm talking about. But there's not really any harm from allowing multiple strings to refer to the same object. Or at least you take as some fundamental assumption (that you don't support) that there is.

I'll get back to the other replies some other time.

2010-11-04 Reply Admin

Jaime:
TRWTF:
An identifier, by its very nature, must uniquely identify something. "MYID" and "myid" are two completely different words composed of completely different char codes, yet you want these completely different identifiers to resolves to the SAME variable?
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.
It's interesting that you used that exact wording. {C758AC4D-E654-410a-9B03-85FC82F493C2} and {c758ac4d-e654-410a-9b03-85fc82f493c2} are both the same unique identifier (literally), yet they can be represented in different cases without ambiguity.

So..... If a library is written on an IBM mainframe and the source code is encoded in EBCDIC, then the source is compiled to a Java class, then the class file is copied to a Linux computer, do you have to save your Linux source code encoded in EBCDIC to properly call the functions?

Ha ha, well done Jaime, you win! I knew some moron would try to argue that GUIDs contradict this rule and from previous experience I fully expected it to be you!!

OK, here we go then: words consist of alphabetic characters, GUIDs consist of hexadecimal characters. Hopefully you see already where you screwed up but allow me to continue for you. Alphabetic characters draw a distinction between upper and lower case; it is relevant to their meaning and indeed upper and lower case characters have physically different char codes - they are fundamentally different characters. However, hexadecimal characters draw no such distiction - "f" is exactly the same character in hex as "F". In fact, forget that they're even letters because that is completely arbitrary - hex characters could be represented by your favorite 16 pop stars if you want them to, and there is no such thing as an uppercase or lowercase pop star.

Thanks for playing, it's dipshits like you that make this place so much fun! But seriously, playtime's over so get back to your VB, boy.

2010-11-04 Reply Admin

Here is an argument. It forces the programmer to use the same capitalizations whenever a name is used. Thus information that may be conveyed through case, such as what kind of thing the name represents (whether it be a variable, function, macro, or template parameter), or the starts of words when using camel case, will be visible wherever that name appears.

So force case to be the same, but don't allow two variable to differ only by case. i.e. If $iCnt is used, don't allow $icnt to be used.

Jaime · 2010-11-04 Reply Admin

TRWTF:
However, hexadecimal characters draw no such distiction - "f" is exactly the same character in hex as "F".

So, it's fine that "f" and "F" are treated as the same in the representation of a hexadecimal number, because you say so. But, it is not fine that "f" and "F" are treated the same in the representation of a variable name, once again, because you say so.

What about my EBCDIC comment? In this case, "F" and "F" may not even be the same thing. If you define the identity of an alphabetic character by it's numeric representation, then they must be different.

2010-11-04 Reply Admin

Jaime:
TRWTF:
However, hexadecimal characters draw no such distiction - "f" is exactly the same character in hex as "F".
So, it's fine that "f" and "F" are treated as the same in the representation of a hexadecimal number, because you say so. But, it is not fine that "f" and "F" are treated the same in the representation of a variable name, once again, because you say so.

You don't do much with hex, do you?

2010-11-04 Reply Admin

Jaime:
TRWTF:
However, hexadecimal characters draw no such distiction - "f" is exactly the same character in hex as "F".
So, it's fine that "f" and "F" are treated as the same in the representation of a hexadecimal number, because you say so. But, it is not fine that "f" and "F" are treated the same in the representation of a variable name, once again, because you say so.

Sorry but you can't argue away your fundamental misunderstanding of hex. "F" and "f" are not the same character "because I say so", they are the same character by definition. In written language, "f" and "F" are not different "becasue I say so", once again they are different by definition. The problem appears to be that you don't understand the definition. Try a dictionary.

EvanED · 2010-11-04 Reply Admin

Ouch!:
That one was hard to figure out. Normally, what you write makes sense, and I couldn't make heads nor tails of this. Then it dawned on me, you took it for something it wasn't meant to be. And given the context of the thread, I can't even ridicule you for misunderstanding me, I can only blame myself for not being clear. Those were just examples of the common practice to indicate the domain an entity belongs to by case, they were not meant to illustrate the superiority of case-sensitive languages.

Fair enough.

When there are meaningful names. If you're writing generic combinators like
zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
zipWith f (x:xs) (y:ys) = f x y : zipWith f xs ys
zipWith _ _      _      = []
using long names only obfuscates because there are no meaningful names for entirely arbitrary parameters.

Sure: note that you didn't write

zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
zipWith f (x:X) (y:Y) = f x y : zipWith f X Y
zipWith _ _ _ = []

(Why? Well, partly because Haskell won't let you, but mostly because xs is so ingrained in that programming mindset. You'd see x::xs and not x::X in ML too even though the latter would (I think) be legal.)

Yup. Nevertheless, using case to indicate the "kind" of an identifier greatly facilitates following the relations.

We definitely agree on the first point; I am sympathetic to the second but I'm not sure how much it helps. (E.g. I may disagree on the "greatly.")

TRWTF:
Alphabetic characters draw a distinction between upper and lower case; it is relevant to their meaning...

So what's the meaning of q? What about Q? (Don't answer this yet; it's more prep for what comes next.)

However, hexadecimal characters draw no such distiction - "f" is exactly the same character in hex as "F".

Ah, but see? You're not comparing like-to-like.

In the case of hex digits, what you're saying is that the meaning of character code 102 (f) is the same as the meaning of character code 70 (F) in the context of interpreting hex (both mean "15"). That's plenty fair enough.

But then when talking about the alphabet, you don't allow for such a translation function. I could give you one that behaves quite reasonably: the meaning of character code 102 and the meaning of character code 70 are both the letter 'a'. Why do I have to keep them distinct?

IMO your argument boils down to "f and F are different because they mean different things" but you don't ever justify why that's the case.

To reiterate other posts, in English at least, it's almost never the case that capitalization changes meaning, just correctness according to the prescribed rules of English. The analogous thing to do in a programming language would be to make it case-sensitive but require that all identifiers follow a particular case. Of the languages I know, only Haskell comes anywhere close to doing this.

TRWTF:
In written language, "f" and "F" are not different "becasue I say so", once again they are different by definition. The problem appears to be that you don't understand the definition. Try a dictionary.

OK. Here's dictionary.com's definitions of f and F.

Oh, would you look at that! You get the same page for both.

Addendum (2010-11-04 13:31): And just to clarify, not only do you get the same page, but the only case-specific definitions don't apply when 'f' is used in a larger word. (Not that you can exactly say that the case-unspecific versions do apply...)

Much more clear is the fact that the dictionary (both dictionary.com and merriam-webster.com) consider "forum" and "Forum" to be the same word.

Jaime · 2010-11-04 Reply Admin

Jim Moran:
Jaime:
TRWTF:
However, hexadecimal characters draw no such distiction - "f" is exactly the same character in hex as "F".
So, it's fine that "f" and "F" are treated as the same in the representation of a hexadecimal number, because you say so. But, it is not fine that "f" and "F" are treated the same in the representation of a variable name, once again, because you say so.

You don't do much with hex, do you?

Yes, I do. The fact the I said "because you said so" and the entire industry accepts either case are not contradictions. This isn't about whether real tools accept mixed case, this is about whether it's "OK" to accept mixed case. After all, most of this discussion of variable case sensitivity seems to be conducted as if case insensitive languages don't exist.

2010-11-04 Reply Admin

EvanED:
TRWTF:
In written language, "f" and "F" are not different "becasue I say so", once again they are different by definition. The problem appears to be that you don't understand the definition. Try a dictionary.
OK. Here's dictionary.com's definitions of f and F.
Oh, would you look at that! You get the same page for both.

I think it is obvious to everyone but the highest order of retard that I meant the respective definitions of hexadecimal and alphabetic characters. Hex defines that "F" is the same as "f", whereas the standardised alphabet defines "f" to be a lowercase (and therefore different) form of "F". Seriously, did I have to explain that to you? You actually went out and got a dictionary definition for a letter and thought you were proving some point? What kind of idiot are you? I thought Jaime was dumb but I never anticipated finding such a well matched contender for him in an otherwise intelligent forum.

EvanED · 2010-11-04 Reply Admin

TRWTF:
...whereas the standardised alphabet defines "f" to be a lowercase (and therefore different) form of "F".

It's a different form, but I'm far from convinced that it has a significantly different meaning.

But OK then. Go ahead and explain the difference in meaning between, say, "bottle" and "Bottle".

Jaime · 2010-11-04 Reply Admin

TRWTF:
Jaime:
TRWTF:
However, hexadecimal characters draw no such distiction - "f" is exactly the same character in hex as "F".
So, it's fine that "f" and "F" are treated as the same in the representation of a hexadecimal number, because you say so. But, it is not fine that "f" and "F" are treated the same in the representation of a variable name, once again, because you say so.
Sorry but you can't argue away your fundamental misunderstanding of hex. "F" and "f" are not the same character "because I say so", they are the same character by definition. In written language, "f" and "F" are not different "becasue I say so", once again they are different by definition. The problem appears to be that you don't understand the definition. Try a dictionary.

But then F (ASCII hex code 47), F (EBCDIC hex code C9), and F (Unicode hex sequence 0047) are all different. "F" is "f" when the rules say it is and "F" is not "F" when the rules says it is not. The standard hex rules say they are the same. The standard variable naming rules say........ well they don't agree. You can't simply assert out of the blue that a given set of equivalence rules are right and another set are wrong, all you can do is argue the strengths and weaknesses of each in a given context.

2010-11-04 Reply Admin

EvanED:
TRWTF:
...whereas the standardised alphabet defines "f" to be a lowercase (and therefore different) form of "F".

It's a different form, but I'm far from convinced that it has a significantly different meaning.

But OK then. Go ahead and explain the difference in meaning between, say, "bottle" and "Bottle".

Absolute childs play:

pubic void ProveAMoronWrong()
{
  bool isTheSame = ("bottle" == "Bottle");
  Console.Write("Is 'bottle' the same as 'Bottle': " + isTheSame.ToString());
}

I'm sure you can see where this is going but just in case, the output of calling this method is:

Is 'bottle' the same as 'Bottle': False

You might be asking why this prints false (if you really are as dumb as you seem). Well, it might be something to do with the fact that they consist of different characters. That makes them different. I really can't dumb this down any further for you.

Jaime · 2010-11-04 Reply Admin

TRWTF:
EvanED:
TRWTF:
...whereas the standardised alphabet defines "f" to be a lowercase (and therefore different) form of "F".

It's a different form, but I'm far from convinced that it has a significantly different meaning.

But OK then. Go ahead and explain the difference in meaning between, say, "bottle" and "Bottle".
Absolute childs play:
pubic void ProveAMoronWrong()
{
  bool isTheSame = ("bottle" == "Bottle");
  Console.Write("Is 'bottle' the same as 'Bottle': " + isTheSame.ToString());
}
I'm sure you can see where this is going but just in case, the output of calling this method is:
Is 'bottle' the same as 'Bottle': False
You might be asking why this prints false (if you really are as dumb as you seem). Well, it might be something to do with the fact that they consist of different characters. That makes them different. I really can't dumb this down any further for you.

Try it with Unicode characters 212B and 00C5. Proper implementations will consider them equivalent.

2010-11-04 Reply Admin

Anonymous:
Indigo:
Great job of completely quoting someone!
The poster already presented an argument against Fail.

Please do such of someone again.
Thanks for your support, I did rather assume that most intelligent folks would agree with me.

... Oh my god are you completely stupid! You totally misquoted me there! "do such of someone" - oh please, like I would ever use lousy grammar like that!

Dwedit · 2010-11-04 Reply Admin

This is why programming languages have Reflection. Look for all variables which contain the case insensitive string "mail" and begin with the letter E, and take the longest one.

2010-11-04 Reply Admin

EvanED:
TRWTF:
...whereas the standardised alphabet defines "f" to be a lowercase (and therefore different) form of "F".

It's a different form, but I'm far from convinced that it has a significantly different meaning.

But OK then. Go ahead and explain the difference in meaning between, say, "bottle" and "Bottle".

One's unambiguously a container for liquids, and the other's either a container for liquids at the start of a new context creation, or all or part of the identifier for a sapient singleton. In English, at least.

Why anyone would name a creature "Bottle", though, is a much more difficult question; still, there's at least one being named "Blanket" that I'm sure we all know (about), several "Rainbow"s, and an "Apple" or "Moonbeam" or two.

Personally, I adore the German method of proper casing types...er, nouns. Perhaps you might recognize such overlay constructs as casing by the term "meta-data"; meta-data, as you no doubt know, and whose utility you hopefully understand, provides immediate, explicit context that is otherwise lacking or must be painstakingly built through backreferences or control trees.

Ranting against context and for a lack of discipline--in this profession, no less--is, at the very least... odd.

0_o

2010-11-04 Reply Admin

Indigo:
I helped my Uncle jack off a horse.
Whoa, [...]!

I see what you did there....

DaveK · 2010-11-04 Reply Admin

Indigo:
Anonymous:
Indigo:
Great job of completely quoting someone!
The poster already presented an argument against Fail.

Please do such of someone again.
Thanks for your support, I did rather assume that most intelligent folks would agree with me.
... Oh my stupid! You totally quoted me there! "do such of someone" - I would use lousy grammar like that!

Beg pardon?

2010-11-04 Reply Admin

Ben:
And that's precisely why the unicode consortium developed normal forms: http://unicode.org/reports/tr15/

Good to know - not my area of expertise after all. Also they've specified lots of rules for case folding, which should at least from a technical point of view fix unambiguity. There are even papers about exactly that problem.. http://www.unicode.org/reports/tr31/

But I still don't see how handling e.g. strasse and straße as the same identifier won't lead to at least some confusion. Although at least in germany german identifiers or comments are not common anyhow - don't think I've ever seen something like that (japanese on the other hand like to do it, ah I see it as training ;) )

2010-11-04 Reply Admin

Joops:
visit 'Pen Island' www.penisland.com

Strange enough, but:

www.penisland.net:
Welcome to Pen Island, the best place to get custom made pens on the internet! (...) You're also invited to contact our CEO, Josh Simoneau, directly at [email protected].

EvanED:
But still, basically every Lisp dialect out there I know of except for one is mostly case-insensitive

So may i ask you to tell us which one the exception is?

I guess Clojure is for obvious reasons; but you might have another in mind?

Ouch!:
When there are meaningful names. If you're writing generic combinators like
zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
zipWith f (x:xs) (y:ys) = f x y : zipWith f xs ys
zipWith _ _      _      = []

... then i assume you are a fan of Pointless Programming! (look it up in google, Akismet didn't like the link to wikipedia.)

EvanED:
But OK then. Go ahead and explain the difference in meaning between, say, "bottle" and "Bottle".

German sayings: "Bier soll man in Maßen trinken!" -> You shall drink beer in moderation. "BIER SOLL MAN IN MASSEN TRINKEN!" -> Drink beer in huge quantities!

But of course correct is: "Bier soll man in einer Maß drinken!" -> Drink your beer in a stein!

Dude:
Can I use these characters in .NET?
ℂℍℕℙℚℝℤ

They are awesome!

Indeed modern languages support Unicode-characters in identifiers: http://www.scala-lang.org/node/5818

CAPTCHA: incassum - shouldn't that be incbuttum?

2010-11-04 Reply Admin

Design Pattern:
Ouch!:
When there are meaningful names. If you're writing generic combinators like
zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
zipWith f (x:xs) (y:ys) = f x y : zipWith f xs ys
zipWith _ _      _      = []
... then i assume you are a fan of Pointless Programming! (look it up in google, Akismet didn't like the link to wikipedia.)

Within reason. You won't find me flinging round stuff like

(`ap` (flip . flip id)) . ((flip . (((.) . ap) .)) .) . (. ((. flip id) . (.))) . (.). (.)

in earnest ;)

EvanED:
But OK then. Go ahead and explain the difference in meaning between, say, "bottle" and "Bottle".
German sayings: "Bier soll man in Maßen trinken!" -> You shall drink beer in moderation. "BIER SOLL MAN IN MASSEN TRINKEN!" -> Drink beer in huge quantities!

Nietzsche didn't have that problem, he wrote "Maasse" for the one, "Masse" for the other.

But of course correct is: "Bier soll man in einer Maß drinken!" -> Drink your beer in a stein!

Igitt! Am Ende etwa noch Weizen oder was? Export oder Pils, alles andere ist Pferdepisse. Und Bier trinkt man aus der Buddel, so und nich anners geiht dat.

drfreak · 2010-11-04 Reply Admin

<blink>TRWTF is the fact that converting both sides of the equation ToUpper() or ToLower() is as easy as writing a blink tag no modern browser supports.</blink>

2010-11-04 Reply Admin

Joops:
The less a compiler (or parser) has to work out for itself, the less chance you have of introducing a unintended subtleties. When I write code (or a document, for that matter) I mean exactly what I say (auto-correct sux too). If I have used 'x=0;' somewhere, and 'X=17;' somewhere else, I like the compiler to fail - it cannot (and should not) be certain that I was referring to the same x. Insisting on standards may be a pain in the ass, but it does create more readable programs (and I think better programmers).

If that were the genuine argument, then compilers would insist on case-sensitivity, but disallow identifiers that differ only by case. In fact, that would probably be the ideal.

The reason it exists, however, is because it was easier and quicker to implement when K&R developed C. And seems to have persisted purely because of C.

But case-sensitive identifiers are nearly as WTF-y as the Unix case-sensitive filesystem, which is just embarrasing.

EvanED · 2010-11-04 Reply Admin

TRWTF:
EvanED:
But OK then. Go ahead and explain the difference in meaning between, say, "bottle" and "Bottle".
Absolute childs play:
pubic void ProveAMoronWrong()
{
  bool isTheSame = ("bottle" == "Bottle");
  Console.Write("Is 'bottle' the same as 'Bottle': " + isTheSame.ToString());
}
I'm sure you can see where this is going but just in case, the output of calling this method is:
Is 'bottle' the same as 'Bottle': False
You might be asking why this prints false (if you really are as dumb as you seem). Well, it might be something to do with the fact that they consist of different characters. That makes them different. I really can't dumb this down any further for you.

I'm sorry, I didn't realize that the == operator on strings took into consideration the linguistic meaning of the words. Clearly I should go back to my C# books.

Less flippantly, I can almost as easily (I did have to type a couple words into Google and click a link) write a version that will reasonably print true. You still have to justify why you choose that version of string equality. "Programming languages should be case-sensitive because they do case-sensitive string comparisons." Wow, that's revelatory.

quisling:
One's unambiguously a container for liquids, and the other's either a container for liquids at the start of a new context creation, or all or part of the identifier for a sapient singleton. In English, at least.

And that's about the only way you can answer that question. But it presents a problem: there's not really an equivalent to that distinction in programming languages. In a programming language, essentially every name is proper. Now, there are certainly distinctions between different types of identifiers in programming languages -- most particularly types and non-types -- but that's not what case distinguishes. In fact, when typing this out, I finally clarified in my mind what the difference actually is between programming languages and natural languages:

When case matters in natural languages (at least English) it's almost always because only one case is correct. In the practically-rare case that a change in case actually changes the meaning (i.e. both are correct and the two cases have two different referents), it's because the language itself defines that an initial capital means a proper noun.
However, in a programming language (except Haskell), no case is considered more or less correct by the rules of the language. Furthermore, when case only distinguishes between two different referents, the rules of the language again don't specify any kind of context for them.

If you had a programming language that was case-sensitive but only permitted certain spellings in certain contexts (pick your favorite standard, e.g. the compiler itself enforced a lowerCamelCase for variables and UpperCamelCase for types), that would be pretty close to the sense that English is case-sensitive. But what programming languages do now... I think basically has no relation to what English does.

Design Pattern:
EvanED:
But still, basically every Lisp dialect out there I know of except for one is mostly case-insensitive
So may i ask you to tell us which one the exception is?
I guess Clojure is for obvious reasons; but you might have another in mind?

So I didn't know about Clojure; I was thinking of Guile. (And of course I already mentioned that you have to revise that up by one because of standard R6RS.)

2010-11-04 Reply Admin

TRWTF:
EvanED:
TRWTF:
In written language, "f" and "F" are not different "becasue I say so", once again they are different by definition. The problem appears to be that you don't understand the definition. Try a dictionary.
OK. Here's dictionary.com's definitions of f and F.
Oh, would you look at that! You get the same page for both.
I think it is obvious to everyone but the highest order of retard that I meant the respective definitions of hexadecimal and alphabetic characters. Hex defines that "F" is the same as "f", whereas the standardised alphabet defines "f" to be a lowercase (and therefore different) form of "F". Seriously, did I have to explain that to you? You actually went out and got a dictionary definition for a letter and thought you were proving some point? What kind of idiot are you? I thought Jaime was dumb but I never anticipated finding such a well matched contender for him in an otherwise intelligent forum.

Well, one case I can think of is:

"The internet is down" vs. "The Internet is down"; Capital I Internet would be the global TCP/IP network; vs. a corporate wan scale network for the corporation you're in.

or "doctor who" vs. "Doctor Who"; capitalization can distinguish between a class, and a widely known specific instance that has no other name.

"The president picked up the phone." (and ordered lunch) vs "The President picked up The Phone." (and ordered a nuclear strike)

EvanED · 2010-11-05 Reply Admin

John Muller:
Well, one case I can think of is:
"The internet is down" vs. "The Internet is down"; Capital I Internet would be the global TCP/IP network; vs. a corporate wan scale network for the corporation you're in.

or "doctor who" vs. "Doctor Who"; capitalization can distinguish between a class, and a widely known specific instance that has no other name.

"The president picked up the phone." (and ordered lunch) vs "The President picked up The Phone." (and ordered a nuclear strike)

The fact that there are a few counterexamples (cf. Uncle Jack) doesn't diminish the fact that capitalization is pretty meaningless almost all the time.

In any other conversation, if I wrote "thE mOOn laNDINgs WerE FAKeD" I can almost guarantee most people would consider the difference in meaning between that and "the moon landings were faked" to be of roughly the same measure as my grammatical or critical thinking skills.

2010-11-05 Reply Admin

who HAS had to do something like this? I haven't.

gladly, the languages that i use normally don't even allow that to happen.

2010-11-05 Reply Admin

John Muller:
TRWTF:
EvanED:
TRWTF:
In written language, "f" and "F" are not different "becasue I say so", once again they are different by definition. The problem appears to be that you don't understand the definition. Try a dictionary.
OK. Here's dictionary.com's definitions of f and F.
Oh, would you look at that! You get the same page for both.
I think it is obvious to everyone but the highest order of retard that I meant the respective definitions of hexadecimal and alphabetic characters. Hex defines that "F" is the same as "f", whereas the standardised alphabet defines "f" to be a lowercase (and therefore different) form of "F". Seriously, did I have to explain that to you? You actually went out and got a dictionary definition for a letter and thought you were proving some point? What kind of idiot are you? I thought Jaime was dumb but I never anticipated finding such a well matched contender for him in an otherwise intelligent forum.

Well, one case I can think of is:

"The internet is down" vs. "The Internet is down"; Capital I Internet would be the global TCP/IP network; vs. a corporate wan scale network for the corporation you're in.

or "doctor who" vs. "Doctor Who"; capitalization can distinguish between a class, and a widely known specific instance that has no other name.

"The president picked up the phone." (and ordered lunch) vs "The President picked up The Phone." (and ordered a nuclear strike)

Small "l" liberal? Although this probably doesn't work in the US, where liberal is widely used, somewhat paradoxically, as a four letter word.

2010-11-05 Reply Admin

As case is a typographical finesse, bold, italics and character size should also carry meaning for sensitive languages.

2010-11-05 Reply Admin

EvanED:

Design Pattern:
I guess Clojure is for obvious reasons; but you might have another in mind?
So I didn't know about Clojure; I was thinking of Guile. (And of course I already mentioned that you have to revise that up by one because of standard R6RS.)

Just as a confirmation: Clojure is indeed case-sensitive: http://clojure.org/lisps

2010-11-05 Reply Admin

DaveK:
Indigo:
Anonymous:
Indigo:
Great job of completely quoting someone!
The poster already presented an argument against Fail.

Please do such of someone again.
Thanks for your support, I did rather assume that most intelligent folks would agree with me.
... Oh my stupid! You totally quoted me there! "do such of someone" - I would use lousy grammar like that!

Beg pardon?

He said he often uses lousy grammar but let's be honest, we already knew that. Keep working on it Indigo and one day you may be able to write like an intelligent human being. And even though you can barely string a sentence together I'm still grateful for your continuing support.

2010-11-05 Reply Admin

Bob:
no name:
Kempeth:
Now if we could only specify the variable name in RegEx that would solve our problems...

That would be an awesome language feature - just imagine the potential for abuse...

function set_var($regex, $value) { foreach(preg_grep($regex, array_keys(get_defined_vars())) as $field) $$field=$value; }

function get_var($regex) { return array_intersect_key($x=get_defined_vars(), array_fill_keys(preg_grep($regex, array_keys($x)), ")); // TODO: Probably best to randomly grab one value }

TRWTF is PHP and varible variables.

2010-11-05 Reply Admin

I use CamelCase variables, you case-insensitive clods!

2010-11-05 Reply Admin

EvanED:
John Muller:
Well, one case I can think of is:
"The internet is down" vs. "The Internet is down"; Capital I Internet would be the global TCP/IP network; vs. a corporate wan scale network for the corporation you're in.

or "doctor who" vs. "Doctor Who"; capitalization can distinguish between a class, and a widely known specific instance that has no other name.

"The president picked up the phone." (and ordered lunch) vs "The President picked up The Phone." (and ordered a nuclear strike)
The fact that there are a few counterexamples (cf. Uncle Jack) doesn't diminish the fact that capitalization is pretty meaningless almost all the time.

In any other conversation, if I wrote "thE mOOn laNDINgs WerE FAKeD" I can almost guarantee most people would consider the difference in meaning between that and "the moon landings were faked" to be of roughly the same measure as my grammatical or critical thinking skills.

Do you even realize that you've finally stumbled onto the crux of the argument?

By capitalizing idiotically, you're attaching meta-data regarding your intelligence and/or education to the content of the communication. Based on this at-a-glance meta-data, I need now assign only the most basic processing power to the task of understanding your communication, because the meta-data has already in large part invalidated whatever position you flounder to express.

Thus, capitalization enhances communication beyond mere content.

The same is true for capitalization in programming.

Well done, it attaches important (human-grokkable) meta-data to the symbols and declarations that don't inherently care about case.

Poorly done, it's confusing, sloppy, and casts doubt on the rigor and intelligence of the author: If the author can't be bothered to maintain consistent casing, how can I assume any effort was spent maintaining consistent logic?

Further, the appraised consistency of a system is additional meta-data that changes the interpretation of every next symbol or construct parsed, in a feedback loop that raises or lowers the determining appraisal. A "Running Tally", let's call it.

Following your path to conclusion by way of one example, virtually everyone that works on or near the web today agrees that standards (i.e. consistency) are A Good Thing™. Before we had them, or rather, before anyone followed them, The Bright Idea™ that tag soup should be parsed "as well as possible" was the norm. How did that end up?

Nightmarish, you say?

IE6, you say?

To shreds, you say?

We exist to find or build order in chaos. We are all driven to do so, or doomed to run in circles until we lie down and die. It is a HUGE component of life, and of the human condition.

Programmers are generally [expected to be] a little closer to the order end of the scale. Else, how can you even begin to trust them to solve your logic problems?

As I said before, ranting against context (and now, I add, consistency) and for a lack of discipline is very... odd.

0_o

hoodaticus · 2010-11-05 Reply Admin

Mr Jewish:
Perhaps it'd run *slightly* more slowly, but dear god I hate it when developers create these godawful 100-deep nested if statement trees. Some of our code at work looks like this, about two dozen nested if statements.
A few of the blocks have code after the closing braces, and it's impossible to work out which if block it executes after when the opening statement is a hundred lines away and not necessarily at the same indentation.

So yeah, is the following really so bad?
if (!$email) {
	global $Email; 
    $email=$Email;
}
if (!$email) {
	global $Email_Address;
	$email = $Email_Address;
}

Too much nested anything pisses me off, too. Classes, anyone?

hoodaticus · 2010-11-05 Reply Admin

Max:
This 'feature' exists in Fortran 77. Variable names (case insensitive) are capped at 6 characters long. Any extra characters are just ignored by the compiler (as is whitespace). The result is that "Emailaddress", "email ADDRESS", and "EmAiLa" are all the same variable. Further, if you have a variable "TEMPERED" and a variable "TEMPERATURE", they will actually be the same variable "TEMPER". This is entirely fun and not at all frustrating to deal with.

NICE!

2010-11-07 Reply Admin

The correct way to do this is to:

foreach (array('Email', 'email_address', 'EmailAddress', 'emailaddress') as $name)
  if ($email) break;
  else $email = $GLOBALS[$name];

2010-11-08 Reply Admin

Computer is the most complex artifact made by humanity so far, a truly masterpiece. TRWTF is to allow average people to program it (if not morons).

shaman

2010-11-08 Reply Admin

Jaime:
So..... If a library is written on an IBM mainframe and the source code is encoded in EBCDIC, then the source is compiled to a Java class, then the class file is copied to a Linux computer, do you have to save your Linux source code encoded in EBCDIC to properly call the functions?

Trick question. Java mandates that source code is in UNICODE. A Java compiler that eats only EBCDIC isn't. You lose.

2010-11-08 Reply Admin

Design Pattern:
German sayings: "Bier soll man in Maßen trinken!" -> You shall drink beer in moderation. "BIER SOLL MAN IN MASSEN TRINKEN!" -> Drink beer in huge quantities!

FYI, the correct transliteration of ß in this case is sz:

Bier soll man in Maszen trinken.

Masse und Gewichte: Mass and weights Masze und Gewichte: Measures and weights

Tut Busze: Repent! Tut Busse: Do buses - erm, what?

Jaime · 2010-11-08 Reply Admin

similis:
Jaime:
So..... If a library is written on an IBM mainframe and the source code is encoded in EBCDIC, then the source is compiled to a Java class, then the class file is copied to a Linux computer, do you have to save your Linux source code encoded in EBCDIC to properly call the functions?

Trick question. Java mandates that source code is in UNICODE. A Java compiler that eats only EBCDIC isn't. You lose.

Then why does javac have a -encoding switch?

2010-11-08 Reply Admin

AndyC:
Joops:
The less a compiler (or parser) has to work out for itself, the less chance you have of introducing a unintended subtleties. When I write code (or a document, for that matter) I mean exactly what I say (auto-correct sux too). If I have used 'x=0;' somewhere, and 'X=17;' somewhere else, I like the compiler to fail - it cannot (and should not) be certain that I was referring to the same x. Insisting on standards may be a pain in the ass, but it does create more readable programs (and I think better programmers).
If that were the genuine argument, then compilers would insist on case-sensitivity, but disallow identifiers that differ only by case. In fact, that would probably be the ideal.
The reason it exists, however, is because it was easier and quicker to implement when K&R developed C. And seems to have persisted purely because of C.

But case-sensitive identifiers are nearly as WTF-y as the Unix case-sensitive filesystem, which is just embarrasing.

How odd. Granted, it isn't enforced by the compiler, but the IDE for VB tries to simulate exactly that. (Case-preserved identifiers; identifiers that would differ only by case are re-cased to the same identifier.) Guess it was ahead of its time... in a very annoying way.

2010-11-08 Reply Admin

Anonymous:
frits:
This is literally the lamest WTF that has ever been posted.
Seriously, who hasn't had to do something like this?
Puts hand up

Yeah, no - I haven't needed to either.

2010-11-08 Reply Admin

quisling:
EvanED:
John Muller:
Well, one case I can think of is:
"The internet is down" vs. "The Internet is down"; Capital I Internet would be the global TCP/IP network; vs. a corporate wan scale network for the corporation you're in.

or "doctor who" vs. "Doctor Who"; capitalization can distinguish between a class, and a widely known specific instance that has no other name.

"The president picked up the phone." (and ordered lunch) vs "The President picked up The Phone." (and ordered a nuclear strike)
The fact that there are a few counterexamples (cf. Uncle Jack) doesn't diminish the fact that capitalization is pretty meaningless almost all the time.

In any other conversation, if I wrote "thE mOOn laNDINgs WerE FAKeD" I can almost guarantee most people would consider the difference in meaning between that and "the moon landings were faked" to be of roughly the same measure as my grammatical or critical thinking skills.
Do you even realize that you've finally stumbled onto the crux of the argument?

By capitalizing idiotically, you're attaching meta-data regarding your intelligence and/or education to the content of the communication. Based on this at-a-glance meta-data, I need now assign only the most basic processing power to the task of understanding your communication, because the meta-data has already in large part invalidated whatever position you flounder to express.

Thus, capitalization enhances communication beyond mere content.

The same is true for capitalization in programming.

Well done, it attaches important (human-grokkable) meta-data to the symbols and declarations that don't inherently care about case.

Poorly done, it's confusing, sloppy, and casts doubt on the rigor and intelligence of the author: If the author can't be bothered to maintain consistent casing, how can I assume any effort was spent maintaining consistent logic?

Further, the appraised consistency of a system is additional meta-data that changes the interpretation of every next symbol or construct parsed, in a feedback loop that raises or lowers the determining appraisal. A "Running Tally", let's call it.

Following your path to conclusion by way of one example, virtually everyone that works on or near the web today agrees that standards (i.e. consistency) are A Good Thing™. Before we had them, or rather, before anyone followed them, The Bright Idea™ that tag soup should be parsed "as well as possible" was the norm. How did that end up?

Nightmarish, you say?

IE6, you say?

To shreds, you say?

We exist to find or build order in chaos. We are all driven to do so, or doomed to run in circles until we lie down and die. It is a HUGE component of life, and of the human condition.

Programmers are generally [expected to be] a little closer to the order end of the scale. Else, how can you even begin to trust them to solve your logic problems?

As I said before, ranting against context (and now, I add, consistency) and for a lack of discipline is very... odd.

0_o

clap._x = 0; clap._y = 0; clap.gotoAndPlay(0); //flash makes me want to vomit

The Email Tree

Leave a comment on “The Email Tree”