Ask yourself who the end user is. If it’s meant to be written by someone with programming experience in C or Javscript, or IT experience in Unix, then case sensitivity is probably the right thing to do, because that’s what the user expects. But for most end-users, even power-users, this will be confusing.

VB/VBA/VBScript are case-insensitive, and this was a decision made to allow non-programmers to easily get the hang of the language. Excel formulas, not exactly scripts but as close as many users get, are not case sensitive. In most writing the choice of case can make the text look more or less professional and polished, but case it self won’t change the semantic meaning of the words. That’s why I believe non-developers will be confused by a case sensitive scripting language.

Again, this isn’t a technical choice. It’s a product-management choice that has to be made by the people who know the target audience well.

You should decide based on the user experience you wish to present, not how easy or hard it is to implement.

If it will make it easier for your users to have case insensitivity then that’s what you should implement.

As a case in point SQL is case insensitive. This makes it very easy to use in an interactive setting.

Another way to look at this is will there ever be a difference between keyword and Keyword in your language, and will this difference be meaningful to the user? For a scripting language I’d say the answer is “no”.

Programming languages should be case-sensitive, period. People can adjust to this very easily: they simply have to remember to work mostly in lower case, and to watch out for mixed-case or all-caps identifiers in existing API’s.

It once seemed obvious to make languages case-insensitive. This is because lower case was not available on all computing systems and their I/O devices (keyboards, printers and display devices). Programming language implementations had to accept programs written in upper case, since only that could be displayed or printed. And for that they had to be case insensitive, because to accept upper case and be case sensitive at the same time means to reject lower case. Lower case was something programmers wanted, but could not always have. Nobody really wanted to work with programs which shouted in upper case; it was just a hardware limitation.

For a while, it was common to even do case folding in terminals. If a terminal could only display upper case, but you had to log into a computing system supporting upper and lower case, the terminal would fold the lower case to upper case. Think this was so long ago? “Like the Apple II, the Apple II Plus had no lowercase functionality.” (http://en.wikipedia.org/wiki/Apple_II_Plus) When users of early Apple computers dialed into a BBS that had mixed-case content, the terminal emulator (or host) had to fold that all to upper case. Messages written in all caps were common on bulletin boards in those days. This functionality is still found in Unix-like operating systems, like the Linux kernel. For example, type the stty olcuc at your shell prompt. The Unix tty line discipline can map lower case to upper on output, and it can map upper case to lower on input. This allows you to work in a lower case programming language, on a terminal that has no lower case.

Case insensitivity is an outdated concept from a bygone computer era that doesn’t work very well in the modern world of internationalized computing. Do you extend that into other languages? How about French: do you consider È and è to be equivalent? Or Japanese? Do you consider hiragana and katakana to just be cases, so that ファイル and ふぁいる are the same identifier? Support for such folly will greatly complicate your lexical analyzer, which will have to have case equivalence maps for the entire Unicode space.

Note that mathematics is case sensitive. For instance, the upper case sigma might denote summation, whereas the lower case sigma denotes something else, like standard deviation.
This can occur in the same formula without creating any difficulties. (Will the programming language make Σ and σ equivalent?)

English orthography is sensitive. For example, many proper nouns correspond to ordinary nouns or even other parts of speech. “may” is a verb, but “May” is a month, or a woman’s name. Moreover, if an acronym or abbreviation is written in lower case, it can be confusing. SAT stands for scholastic aptitude test, whereas “sat” is the past participle of “sit”. Intelligent people pay attention to detail and capitalize properly.

Basicaly, any new programming language created since 1985 which is case-insensitive is FOR THOSE WHO STILL SHOUT IN E-MAILS AND POSTINGS WITHOUT A SECOND THOUGHT.

What if your language is ever used as a code-generation target to translate code in another language, and that other language is case sensitive? You will have to somehow transform all the names to capture the distinction. (So to assert that this is not a technical decision, and only matter of the emotional preferences of the target audience, is ridiculous.)

Look at the annoying problems caused by case handling in the Windows, when files are imported from another operating system. That’s a technical issue. Case sensitive file systems have a problem with foreign data which case-insensitive ones do not.

Common Lisp has hit upon the ideal approach: symbol names are case sensitive, but when tokens are read, they are folded to upper case. This means that the tokens foo, fOO, FOO and Foo all denote the same symbol: the symbol whose name is stored as the character string "FOO". Furthermore, this behavior is only the default read table configuration. The reader can fold letters to upper case, to lower case, invert the case, or preserve it. The last two choices give rise to a case-sensitive dialect. This way, users have the maximum flexibility.

The real determining factor is how often you’re going to want to have multiple things with the same name. Case insensitivity works in SQL because it’s not often you want a column named SELECT. It would be annoying in Java because every other line looks like Object object = new Object(), where you want the same name to refer to a class, an instance, and a constructor.

In other words, case sensitivity is mostly useful for overloading a name, and overloading is mostly useful in large, complex projects. For more infrequent use, such as a scripting language, case insensitivity can make programming much simpler.

I made a rules language once where identifiers were not only case insensitive, they were whitespace insensitive. I also allowed creating aliases that referred to the same identifier. For example, ProgrammersStackExchange, programmers stack exchange, and PSE all resolved to the exact same symbol and could be used interchangeably.

For my domain that worked very well, because the domain had a lot of extremely well known ways to refer to the same thing, and naming conflicts were rare. No one would be surprised by typing a query using one name and having the result use another. Having language support made translating between the domain and the programming language very easy. However, it also made certain tasks harder, like finding all references to a variable. Thankfully, in my case those sorts of situations either rarely came up, or were fairly easy to build tool support to help, but you have to take your own situation into account.

Assumed your script language will be case sensitive – are you going to create a compiler or syntax checker that will tell the user if he makes a typo by using the wrong case in a variable name or a keyword? If not, that would be a very strong argument for making the language case insensitive.

Can you declare variables on-the-fly ? If so i would argue against case sensitive, as tracking down a bug caused by

ATypo = 42; 

as opposed to

Atypo = 42; 

is needlessly asking for debugging time, when having the two statements equivalent just makes life easier.

Examples of languages like FORTRAN, BASIC, SQL are given saying that these are case insensitive.

The reason why FORTRAN and SQL (and COBOL) are case insensitive is that they were originally designed for use on machines where the normal character sets had only uppercase letters. Case insensitivity in those languages (at least) is more a historical artefact than an language design choice.

Now you could argue that case insensitivity of more forgiving, but the flip side is that case sensitivity results in more readable code because it fOrCeS tHe cOdEr tO uSe cOnSiStEnT cApItAlIzAtIoN.

From my personal experience I don’t see a big difference between case sensitive and insensitive languages.

More important thing is naming and structural conventions that a programmer should keep in his code and no compiler or parser checks it for him. If you stick to some kind of rules you will easily know a proper name (you won’t think if you named a variable checkOut or CheckOut) and your code probably will be case sensitive and easier to read.

One shouldn’t use CheckOut and checkOut and checkout and cHeCkOuT and CHECKOUT in the same meaning. It will hurt readibility and make understanding that kind of code more painfull (but there are worse thing that one can do to destroy readibility of code).

If you use some kind of rules you will see at glance for example:

CheckOut.getInstance() – it’s static method of a class called
checkOut.calculate() – it’s a method of an object kept in variable or public field called
_checkOut.calculate() – it’s a method of an object kept in private field called
CHECKOUT – it’s a final static or constant field / variable

without checking out some other files or parts of a file. It makes reading code faster.

I see pretty many developers using similar rules – in languages which I often use: Java, PHP, Action Script, JavaScript, C++.

In a rare case one might be angry on case insensitiveness – for example when wanted to use CheckOut for a class name and checkOut for a variable and cannot because it collides with each other. But it’s a problem of a programmer that is used to case sensitivity and to using it in his naming conventions. One can have rules with standard prefixes or postfixes in a case insensitive language (I don’t program in VB but I know that many VB programmers have this kind of naming conventions).

In few words: I see case sensitiveness better (only for object oriented languages) because most of developers use case sensitive languages and most of them use naming conventions based on case sensitivity so they would like better a language to be case sensitive so they would be able to stick to their rules without some sort of modifications. But it’s rather religious argument – not an objective one (not based on real drawbacks or good sides of case sensitiveness – because I don’t see any when it comes to a good developer, when it comes to a bAd DeVeLoPeR one could produce nightmare code even when there is case sensitiveness so it’s not a big difference).

Programming languages should be case insensitive.

The main reason so many languages these days are case sensitive is simply cargo-cult language design: “C did it that way, and C’s incredibly popular, so it must be right.” And as in so many other things, C got this one demonstrably wrong.

This is actually part of the driving philosophy behind C and UNIX: If you have a choice between a bad solution that’s easy to implement and a good solution that’s harder to implement, choose the bad solution and push the burden of working around your mess off onto the user. This may sound like snark, but it’s absolutely true. It’s known as the “worse is better principle,” and it’s been directly responsible for billions of dollars worth of damage over the last few decades due C and C++ making it far too easy to write glitchy and insecure software.

Making a language case insensitive is definitely easier; you don’t need the lexer, parser and symbol tables to have to do the extra work of making sure everything matches in a case insensitive fashion. But it’s also a bad idea, for two reasons:

• First, especially if you’re building a scripting language, a simple typo where you call something “myObject” in one place and “MyObject” in another, where you obviously are referring to the same object but just got a bit inconsistent with the capitalization, doesn’t turn into a runtime error. (This is infamous as a major pain-point in scripting languages that get this wrong, such as Python.)
• Second, not having case sensitivity means that case sensitivity can’t be abused to have the same word refer to two different things in the same scope just by changing the capitalization. If you’ve ever had to work with Windows code in a C environment, and run into ugly declarations like HWND hwnd;, you’ll know exactly what I’m talking about. People who write like that oughtta be taken out and shot, and making the language case insensitive prevents case sensitivity abuse from making its way into your code.

So make the extra effort to get it right. The resulting code will be cleaner, easier to read, less buggy, and make your users more productive, and isn’t that the ultimate goal of any programming language?

I can’t believe that someone said “case sensitivity makes reading code easier”.

It most certainly does not! I’ve looked over a colleague’s shoulder at variables called Company and company (public variable Company, matched private variable company) and his choice of font and colour makes it incredibly difficult to tell the difference between the two – even when next to each other.

The correct statement should be “mixed case makes reading code easier”. That’s a much more obvious truth – e.g. variables called CompanyName and CompanyAddress rather than companyname. But no language I know of makes you only use lower case variable names.

The most insane convention I know of is the “uppercase public, lowercase private” one. It is just asking for trouble!

My take on errors is “better that something fail noisily and as soon as possible rather than quietly fail but appear to succeed”. And there’s no sooner than compile time.

If you mistakenly use a lower case variable when you meant to use the uppercase, it will often compile if you are referencing it within the same class. Thus, you can appear to succeed in both compile and run time but be subtly doing the wrong thing, and perhaps not detect it for a long time. When you do detect that there’s something wrong

Far better to use a convention where the private variable hass a suffix – e.g. Company public variable, CompanyP private variable. Nobody is going to accidentally mix up the two, and they appear together in the intellisense.

This contrasts with an objection people have to Hungarian notation, where a prefixed private variable pCompany would not appear in a good place in the intellisesne.

This convention has all of the advantages of the dreadful upper/lower case convention and none of its drawbacks.

The fact that people feel the need to appeal to case sensitivity to distinguish between variables shows both a lack of imagination and a lack of common sense, in my opinion. Or, sadly, the human sheep like habit of following a convention because “that’s the way it’s always been done”

Make the things you work with clearly and obviously different to each other, even if they’re related!!

Case sensitivity considered harmful.

Life is not case sensitive and neither are users or programmers.

Case sensitive languages are a historical accident, of constrained systems which found case-insensitive comparisons difficult. This handicap no longer exists, so there is no reason to make a case-sensitive computer system ever again.

I would go so far as to say that case sensitivity is evil, since it puts the convenience of the computer before that of the user.

(Related, I recall a few years back, some genius refused to pay his credit card bill because his name was in all caps, but he spelt it mixed case. Therefore, he argued, it was not properly addressed to him and wasn’t a valid demand for payment. The Judge treated the argument as it deserved).

You shouldn’t introduce case insensitivity without a very good reason to do so. For example, dealing with case comparisons with Unicode can be a bitch. The case sensitivity (or lack thereof) of older languages is immaterial, as their needs were very different.

Programmers in this era expect case sensitivity.

Case sensitivity makes code more readable and programming easier.

• People find proper use of mixed case easier to read.

• It allows/encourages CamelCase such that the same word with different case can refer to related things: Car car; Thus the variable named car is created of type Car.

• ALL_CAPS_WITH_UNDERSCORES indicates constants by convention in many languages

• all_lower_with_underscores can be used for member variables or something else.

• All modern programming tools (source control, editors, diff, grep, etc) are designed for case sensitivity. You’ll forever be having problems with tools programmers take for granted if you make a case insensitive language.

• If the language will be interpreted, there may be a performance penalty to case insensitive parsing of the code.

• What about non-English characters? Are you deciding now to never support Coptic, Chinese, and Hindi? I’d strongly suggest you make your language default everything to UTF-8 and that supports some languages that have characters with no upper or lower-case equivalent. You won’t use these characters in your keywords, but when you start turning off case sensitivity in various tools (to find things in files for instance), you will run into some surreal and probably unpleasant experiences.

What’s the benefit? The 3 languages you mention are from the 1970’s or earlier. No modern language does this.

On the other hand, anything that actually makes the end-user happy brings a little light into the world. If it will really effect user happiness, then you have to do it.

If you want to make it really simple for end-users, you can do better than case sensitivity/insensitivity – have a look at Scratch! A few less cartoon cats and more business-friendly colors and you have about the friendliest language I’ve ever seen – and you don’t have to write anything! Just a thought.