Software Development

I wish language developers would agree on the equals syntax


Today's post is short because I just want to rant about how different programming languages have different syntax for the equals sign. For some reason I've been running into this particular issue a lot the past week, and it's starting to drive me crazy.

Sometimes I envy people who only have to program in one language because they never have to worry about this problem. But those of us who program for the Web use so many different languages and sometimes we use one language to generate another -- for example, I'm using PL/SQL to spit out HTML and JavaScript. So we're constantly running into the scourge of the un-equal equals.

What I'm talking about is the syntax for how a language uses the equals sign. For example, in PL/SQL we use := for assignment:

x := 7;

And then we can use the plain old equals sign for doing the logical equals:

if (x = 7) then...

Those of you who do any JavaScript and HTML will immediately see my problem. This is quite different from the equals syntax used in those languages. My poor little brain can't handle the constant context switching. So when I'm embedding HTML or JavaScript code inside my PL/SQL code, I invariably end up with a bunch of extraneous := like so:

v_href := '<a href="javascript:void(0)" mce_href="javascript:void(0)" onclick=''return launch("/portal/pls/portal/CMP.pkg_discoverer.show_viewer_iframe?p_disco_id=' || p_disco_id || '")''>';

Of course the PL/SQL editor doesn't know that's a syntax problem because it's treating the stuff inside the single quotes as a string in the PL/SQL syntax. So I get no help from my IDE -- it's only when I compile and try to run my code in a browser that I see the problem.

It would make my life so much easier if all those big-brained people who create these programming languages would think about the poor lowly programmers like me. They should standardize key parts of language syntax, and they need to start with the equals sign. Imagine how much it would increase your productivity if you didn't have to think about which language you're in before typing out the appropriate variation of an equals sign.

Oh, and don't get me started on the quotation marks -- you can see from my href sample above that PL/SQL uses the single quotes to delineate strings. The way you escape a single quote in PL/SQL is with another single quote instead of the forward slash used by JavaScript as the escape symbol.

Sorry about this rant. I'm just feeling grumpy from all the time I've wasted on these silly little syntax issues this week. But I'd love to hear what other cross-language syntax wackiness drives you crazy.

52 comments
doug.cronshaw@baesystems
doug.cronshaw@baesystems

... the presumed confusing use of the := and = tokens in assignment statements dates back forty years to the definition of Algol 68. The introductory report for that language, and its 1974 revision are quite clear about the distinction to be made between them. Unfortunately, those derivative languages that use the := token to indicate assignment don't always make that clear distinction. The := is known in Algol as the is-and-becomes symbol. It is used to indicate the assignment of a value of a suitable type (mode in Algol) to a variable. There are strict rules governing the types of the source and destination parts of Algol 68 assignments: the (possibly coerced) type of the source must have one less "ref" part to its mode than the destination. ("ref" is a keyword in Algol indicating a reference to a location, i.e. it is used to tell the programmer that the identifier with that mode is some sort of variable that is held in some sort of memory store.) The implication of use of this token in an assignment statement is that a value is being moved (assigned) to a location. [Another Algol 68 rule for assignment statements is that the scope of the source's value should be at least as great as the scope of the destination's reference identifier for the assignment to be valid. The language definition of Ada '83 managed to ignore this last rule with the result that pointer variables could be assigned values that became invalid before the potential use of the pointer variables ceased. That blunder was fixed for Ada '95.] The = token in Algol is used to indicate identity. This is usually used in constant declarations to indicate the value to be associated with a constant identifier. Thus: int x = 2; puts x as an identifier of an integer constant into the symbol table with an associated value of 2. Subsequent reference to the identifier x would expect the compiler to replace it with the integer value 2. Identity declarations can also be used in Algol to declare identifier symbols which are to be treated as equivalents; they allow similar syntactical use to the Fortran EQUIVALENCE statement. Thus the declarations: real a; ref real b = a; create a single single-precision real variable location with two different identifiers; b refers to the same location as a. (They wouldn't normally be used in exactly the form shown above, as the usual use of equivalence identifiers is to declare a symbol to access a location at an inner scope level that might otherwise have been excluded by re-declarative use of the same identifier within that inner scope level.) Note: Exasperation with confusing token or symbol use within and between languages may mean that there is more to the situation than immediately meets the eye!

gingoro
gingoro

Agree! My take is that assignment should be something like := or even

amsmota
amsmota

There are different levels of programming, thus different languages with different sintaxes. I've programmed in Assembler and there wasn't no =, who needs it? Maybe with such "poor little brain" you should consider a carreer change...

gweinman
gweinman

C++ was originally a preprocessor. Nothing stands in your way of creating another preprocessor. Your preprocessor would convert some symbol to the equals for equate and some other synbol to the equals for assignment. Complaints about any language syntax are easily resolved by programming. You can have your cake and eat it too.

jjrockman
jjrockman

Not to pick on a particular language, but I had gotten so used to using "==" for comparison in almost every language I use - then I get to the "===" in php and it blew my mind. For those that don't know, "==" is a comparison on the value whereas "===" is also a comparison on the value that ensures the items you are comparing of the same type. So many gotchas on PHP!

jck
jck

WAH! I WANT ONLY ONE PROGRAMMING CONVENTION! Jesus. I program in several languages too and have for years. It is PART OF PROGRAMMING LIFE TO HAVE TO CONFORM TO LANGUAGES FROM SEVERAL DIFFERENT CORPORATIONS THAT ARE USED FOR DIFFERENT PURPOSES. If you can't handle remembering x:=7 or x=7, or even the difference in C++ of x=7 and x==7...then get out of programming. It's not for you if it's that much of a hassle. Go write users' manuals or something. English is pretty standard nowadays. But, don't expect the technical industry to change their standards just because it inconveniences you. There's my rant back. Happy friggin Monday.

dogknees
dogknees

One problem with this idea is choosing which languages standards should be applied to all the others. Would we all agree to use the oldest standard, probably the first version of Fortran. You really don't want this as the standard! Would we all agree that we should apply the standards from OZ? It has single assignment as the standard. That is, you can only ever assign one value to a variable. Should we use BASIC, because it's probably the most common language when you include all the VBA code out there? COBOL would also be interesting. It'd be kind of fun to graft the COBOL assignment method onto C#. Which of these? One reason it actually makes sense to use different approaches is that the semantics of equals is not the same in every language. In some, it means the values stored in the objects are the same. Others say two objects are only equal if they refer to the same location in memory. Similarly, assignment sometimes means making the second object refer to the same location as the first. Sometimes it means make a copy of the first object. And the important thing to realise is that all these interpretations are entirely reasonable in certain types of languages. The're not invented arbitrarily to amuse language researchers and cause pain to programmers. They have these differences because the designers are trying to get a better match between the problem domain and the tools used to address it. Not everyone spends their day coding database apps and websites. The world of programming is a lot broader than that, and the languages that make sense to people a lot more varied. Ultimately, you have to treat learning a language as finding a new way to look at the world of programming problems. A new way of seeing may make the solution to a problem that has you stumped obvious and simple. That won't happen if you try to understand a new language in the terms of an old one. An associate of mine had this idea when we moved to Unix in the early eighties. He got me to write a bunch of scripts to create the same commandline tools he was used to in the previous OS. (RSTS/E for those old enough) This meant he took far longer to learn Unix as he was trying to understand it using an inaccurate set of assumptions. Make a clean break and learn each new langauge as if it's your first. Regards

Tony Hopkinson
Tony Hopkinson

I'm working With Delphi and C# at the moment Needless to say I'm getting assignment and equality backwards on a regular basis. And single and double quotes. At least ;for end of statement is the same in both. They get spotted at compile time in both those languages, dare say an IDE semantic check could get expensive, be nice though. Fortran, VB, Perl, PHP and SQL (MySQl version) at the same time, that will sort you out. :D

sherryg
sherryg

Having been programming in scores of languages for over 40 years (yes, I began before S/360 mainframes), I really appreciated your rant.

Justin James
Justin James

... languages that have both single and double quote quoting mechanisms, too. In the languages that do, single quotes tend to be a pure literal (like take '\n' to mean "\n") and double quotes get some interpretation done on them (such as "\n" means "newline"). But at the end of the day, things like this make sense to be different in different languages. Each one has a purpose, and their purpose is reflected in their syntax. I cannot tell you how many errors I have seen caused by someone doing: if (sInput = "Hello") { which always evaluates to true (and sets sInput to "Hello" at the same time) in quite a number of languages... J.Ja

gfhavewala
gfhavewala

What I sorely wish for is a "programmer's keyboard" where there would be a separate 'symbols pad' (may be in lieu of the numeric pad, which is more of a data entry convenience). This should generate the following symbols / combinations of symbols WITHOUT using the 'Shift' key: :, :=, {, }, , @, #, $, %, ^, &, (, ), +, and the vertical bar | Microsoft, Logitech, iBall -- are you listening?

Wayne M.
Wayne M.

The human brain excels in pattern recognition and pattern matching and these are the characteristics of a strong programmer. The effective programmer is thinking at a higher level than the pure syntax of the language and is automatically translating that into code. This process, however, is greatly interfered with when doing mixed language development. The translation process is no longer automatic; the developer needs to be cognizant of the context for a line or even a part of a line of code and select the correct syntax. This slows the development process as well as being a source of faults. Switching assembly languages is equally hard, and few have to switch at anything below the project level. Even so, C has been widely adopted in the embedded market to avoid the reduction in efficiency due to switching languages. One should never identify systemic problems as individual failings. It is also advisable not to be insulting when discussing an issue outside of one's direct experience.

Tony Hopkinson
Tony Hopkinson

gotchas, for chaps used to statically typed. When the concept is different I prefer a different operator, at least you can see what's going on then. StrNumber == intNumber would confuse the heck out of anyone.

Shellbot
Shellbot

Hopefully Tuesday is workin out better for ya?? Still waiting for a mail re: where the heck you've been for the past oh YEAR! I'll admit, the differences in languages with certain things does annoy me..but i get over it :) Half my code doesn't work the first time around cause I've used FoxPro or VB syntax... :)

techrepublic
techrepublic

Thats why people who can program in more than one language make more $$$.

djj55
djj55

I have a bad memory at best so when I have been working in one language and a problem comes in for another language to be fixed NOW! I find it takes me a few to re-adjust my thinking. djj

lostcarpark
lostcarpark

I have to agree with everything you've said here. The idea of all languages following the same convention for operators sounds fine in principal, but it belies the reasons for having different languages. If it was as simple as adopting one convention for all languages to follow, we'd only need one language! Believe or not languages designers do not adopt different conventions to annoy you or make your life more difficult. Most languages are designed to solve a specific set of problems, usually taking the designer's favourite language (or a subset of it) and adding the specific new feature they want. Trying to get language designers to change their languages to a common set of conventions would be like getting all speakers of French to adhere to a common set of conventions because you have difficulty changing from English to French. It's not going to happen. On a daily basis I could be using C++, C#, VB (two flavours), PHP, JavaScript and SQL (three flavours), and of course HTML and XML, and something strange called Ab Initio. Personally I like the fact that they all do things differently. I think it would be more confusing if they were all the same. At least I can look at a piece of code and say "Ah, that's PHP" and my brain instantly goes into PHP mode.

C_Tharp
C_Tharp

Why not? It seems reasonable to have some tokens always mean exactly the same thing regardless of the language or operating system or other extraneous factors. It is reasonable to limit the overloading of operators. (That does not mean eliminate overloading.) It is reasonable to expect comparitors to be different from other operators. Can some operators be overloaded without confusion? possiblity = "yes" + " and " + "no" or is it possibility = "yes " || " or " || "no" This seems reasonable so long as these operators do not take on a different meaning in yet another language. However, overloading "+" for color might be confusing. A new operator might provide clarity. green = yellow + blue Could "~" to mean "blend with" be too much to ask. green = yellow ~ blue Don't reinvent the wheel. Why do we need "|" in one language and "or" in another and ".or." in another? If it must be changed, make it for a considerable improvement that everyone will recognize and readily assimulate. If a different operation is desired, provide a different token. The fact that the developer has to learn something new is not a reason to introduce confusion. Yes, some choices were not so great and we want to make them better in the next language. Is the change worth the nuisance that it creates? Unfortunately, the history has been cast and we have no hope of correcting it. At least, now that we recognize the problem, let's try to limit the madness.

Justin James
Justin James

The nuances of each language are such that to try to standardixe the equals syntax takes away a huge differentiating factor. What about the returned results of the equals syntax? Some of them return a purely Boolean result, and others return something else entirely, which can be evaluated in a Boolean context. The same goes for assignment. Some languages return an "A-OK" signal for assignment, to indicate that the assignment occured correctly. Others may return the number of items, bytes, array elements, etc. copied or assigned. And so on and so on. It all depends on the language and the goals and syle of the language. J.Ja

fyw
fyw

I also have toooo many years of experience. I first programmed in FORTRAN on an IBM 1130 in the '60s and the scores of languages have sure made it tedious to think about syntax. The =, ==, := ... and ~, ! extensions don't help. Great rant! Syntax parsing is not that hard :-)

gerard
gerard

Justin, I agree with your rant up to a point. I'm into ruby myself (got there via a life of perl, bash , sql and some php), and in the office the developers use python. You can learn everything but I came to the conclusion that if you need functionality in a certain language and somebody else is better in it, define your request and let them do it. In my case I especially experience this in the office with young ICT students that are incredibly good. You don't need to know the programming language, you just need to speak their language. Like they say: You can know a little about everything, or everything about just a little bit. Regards, An IT specialist who used to think he was getting old .. :-)

paulallsopp
paulallsopp

As far as the equals is concerned, I'm afraid I have to disagree. = means equals; == means is equal to; === means is equal and of the same type. For me that is very logical. = is a assignment operator, where == is a comparison operator. As a PHP/Javascript developer one thing I do find annoying is their differing definition of the timestamp. In Javascript, the timestamp is taken to a further 3 digits, and so when passing timestamps between PHP and JS, I must always remember to either /100 or *100 first. When I first didn't know this I ran into some issues.

The Terminated
The Terminated

I don't mind leaving out the space, but whose bright idea was it to leave the last e off the else? My fingers always put it in automatically.

Mikiel
Mikiel

Concatenation operators could use some standardizing as well. For the readers out there who are making or improving a language, please... * make everything case insensitive and * let us nest comments. (If I comment out a big block of code that happens to have comments within it - I do not want the big block to be come uncommented half-way through.)

Justin James
Justin James

I want a "programmer's remote control", it would basically be like a DVD player remote, but for debugging. A dial for "shuttle" would hold down the "step into" command, there would be a "skip" button for "step over", a "fast forward" button for "run until this block exits" and so on. It would be really handy, esp. when working as a group. My current keyboard is GREAT for ergonomics, but horrible for coding. Because it is designed for easy, fast typing, the common programming symblos are quite out of the way. :( J.Ja

jck
jck

You said: [i]One should never identify systemic problems as individual failings.[/i] How is it a "systemic" problem, when the difficulty lies with the individual ability to deal with remembering different syntaxes within different development environments in only some cases? If the problem is system-wide, then the majority of people would have serious enough problems with it to warrant change in the system. Since that has not happened, I would tend to disagree. I think most computer professionals who program in several environments/languages/syntaxes deal with it quite well. It's the "vocal minority" who demand that their syntactic "squeaky wheel gets the grease". It's not the fault of the system that individual(s) can not adapt to the use of several languages, syntaxes, environments, and requirements which have evolved during the approximately half-century of electronic computing. That is an individual issue.

jck
jck

was written when i was at an old job...and as you can tell, i was stressed out... But still...askin for one...or even a more unified model for programming...is like asking Baskin-Robbins to just make one flavor of ice cream that everyone will love. it just isn't going to happen. i will go check emails today and see if i missed your email...or maybe yahoo just didn't deliver it...they're notorious for having my emails and YM messages go into the ether. where did i go? um...i took a 9 month hiatus from TR...mainly cause i got a new job...and i was doing 4 roles...and i had no spare time. lol

Wayne M.
Wayne M.

I guess I prefer to avoid most of the confusion over operators by quickly creating custom objects and getting away from data primitives. After a brief flirtation with overriding operators many years ago, I came to prefer English language operations to pseudo-mathematical ones. If I ever defined a new language, I would try my best to avoid operators.

Justin James
Justin James

This is not my "rant"! Argh! This is what happens when I "own" this space for 6+ months with the anonymous title "Programming and Development" and then they put someone else in it! J.Ja

marcellus.tryk
marcellus.tryk

How is that logical? Seems completely arbitrary to me. In my opinion = should be the universal logical operator. After all that's what it has signified historically. You've got < for "less than", > for "greater than", = for "greater than or equal to and, naturally (I would think) = for "equals". I don't see why assignment should be denoted by =, except that it vaguely suggests equality in the sense of "after you apply this operator the value of the LHS argument should be equal to the value of the expression on the RHS". I think there is an admission to this in the case of ==. I see the second = as added for emphasis, as in "REALLY equal!". :) All that being said, we all know that consistent conventions across programming languages is a pipe dream.

Justin James
Justin James

You must be disagreeing with Rex, 'cuz I said "But at the end of the day, things like this make sense to be different in different languages." :) J.Ja

Tony Hopkinson
Tony Hopkinson

:= means assign which you noted as equal which it may not be have been and still may not be. = is equivalence Pascal's a statically typed language so === is =, it's not possible for different types to be equal. Justin said the inconsistency was illogical.

Jaqui
Jaqui

case sensitive languages are REQUIRED for the complex applications being developed. try writting a complex app with every variable name being case insensitive, you will find conflict after conflict because the developers used the EXACT same name for different things, yet it is only the same and an issue because of "case insensitive". last thing I would want to see is Foo = foo = fOo = foO = FOo ... because of case insensitive. never mind that all QUALITY operating systems are completely case sensitive themselves. [ note, Windows is the only non case sensitive os out there, and is the least secure, maybe they are RELATED? ]

RexWorld
RexWorld

Thanks for reminding me about another bug-a-boo, nested comments. I definitely would vote for supporting nested comments in a programming language.

jck
jck

Perfection in programming is impossible to any industrial level of coding. Surely you know that. However, the original post sounds like the guy is [b]consistently[/b] repeating mistakes syntactically. Most highly-competent programming minds learn after few mistakes...especially in environments they use constantly. For example, I write in: HTML VB .NET ASP .NET a 4GL language Informix SQL Microsoft SQL MS command line script(DOS batch) VBScript And, I do these almost daily. I don't fret over making the occassional mistake and wish for a ubiquitous programming syntax. I just realize...I make the occassional mistake...and correct it. But *if* you're making repeated, frequent mistakes due to not being able to remember the constructs of various programming languages you use in your professional, technical career...as I pointed out...maybe it's time to write user manuals as writing in English is pretty standardised. Anyways...perfection isn't attainable.

marcellus.tryk
marcellus.tryk

Everybody knows that this problem (if it is one) can't be fixed. But that doesn't mean it isn't annoying. There may be programmers who can work with multiple languages and/or operating systems who aren't at all impeded by context switching, but I bet they are few. These would be people who have NEVER screwed up a path by using \ instead of / (or vice-versa), had a compile fail because they used instead of != (or vice-versa) or had a program crash because they used = instead of == (or vice-versa). In any case that kind of perfection would be nice but not very high on my list of desirable developer abilities (it would fall somewhere below "fast typist").

Shellbot
Shellbot

I didn't check the date on the thread..it was in the list of current threads so i thought it was a new one!!!!!!!!

Wayne M.
Wayne M.

One the trade-offs we would have to make for a context driven approach to work would be to require additional typing to allow the intent to be more specific. My personal preference for the code above would be either bool bTruth(x == y); or the if/else variant. I tend to favor resolving ambiguity by relying on more typing and less on language specific knowledge.

Justin James
Justin James

... especially with "elegant" statements like you give. Another one is something like: bTruth = (x = y) or (rewritten to be more C-like) bTruth = x == y; in a language that lets you do a syntactic munge like this, you would need to rewrite this as: 'BASIC syntax if (x = y) then bTruth = true else bTruth = false end if //Proposed C syntax if (x = y) { bTruth = true; } else { bTruth = false; } For the low SLOC folks out there (and I am one, to an extent... when more than 10% or so of coders are baffled by the code, it is too "elegant"), this is a travesty. Anyone who understands C-style knows exactly what: bTruth = x == y; will do, but to change this to: bTruth = (x = y); or bTruth = x = y; Makes it nearly impossible for the compiler OR the coder to know the intention of the statement! The only way to make it work is to have the identical assignment/equal operator overloaded based on whether or not it is evaluated in the context of a logic function like if or switch or what have you. To me, that is a much bigger kludge (just read a lot of VB code with a lot of Boolean setting!) that having two different operators. J.Ja

Wayne M.
Wayne M.

There is no reason that the meaning of = could be defined by context. If a boolean value is being evaluated, then a comparison would be warranted. If no evaluation is needed, then assignment is appropriate. If we restricted ourselves to usage like x = 0 (assignment) if(x = 0) (comparison) a lot of errors could be avoided and we could actual migrate languages away from use of == while providing backwards compatibility. The only thing we would give up would be things like the C string copy monstrosity: while(x++ = y++); I can't imagine how much developer time has been wasted as people puzzle over obscure statements like that and trying to determine if they actually work.

lostcarpark
lostcarpark

If you are going to establish a convention for assignment and equivalence, whatever way you do it you will be upsetting millions of programmers across the planet. The only fair way would be to outlaw the "=" operator altogether, and make all compilers flag an error whenever they see one. The most reasonable convention I can think would be to use the most common assignment operator that isn't "=" (I think that would be Pascal's ":=" operator), and the most common equivalence operator that isn't "=" (almost certainly C's "=="). It's often said that you know you've reached a good compromise when nobody's happy, and I'm sure nobody would be happy with this. However, if you were to enforce a convention, this would be the one that would result in least confusion, since you'd never have to ask yourself "is equals assignment or equivalence?"

marcellus.tryk
marcellus.tryk

I'm not saying which usage is more common, just what makes more sense. I would be happier (if we're talking about a universal convention that would be used in perpetuity) to have == denote assignment. To me this is clearly preferable as is using + for addition and ++ for incrementing (rather than the other way around). Regardless of what symbol you use for assignment you can still have the assignment return a value. It would just be less likely to bite you in the posterior E.g. where in C you can do this: if (x=0) // do something Which is valid, executable and clearly does something different than what the programmer intended. Yes, reversing the semantics of these symbols would cause enormous pain and suffering for the current generation of programmers, but our children would be happier for it. :D

Justin James
Justin James

If you use = for logical, what about assignment? Coding in a language where assignment and logical use the same operator makes code significantly more verbose in many cases. Additionally, there are a lot of tricks that you can do when assignment returns a result that can be used in a logical context (think: "if !(a = b) then die 'Could not assign be to a.';" BASIC and its associates (VB, VB.Net, VBA, QBasic, et al) use "=" as its equality and assignment, and the language suffers poorly for it. Indeed, I am hard pressed to remember a non-BASIC language that uses "=" for equality... J.Ja

Justin James
Justin James

... I have *never* (as far as I can recall) use the blockquotes, and his writing style is nothing like mine! Sheesh... Actually, this week I will probably be discussing F#, since after a year of merely *talking* about it, I finally started to actually use it. J.Ja

Tony Hopkinson
Tony Hopkinson

posting 'interesting' technical articles, I though it was yours. :D If you are running out of material, DLR (Dynamic Language Runtime) is a goody.

Justin James
Justin James

Tony - "Justin said the inconsistency was illogical." I never said that, Rex did! I just pointed out that along the same lines are the different quoting mechanisms. I also said that I actually think that it makes sense for different languages to have different assignment and equality tests. J.Ja

klaasvanbe
klaasvanbe

To avoid as much confusions as possible for me everything i.e. FileNames, Variables, Procedures etc. are case sensitive like in *X or nothing like in DOS/WIN*. Any exceptions should be notified clearly.

Mikiel
Mikiel

True. I'm not against case sensitivity in passwords. It's also needed in many searches. What I'm against is case sensitivity in variable names, function names, etc.

Jaqui
Jaqui

slightly off topic. language case sensitivity is not the same at all as application case sensitivity. [ Visual Basic isn't case sensitive, as far as I know, yet you can code applications for login that are in it. ] C++ is case sensitive, yet the most common OS, Windows, written in C++ is not. I happen to agree it is better to be case sensitive, since it FORCES the developers to PAY ATTENTION to what they are doing, where the case insensitive idea would let them not pay attention to their jobs.

klaasvanbe
klaasvanbe

case insensitivity will cause less security, because it gives you for every letter 26 possibilities less to make your password more safe. Suppose you have only 4 letters you can make only 456,976 as opposed to 7,311,616 different passwords.

Mikiel
Mikiel

I guess our experiences have been radically different. I'd love it if Foo = foo = fOo. Developers have enough problems with logic - why introduce new meaningless capitalization errors by insisting on case sensitivity? It's not adding any functionality or power to the language and it creates problems. I've often encountered code where someone thought they were referencing an existing variable - but due to capitalization and case sensitivity they had unknowingly created a new variable. These problems can be hard to track down. I've had that happen to myself with CSS class names. You could blame lazy developers for not being consistent, but I think programming languages would be easier if they took into consideration that humans will mix up "nextItem" and "NextItem" and that humans think that "aardvark" comes before "Balloon" in the dictionary. On the other hand, I can't recall ever encountering code where someone purposely had two different variables with the exact same letters but which were distinguished only by capitalization. In fact, if I ever did encounter such code I'd want to shoot the developer. You're just begging for problems if you rely on capitalization to distinguish two variables and hope that future humans reading your code will get the distinction. The readability of your code would be abysmal.