32

We're trying to write a custom scripting language. There has been a suggestion to make the language forgiving by providing case insensitive keywords.

I personally do not like the idea, but there are few people in my team leaning towards it, saying it will make the end user happy! Examples of languages like FORTRAN, BASIC, SQL are given saying that these are case insensitive.

Is this a good idea?

17
  • 4
    Well, Visual Basic is generally not case sensitive, does that answer your question? ;P
    – yannis
    Sep 24, 2012 at 10:56
  • 14
  • 3
    Note that it is very difficult to make identifiers case insensitive, unless you limit the users to the ASCII character set. Sep 24, 2012 at 13:07
  • 2
    @MainMa: C++ atleast doesn't directly. It allows implementation-defined characters in the identifier, but what is guaranteed is only a-zA-Z, 0-9 (except at the start) and _.
    – Xeo
    Sep 24, 2012 at 14:34
  • 2
    VB6 actually uses a kind of hybrid approach: You can write keywords and identifiers any way you want and the IDE immediately converts them to the stored way. (You can even write "endif" and it will be converted to "End If".) Sep 24, 2012 at 14:48

13 Answers 13

42

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.

6
  • Think about which filesystems are case sensitive before looking at programming languages. FAT/NTFS for Windows and HFS+ for MacOS X are both case insensitive, while UFS/NFS for Unix are case sensitive. Power users like the ability to distinguish files/variables by tiny differences while most users prefer to keep things more intuitive. As Avner says the difference is a product-management choice. Sep 24, 2012 at 14:16
  • 4
    Since it is a scripting language, it is a no-brainer - case insensitivity is the way to go. Why be case-sensitive? If the answer is "to be like C and Java", is that really a good reason?
    – Ben
    Sep 24, 2012 at 17:23
  • 15
    @Ben Python, Ruby, bash, Lua and Perl are examples of very popular scripting languages that are case sensitive. Case insensitive languages include enterprisey languages like Delphi and SQL (and COBOL IIRC, if you count that). Why is it a no-brainer for scripting languages, and why do the designers of the world's largest scripting languages disagree?
    – user7043
    Sep 24, 2012 at 17:39
  • 2
    It can't be a no-brainer due to being a scripting language -- the relevant question is: who is doing the scripting, and what is the best choice for them? (I will also say that you should probably be consistent: if your keywords are case-insensitive, please do not make the identifiers case-sensitive...) Sep 24, 2012 at 20:44
  • @delnan I think that it is a logical choice that scripting language targeting the OS where case-sensitivity is built-in should also be case-sensitive.
    – Artemix
    Sep 25, 2012 at 10:18
16

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

3
  • 3
    +1 for "will this difference be meaningful to the user". The user matters most of all.
    – Ben
    Sep 24, 2012 at 16:35
  • Why is SQL easier to use in an interactive setting due to case insensitivity? Is it because you can accidentally turn on Caps Lock and not notice?
    – Kaz
    Sep 25, 2012 at 15:41
  • @Kaz - Pretty much.
    – ChrisF
    Sep 25, 2012 at 16:34
11

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.

8
  • 1
    "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?" The answer is "yes", and it's only folly if you think other people's cultures are foolish.
    – Ben
    Sep 25, 2012 at 11:02
  • Well, prepare for your little head to explode, because I don't think other people's cultures are foolish (with certain exceptions, in regard to the world's current events), yet at the same time I think it is completely moronic to treat ファイル and ふぁいる as the same identifier in a programming language.
    – Kaz
    Sep 25, 2012 at 15:30
  • @Ben you know the cultures mentioned? If you knew what Kaz was talking about you wouldn't call him foolish. Sep 26, 2012 at 5:44
  • 1
    @DavidCowden, I at no point called Kaz foolish. I agree one should always use the same case wherever one uses an identifier. Kana difference is more significant than case difference, just as accent difference is more significant than case difference. However just as it is silly to have two identifiers which differ only by case, it is also silly to have two identifiers which differ only by kana or by accent. It makes more sense to forbid identifiers differing only by kana or accent than to treat them the same, but it makes very little sense to treat them as different.
    – Ben
    Sep 26, 2012 at 12:19
  • If you forbid identifiers that differ only in case, accent, or kana or whatever, then you're tacitly admitting that they are the same (but only insisting on consistency). It's better not to banish such things, and leave them to the users to be a matter of coding convention. A better idea would be to have a declarative system whereby the program can assert that foo and Foo are to be treated as synonyms or as distinct. Without such a declaration, it is an error for both of them to occur. And since the declaration doesn't extend to FOO, then FOO is still forbidden; it has to be added.
    – Kaz
    Sep 27, 2012 at 1:57
6

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.

9
  • I don't think wanting to reuse keywords for names is the issue. SQL, Visual Basic, and C# (the former two case-insensitive and the latter case-sensitive) both resolve this by allowing a way to quote identifiers: "double quotes" (or [brackets] in MS SQL) in SQL, [brackets] in VB.net, and @atsign in C#.
    – Random832
    Sep 24, 2012 at 16:11
  • "how often you're going to want to have multiple things with the same name." Case insensitivity means that you must add some overhead to disambiguate names that would otherwise be dealt with by case (eg. m as a prefix for 'member' to distinguish from an unprefix property name, say).
    – nwahmaet
    Sep 24, 2012 at 16:28
  • Why would you name an object object? That's just asking for trouble.
    – Ben
    Sep 24, 2012 at 16:34
  • @Ben, suppose you are implementing a container object, what else are you going to call the parameter to your add method? Sep 24, 2012 at 19:20
  • @WinstonEwert, I would call it o. It really doesn't matter what you call it since it is just a parameter name. As long as it isn't offensive or illegal, or liable to cause confusion.
    – Ben
    Sep 24, 2012 at 19:24
5

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.

9
  • Good point, but not an answer.
    – user7043
    Sep 24, 2012 at 11:40
  • @delnan: perhaps not an answer as good as the one from Avner Shahar-Kashtan (to whom I gave +1), but probably helpful for the OP.
    – Doc Brown
    Sep 24, 2012 at 11:44
  • 3
    Yeah, helpful as a comment ;)
    – user7043
    Sep 24, 2012 at 11:50
  • So if this is reworded to say it's only a good idea if you warn the user about case sensitivity then it would be an answer? To me, that was assumed.
    – JeffO
    Sep 24, 2012 at 13:07
  • No, then it'd be a minor point that's hardly answering the question phrased as an answer. IMHO.
    – user7043
    Sep 24, 2012 at 14:48
4

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.

15
  • 2
    IMHO it makes reading easier too. After all when you start a sentence, you capitalise the first word, But you dont change its meaning. Same should be for code!
    – NWS
    Sep 24, 2012 at 14:59
  • 2
    @delnan - you wanted readability, it uses the same alphabet, Why change the meaning when you change case ?
    – NWS
    Sep 24, 2012 at 16:34
  • 1
    @delnan, according to the Supreme Court of the United States of America, computer languages are an expressive language designed to be understood by both computers and humans (when ruling that computer code is protected by the first amendment). They are not English, but they are a language, and saying "BOB" is different from "bob" is different from "Bob" is idiotic in any language intended to be used by humans. Yes, we can learn to cope with it, but that is no excuse whatsoever.
    – Ben
    Sep 24, 2012 at 18:51
  • 2
    @Ben Let me make an analogy. Mathematical notation is, unlike programming languages, exclusively for humans. The usual argument of case insensitivity being a historical artifact of ancient computers does not apply here. Yet I doubt any mathematician would argue that a and A should be interchangeable. They case consistently, with no exceptions. For instance, in some contexts upper case letters are used for sets while lower case letters are set members. Another example occurs in electrical engineering, lower-case being time-dependent and upper case being time-independent...
    – user7043
    Sep 24, 2012 at 19:10
  • 2
    @Ben ... in these and other contexts, I don't see case sensitivity as a restriction. I see it as freeing up redundant symbols to be used in a more productive manner, through conventions which communicate meaning though, among other means, capitalization. Like any terse domain-specific notation, this may seem alien to the layman but allows the experts to communicate better and more quickly.
    – user7043
    Sep 24, 2012 at 19:12
2

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.

4
  • 4
    I'm sick of the argument "X is good, Y enforces related thing Z, therefore Y does good by enforcing X" (e.g. sane coding style/Python/offside rule). No good programmer capitalizes in a way that seriously impacts readability, even when allowed to. Those who do abuse case insensitivity also capitalize inconsistently in a case sensitive environment (and commit a hundred other atrocities), they are just forced to use the same bad capitalization for each use of an individual name. Bad programmers can write Fortran in any language. (Disclaimer: I'm a huge fan of case sensitivity!)
    – user7043
    Sep 24, 2012 at 13:02
  • Guess what. I'm sick of having to read code written by bad programmers who think they are such good programmers that they can develop their own unique style rules. (Disclaimer: I learned to program in the days of FORTRAN and COBOL, and I detest case insensitivity and other linguistic atrocities from that era.)
    – Stephen C
    Sep 25, 2012 at 7:37
  • Any use of upper case whatsoever in a case insensitive language constitutes abuse of insensitivity.
    – Kaz
    Sep 25, 2012 at 16:14
  • @Kaz - erm ... try telling that to a million SQL programmers.
    – Stephen C
    Apr 6, 2014 at 5:10
1

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

15
  • Case sensitivity does not put the convenience of the computer before that of the user. I have implemented case sensitive and case insensitive languages, and the only difference is an additional function call in a few places. Also, other answers say that case in-sensitivity is a historical artifact due to limited character sets -- contradicts your theory, doesn't it?
    – user7043
    Sep 24, 2012 at 16:44
  • Unicode puts this in a whole other realm.
    – DeadMG
    Sep 24, 2012 at 17:12
  • 3
    That blog doesn't give any justification for why it's bad in C, only in Python or PHP- and the OP isn't talking about case sensitive identifiers, only keywords. That link has absolutely nothing to say about that subject.
    – DeadMG
    Sep 24, 2012 at 17:24
  • 1
    @Ben Editors can (and do) fix casing as you type regardless of the rules of the language. Allowing errors which nevertheless slip through (e.g. because you don't have a fancy editor at hand) does not help. It means leaving a problem around, instead of complaining about it to fix it. Moreover, once I do use consistent capitalization, I can have multiple identifiers differing in case, but denoting very different things and being easy to parse for humans thanks to context and capitalization, without ambiguity.
    – user7043
    Sep 24, 2012 at 19:17
  • 2
    @Ben: In some languages, there are very strict lexographic customs, or even rules. In C and C++, all-caps is a macro, and macros should remain all-caps to prevent confusion. Some languages have different meanings for symbols with or without initial caps (and I don't know how well they'd do in various languages that don't have corresponding upper- and lower-case letters). If you have rules or conventions like that, you get something of the effect of different namespaces, and duplicating identifier names in different namespaces often works. Sep 24, 2012 at 22:23
1

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

1

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?

3
  • Programming languages should have lexical scope to catch this type of error prior to run time (even if they are otherwise highly dynamic). Common Lisp is highly dynamic language, yet the compilers tell us when we have used a variable that has no lexical binding and was not globally defined as a dynamic variable. You can't rely on case insensitivity for this because you want to catch all typos, not only ones involving case.
    – Kaz
    Sep 26, 2012 at 7:26
  • I don't mind HWND hwnd;. This is an example where case sensitivity works well. The all caps type "Indian Hill" convention is silly though. hwnd_t hwnd is much better. I suspect that it's all because of FILE. Once upon a time Version 6 Unix had in its I/O library header file this: #define FILE struct _iobuf. It was in all caps because it was a macro. When it became a typedef in ANSI C, the all caps spelling was retained. And I think it is by imitation of this that the ALL_CAPS_TYPE convention was invented, and codified in the Bell Lab "Indian Hill Style Guide. (The original one!)
    – Kaz
    Sep 26, 2012 at 7:34
  • If you now google for "Indian Hill Style Guide" you find mostly references to a 1990 document from Bell Labs which completely repents of the all caps typedef names: no traces of any such recommendation. But the original version recommended things like typedef struct node *NODE. I'm sure that is where Microsoft must have picked up on this. So, blame Bell Labs for HWND.
    – Kaz
    Sep 26, 2012 at 7:37
1

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

1
  • 1
    Okay, so companyName == companyname. That seems reasonable, but how do you handle locales? Will compiling your program in different parts of the world cause different semantics, as it does in PHP? Will you be completely Anglo-centric and only support the ASCII printable set in identifiers? Case insensitivity is a lot of extra complexity for very little extra gain.
    – Phoshi
    Apr 4, 2014 at 12:06
0

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.

4
  • 1
    Case comparisons are not that hard. Just decompose your identifiers. É=E'=e'=é. Remember, you can still choose which case rules to follow, and English is a reasonable choice. (certainly if your keywords are English too)
    – MSalters
    Sep 25, 2012 at 10:51
  • 2
    Yes they are "that hard", across the entire Unicode space.
    – Kaz
    Sep 25, 2012 at 16:22
  • 1
    "Programmers in this era expect case sensitivity"? Only if they have Stockholm Syndrome from having worked with the C family for too long. Sep 25, 2012 at 22:43
  • Well, the C family only accounts for, like, a very large proportion of languages and code. Besides, I think it's a good thing and your comment proposes no reason why it isn't.
    – DeadMG
    Sep 26, 2012 at 9:32
0

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.

7
  • 1
    I think you wanted to say "case-insensitivity is a nightmare". Japanese does have case: hiragana and katakana are, kind of, different cases. Just like A and a are "same" in a certain way, so are あ and ア. Katakana is sometimes used for emphasis, similarly upper case in languages that use the roman alphabet. Needless to say, it would be idiocy to treat hiragana and katakana as the same in programming language identifiers.
    – Kaz
    Sep 25, 2012 at 16:17
  • Thanks - that's enriching! I cleaned up my post just a little. Sep 25, 2012 at 21:24
  • 1
    Car car; is one of the best arguments against case sensitivity: it's ugly, and if your language is case insensitive, you can't abuse case sensitivity that way. Sep 25, 2012 at 22:42
  • 1
    Is Car myCar; so much better? Sep 26, 2012 at 13:29
  • @Mason Wheeler: If we limit our language constructs to those we can't abuse, we're not going to be able to do much, are we? My advice to anybody abusing case sensitivity is "Don't". Sep 27, 2012 at 14:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.